<p>I'm working on MSCT, a little Minecraft server administration utility for personal use (for now). I'm starting the server in a screen session, and it's working just fine. I'm just having no luck getting the screen to start attached or getting MSCT to <em>resume</em> the screen.</p>
<p>Repo is here: <a href="https://github.com/nathanpaulyoung/msct/blob/master/msct.go" rel="nofollow">https://github.com/nathanpaulyoung/msct/blob/master/msct.go</a></p>
<p>The relevant function on line 48 is:</p>
<pre><code>resumeCommand()
</code></pre>
<p>I feel like it must be something I am simply unaware of, like some sort of special way to invoke a new tty or something. If any of you know of the solution, please chip in with advice or a pull request.</p>
<p><strong>EDIT:</strong> I've started thinking more about the real <em>goal</em> here, and figured I'd mention that, in case that yields a solution that is equally satisfactory if not what I expected. <em>I want the Minecraft server to continue running even when I'm not actively looking at the server console.</em> Whether that means when I'm not currently ssh'd in to the box it's running on, or (in the case of screen) not actually connected to the screen session, it should keep running without my eyes on it. If there's a way to, perhaps, pipe screen content into a custom golang terminal session using <a href="https://golang.org/x/crypto/ssh/terminal" rel="nofollow">https://golang.org/x/crypto/ssh/terminal</a>, or a way to create something similar to screen wherein the Minecraft server can run, those would be just as satisfactory.</p>
<hr/>**评论：**<br/><br/>Bake_Jailey: <pre><p>Have you thought about doing something like just using nohup to background the server, then letting Go just follow the file nohup produces? Looking at your code, it looks like you're just printing the server output without any interaction (which would require some terminal emulation, like with kr/pty).</p>
<p>I might also suggest the (unpopular) opinion that you could do this without Go at all with a little bash script, but I think you're just making something for fun here. :)</p></pre>nathanpaulyoung: <pre><p>I've never used nohup, though I've seen it mentioned in a few places here and there. I'll look into it.</p>
<p>I also JUST started looking into kr/pty (or more specifically keybase/pty, a fork which prevents auto compilation by go get on Windows) and have been tinkering with it. It DOES allow me to see the server output, though in my testing using the simple example code provided I haven't been able to get it to allow me to interact directly with the Minecraft console, and it has a weird bug of preventing scrolling below about half of the console height. If you have any info on how better to use the pty package, I'm all ears.</p>
<p>As for what I'm <em>doing</em>, being able to access the terminal and manually enter commands is a nice feature I would like to have. If MSCT ends up lacking that, it could be excused if it had numerous other valuable features, which leads me to...</p>
<p>Yeah, it absolutely could be done with a bash script, and in fact I was using <a href="http://msmhq.com" rel="nofollow">http://msmhq.com</a> up until VERY recently. Need necessitated rolling my own solution, as it kept overwriting my symlinks to my server's ssd, so I decided to write it in my favorite language, go. You're right, this IS a fun project, but I also plan on adding neat features I would like to have, like an automailer on server crash with attached crash report and server log, among other things I can't do in bash, at least not easily.</p>
<p>Any further advice you would be willing to provide would be amazing. Thanks for everything so far.</p></pre>evilissimo: <pre><p>With go i started writing something that is replacing a service that used to start things in screen sessions. I use docker for it as it lets me attach to that running process fairly easy. If it is really a fun project it might be also interesting for you too :-)</p></pre>nathanpaulyoung: <pre><p>I started looking at docker a while back, and even started writing the dockerfile, but I have to admit, I don't really <em>get</em> it. The guides out there aren't in depth enough, and the repos I looked at all do some really esoteric things in their dockerfiles that really should warrant explanation.</p>
<p>I may look at docker again. Any good resources that <del>covet</del> cover a good breadth and depth of dockerfile configuration?</p></pre>evilissimo: <pre><p>Well you should consider what you want to do, first you usually base your image on some linux base image of your liking, then you usually run the install commands for the system you want to install all the dependencies.</p>
<p>As the last thing you'd add the jar file to the image and do other customizations
To me the docker docs are quite extensive and usually helped me enough</p>
<p>Nevertheless you don't really need to write a docker file you can simply pull a base container and run it with /bin/bash as target, then install all your needs and configure all you need inside of the container and when you exit you commit it</p>
<p>The dockerfile is an automatization tool to build docker images, and allows caching of intermediate containers (after each step such as RUN, ADD etc there's a new container image committed and cached)</p>
<p>But well I think this is getting way out of scope of this comment ;)</p>
<p>At the moment I read your post, I was just thinking that this might be interesting to you :-) I am always in love with tinkering with new things to just understand them and to know about them in case there will be a time where the technology fits for a project I am doing. </p></pre>Fwippy: <pre><p>I would just run <code>screen</code> by hand, and not in your program.</p>
<pre><code>screen #start screen session
./mygoprogram #start your program
(Close the window or ctrl-A D to disconnect)
screen -r #reconnect
</code></pre></pre>nathanpaulyoung: <pre><p>Well the program doesn't need to run in the screen. The program is for starting a jar file in a screen. It kind of need to be this way.</p>
<p>I have been looking at tmux however, and it looks like other go programs have been built for attaching to a tmux session. If that's the case, that may be my solution. I'll be experimenting with it tonight.</p></pre>
