Difference between revisions of "util-vserver:Logging"
From Linux-VServer
m (some reformatting and more detail) |
(the intermediate result of my investigations) |
||
| Line 3: | Line 3: | ||
Where is the startup output of vservers going? | Where is the startup output of vservers going? | ||
| − | (A) when using init styles others than "plain" (for example without any style setting) | + | ==== (A) when using vserver init styles others than "plain": ==== |
| + | |||
| + | (for example without any /etc/vservers/<name>/apps/init/style setting) | ||
* "vserver <name> <command>" by itself will not do any redirection, thus print and read to/from the current terminal/whatever. | * "vserver <name> <command>" by itself will not do any redirection, thus print and read to/from the current terminal/whatever. | ||
| − | * <tt>/etc/init.d/vservers</tt> will typically run <tt>lib/util-vserver/vserver-wrapper</tt> which will redirect stdin/out/err from/to the value at <tt>/etc/vservers/guest/apps/init/tty</tt>, <tt>/etc/vservers/.defaults/apps/init/tty</tt> or if neither is set, /dev/null. NOTE: just linking to a normal file will log to that file, but currently also open stdin from that file, which may have bad consequences if some programs actually reads from stdin (it may even create an endless loop appending and reading from the file). | + | * <tt>/etc/init.d/vservers</tt> will typically run <tt>lib/util-vserver/vserver-wrapper</tt> which will redirect stdin/out/err from/to the value at <tt>/etc/vservers/guest/apps/init/tty</tt>, <tt>/etc/vservers/.defaults/apps/init/tty</tt> or if neither is set, /dev/null. NOTE: just linking to a normal file will log to that file, but currently also open stdin from that file, which may have bad consequences if some programs actually reads from stdin (it may even create an endless loop appending and reading from the file). (<tt>pflanze</tt> has started looking into changing this (opening stdin from /dev/null if the link is pointing to a file) but has run out of energy right now.) |
You have to keep this in mind: if for some reason a vserver does not start upon host reboot, but starts without problems with "vserver <name> start", that could be because a program in your vserver's scripts/* directory depends on having access to a terminal. This is (like it is with every system service) one of the differences between starting vservers from host's init process or from a login shell (others being resource limits and environment variables). | You have to keep this in mind: if for some reason a vserver does not start upon host reboot, but starts without problems with "vserver <name> start", that could be because a program in your vserver's scripts/* directory depends on having access to a terminal. This is (like it is with every system service) one of the differences between starting vservers from host's init process or from a login shell (others being resource limits and environment variables). | ||
| + | |||
| + | ==== (B) when using vserver init style "plain" ==== | ||
| + | |||
| + | (what is different to (A)? to be investigated/documented) | ||
Revision as of 18:19, 10 February 2007
Accessing vserver startup output
Where is the startup output of vservers going?
(A) when using vserver init styles others than "plain":
(for example without any /etc/vservers/<name>/apps/init/style setting)
- "vserver <name> <command>" by itself will not do any redirection, thus print and read to/from the current terminal/whatever.
- /etc/init.d/vservers will typically run lib/util-vserver/vserver-wrapper which will redirect stdin/out/err from/to the value at /etc/vservers/guest/apps/init/tty, /etc/vservers/.defaults/apps/init/tty or if neither is set, /dev/null. NOTE: just linking to a normal file will log to that file, but currently also open stdin from that file, which may have bad consequences if some programs actually reads from stdin (it may even create an endless loop appending and reading from the file). (pflanze has started looking into changing this (opening stdin from /dev/null if the link is pointing to a file) but has run out of energy right now.)
You have to keep this in mind: if for some reason a vserver does not start upon host reboot, but starts without problems with "vserver <name> start", that could be because a program in your vserver's scripts/* directory depends on having access to a terminal. This is (like it is with every system service) one of the differences between starting vservers from host's init process or from a login shell (others being resource limits and environment variables).
(B) when using vserver init style "plain"
(what is different to (A)? to be investigated/documented)
