1

Is there a way to join an interactive session of a process that was ran on boot with /etc/rc.local, or send it "stop" over STDIN on reboot/shutdown and wait for it to end before shutting down?

Jan Novák
  • 13
  • 1
    If you launch it in something like screen or tmux you could certainly do that – Eric Renouf Jul 18 '17 at 11:31
  • @EricRenouf even if launched at startup? And is there a way to automate the process with, as I said, sending stop to the process over STDIN and wait for it to end before shutting down (I do need the network interface to be still up before the process ends). – Jan Novák Jul 18 '17 at 11:40
  • Sure, you can script starting a process inside screen see some examples here and you can send commands later to it like here – Eric Renouf Jul 18 '17 at 11:47
  • @EricRenouf But doesn't that have to be from the same session? – Jan Novák Jul 18 '17 at 13:27
  • Nope, that's the advantage of using something like screen or tmux, they'll have their own psuedo-tty that you can attach to any time you like, and detach from again and they'll keep going. They're really useful if you're going to want something to continue across sessions in particular. I use it to start some jobs then ssh from another machine to see how they're going for example – Eric Renouf Jul 18 '17 at 13:29
  • @EricRenouf and what about that waiting for the process to die? – Jan Novák Jul 18 '17 at 13:31
  • 1
    rc.local has been superseded on many operating systems, several times over on some. It only thus works at all via backwards compatibility shims. Exactly how those backwards compatibility shims work varies, moreover. With several of them rc.local does not even have an interactive session and a controlling terminal. rc.local thus does not work the same everywhere, and you need to be specific about what operating system this question pertains to. – JdeBP Jul 18 '17 at 13:31
  • As JdeBP points out, there's probably actually a better way to go (like making a systemd unit that will handle starting and stopping). If you want to do it manually though, you could find the PID of the process and then use wait after you send it the stop, or keep checking with pgrep or similar – Eric Renouf Jul 18 '17 at 13:33
  • @JdeBP in my case it's run by rc.local script inside /etc/init.d on boot - Ubuntu – Jan Novák Jul 18 '17 at 13:47
  • Related: How to recover a backgrounded job from a previous shell – Mark Plotnick Jul 18 '17 at 14:36
  • Even that is not specific enough, as you could be using either Upstart or systemd, and the backwards compatibility shims for rc.local are different in each. You really do need to be specific. In the wider picture, you should of course forget about rc.local. – JdeBP Jul 18 '17 at 21:22
  • Well, it looks like latest LTS Ubuntu (not sure why wouldn't you run the latest LTS version honestly) uses systemd... @JdeBP – Jan Novák Jul 22 '17 at 05:15

1 Answers1

0

As has been explained in comments, you need to “save” the process's stdin somehow. By default, depending on the init system, this may be the console, or /dev/null. To be able to attach to the process, use a screen multiplexer such as Screen or tmux. See also How can I disown a running process and associate it to a new screen shell?

In /etc/rc.local, run something like

screen -S mydaemon -md /usr/local/bin/mydaemon --some-option

To attach to the program interactively, you would then run

screen -S mydaemon -rd

To automatically send keystrokes to the program (see sending text input to a detached screen):

screen -S mydaemon -p 0 -X stuff 'bye^M'
Gilles 'SO- stop being evil'
  • 829,060