running vkernels in production
matthias.rampke at googlemail.com
Fri Feb 3 06:45:19 PST 2012
On Fri, Feb 3, 2012 at 12:52, n0g0013 <ttw+bsd at cobbled.net> wrote:
> the solution would
> appear to be, use `/etc/ttys` to start and manage the process.
Another solution would be to use tmux or screen in the host system to
start the vkernels in detached sessions (I've found tmux to be better
suited; screen gets confused if started outside an interactive
environment, e.g. startup scripts)
I use separate tmux sessions to run semi-interactive $stuff
automatically; since I want them to be associated with a specific user
I have them started from that user's crontab with entries like
@reboot tmux -u new-session -d -s name1 "/path/to/command1 arguments1"
@reboot sleep 2; tmux -u new-session -d -s name2 "/path/to/command2 arguments2"
Note that I found a race-condition in tmux where one of the sessions
won't be reachable if they're started to quickly; thus the "sleep 2;".
This delay can probably be the same for more subsequent sessions as
this only happens on startup of the tmux server, but I haven't tried
that in practice.
You can then attach to the vserver's console by
ssh -t user at server "tmux attach -t name1"
This procedure works in general for any program that you want to run
unattended but may need to reach interactively.
Hoping this helps,
More information about the Users