On Wed 27 Aug 2014 at 06:16:39 +0200, Bzzzz wrote: > I followed all links given by the article, which convince me of one > thing: I don't want this on my machines, especially on servers > (and a recent unpleasant problem raised by systemd getting in > emergency mode just for a bad line into /etc/fstab (that never > caused any problem with sysV) has finished to convince me).
For those who like to know both sides of a story there is http://lists.alioth.debian.org/pipermail/pkg-systemd-maintainers/2014-August/003333.html However, it is considerably better at detecting errors than sysvinit. Failure to mount a filesystem during boot is potentially serious: if you expect a particular filesystem to be mounted but it is not, then any suitably privileged applications trying to read/write that filesystem will actually read/write whatever is in its mount point. This could be really bad if it was /var, for instance. In this case, yes it isn't actually serious, but systemd can't know how you use your filesystems unless you tell it via the auto/noauto and fail/nofail flags. Your system's configuration already had a problem (there was a filesystem in /etc/fstab that was marked for mounting during boot, but wasn't always actually present), but sysvinit's error handling is almost nonexistent, so its response is to carry on anyway. In contrast, systemd's response to a potentially serious problem is "stop doing things that might do more damage, and let the sysadmin either deal with it or configure it to be ignored". You can stop doing that by adding noauto, and/or configure failures to be ignored with nofail. > The 'kernel debug systemd bug' thread is also edifying enough… > > I strongly hope Debian will still keep sysV available without any > systemd part involved; otherwise I'm afraid it'll abruptly end > 15 years of fidelity. Upstart, sysvinit-core and openrc will definitely be with us for the next three years or so. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140827141902.gc4...@copernicus.demon.co.uk