On Fri, Feb 3, 2012 at 12:52, n0g0013 <ttw+...@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@server "tmux attach -t name1" etc. This procedure works in general for any program that you want to run unattended but may need to reach interactively. Hoping this helps, Matthias