On Tue, 02.07.13 16:57, Jean-Marc Pigeon (jmp@safe.ca) wrote:
As expected the problem stand on a very small detail (within /etc/fstab)
Not working /vzgot / ext4 defaults 0 0 proc /proc proc defaults 0 0 sysfs /sys sysfs defaults 0 0 devpts /dev/pts devpts defaults 0 0 tmpfs /dev/shm tmpfs defaults 0 0
Working #/vzgot / ext4 defaults 0 0 proc /proc proc defaults 0 0 sysfs /sys sysfs defaults 0 0 devpts /dev/pts devpts defaults 0 0 tmpfs /dev/shm tmpfs defaults 0 0
Note that in a systemd world fstab shouldn't really list any of the virtual file systems like procfs, sysfs, devpts, /dev/shm, unless you have specific mount options that need to override the defaults. Also, the root file system doesn't need to be listed. It is hence a good idea to leave fstab out entirely if you run things in a container.
The fact that the line just below says, "Please see journal" but journal is not available (empty) just compound the effect.
How did you access the journal? The journal is actually available pretty much all the time. It logs to /run as long as /var is not there, to make this work (very much unlike classic syslog, btw).
So, no, sorry, systemd doesn't grade "production level" (not yet? or never?).
Well, as mentioned you altered the most low-level parts of the unit dep tree. So yeah, a setup like that certainly is not "production level", but that's hardly our fault.
May I propose some way to improve it.
- journal should be accessible regardless of systemd status or
trouble.
It is. journalctl directly accesses all journal files and starts very early in the boot process, including in initrd (hint: this is *much* earlier than classic syslog). And for the time even before the journal is around, we log to kmsg (i.e. demsg).
- You should have a way to proceed in a 'step by step' boot mode (avoiding in parallel fast scrolling report)
systemd.confirm_spawn=yes
But disabling the parallelization doesn't really work. If a service foo triggers starting of a service bar while it is starting up, and needs an answer from bar before it can proceed, how do you want to ever solve this? You need to start both foo and bar at the same time.
- On a more philosophical side:
- linking PID1 and systemd seems to me a problem (why it is
mandatory still escape me),
systemd is an init system. init systems run as PID 1. This how Unix works.
Bug:
- After a very quick check, there is maybe a bug the way systemd is
handling 'int reboot(int cmd);', I have the strong feeling systemd is not feeding WTERMSIG(status), but it is very preliminary, I could be wrong....
Hmm? I cannot parse this.
Lennart