vote for systemd: Nay (now working but still Voting Nay)

[Lennart Poettering]

On Tue, 02.07.13 16:57, Jean-Marc Pigeon (jmp at 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

-- 
Lennart Poettering - Red Hat, Inc.