Rainer Dorsch:
> I think this then results in errors during an apt-get upgrade:
It does indeed. It is systemd-journald that resides at the server end
of /dev/log on a systemd operating system. Quite a lot of other stuff
will break for you if you don't have a running systemd-journald, because
there are quite a lot of things plumbed into systemd-journald, not least
the standard outputs of many of the services on your system.
Restarting systemd-journald historically has not worked *a lot* in
systemd. Bugs about it abound. Things just don't get hooked back up
correctly, and services are surprised and confused by EPIPE errors and
SIGPIPE signals when simply writing to their standard output or error.
* https://bugzilla.redhat.com/show_bug.cgi?id=1378929
* https://bugs.freedesktop.org/show_bug.cgi?id=84923
* https://github.com/chef-cookbooks/chef-client/issues/359
* https://bugs.freedesktop.org/show_bug.cgi?id=56043
... and so on.
You need systemd-journald running. Your best course of action is to see
whether it comes up properly at bootstrap, in normal, rescue, or
emergency mode. If it does not, then *why* is pretty much the first
problem that you need to solve. Note that it is correct for the service
unit to be "static" rather than "enabled". The unit that needs to be
"enabled" is systemd-journald.socket, which is what fires up
systemd-journald.service.
Of course, if a service does not come up, the first port of call is the
log from the service manager to see what errors are recorded, the
infamous "So what do 'journalctl -u systemd-journald -e -b' and
'systemctl status systemd-journald' say?". But in the systemd world
that log is also managed by systemd-journald. Chicken. Egg.
(This is why designs in the daemontools family world have more than one
log daemon. Laurent Bercot describes things in terms of a "logging
chain". If mysqld doesn't start, then one consults the logs maintained
by its (individual) log service. If the mysqld log service itself
didn't start, then one consults the logs maintained by the service
manager's own (distinct) log service.)
> Dec 4 09:44:48 scw-1fe3cf systemd[1]:
[/lib/systemd/system/systemd-journald.service:25] Unknown lvalue
'FileDescriptorStoreMax' in section 'Service'
Oh look. The version of systemd that you have doesn't like the settings
in the systemd-supplied service units that you have. Have you checked
that everything is at the same version?
> Dec 4 09:44:38 scw-1fe3cf systemd[1]:
[/lib/systemd/system/emergency.service:19] Not an absolute path,
ignoring: -/root
> Dec 4 09:44:38 scw-1fe3cf systemd[1]:
[/lib/systemd/system/rescue.service:18] Not an absolute path, ignoring:
-/root
The version of systemd that you have doesn't like some other settings,
too. Rescue and emergency modes are going to be interesting for you, I
suspect.
