On 23/08/14 16:30, Bzzzz wrote:
> This raises a question: shall I assume that systemd will turn
> machines administration into a kinda ISO-9001 long and painful
> procedures to _absolutely_ apply, with a "sanction" each
> time things aren't completely right? (and if so, will there
> be an alternative to it? (sysv or other)).
systemd's goals do not include making machine administration more
difficult. That would be silly.
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.
sysvinit is still available if you don't need systemd's features; but if
you have packages that depend on libpam-systemd, then you do need some
of systemd's features (at least systemd-logind). It is possible to use
systemd-logind on sysvinit via systemd-shim, but I would not personally
recommend that configuration.
> E: cups-daemon: subprocess installed post-installation script returned error
> exit status 1
As with the dbus error, this is not the important part: the crucial
lines of output that indicate *why* the postinst returned 1 will be a
few lines above that.
S
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
