[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: systemd-journald fails



Hi Jonathan,

 

many thanks for your response.

 

On Tuesday 06 December 2016 00:04:04 Jonathan de Boyne Pollard wrote:

> 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.

 

Hmmm...I need to find out how I boot in rescue mode on a virtual machine from scaleway (KVM).

 

>

> 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.

 

Indeed there is not much information.

 

root@scw:~# systemctl status systemd-journald

● systemd-journald.service - Journal Service

Loaded: loaded (/lib/systemd/system/systemd-journald.service; static; vendor preset: enabled)

Active: failed (Result: exit-code) since Fri 2016-12-09 20:27:23 UTC; 1min 11s ago

Docs: man:systemd-journald.service(8)

man:journald.conf(5)

Main PID: 2395 (code=exited, status=1/FAILURE)

root@scw:~# journalctl -u systemd-journald -e -b

-- No entries --

root@scw:~#

 

> (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?

 

It is an uptodate stretch system, therefore I would assume that the systemd components fit together.

 

Is there anything more you include in "everything"? :-)

 

root@scw:~# dpkg --get-selections|grep -i systemd

libpam-systemd:amd64 install

libsystemd0:amd64 install

systemd install

systemd-sysv install

root@scw:~# apt-cache policy systemd

systemd:

Installed: 232-7

Candidate: 232-7

Version table:

*** 232-7 500

500 http://ftp.fr.debian.org/debian stretch/main amd64 Packages

100 /var/lib/dpkg/status

root@scw:~# apt-cache policy systemd-sysv

systemd-sysv:

Installed: 232-7

Candidate: 232-7

Version table:

*** 232-7 500

500 http://ftp.fr.debian.org/debian stretch/main amd64 Packages

100 /var/lib/dpkg/status

root@scw:~# apt-cache policy libsystemd

libsystemd0 libsystemd-dev

root@scw:~# apt-cache policy libsystemd0

libsystemd0:

Installed: 232-7

Candidate: 232-7

Version table:

*** 232-7 500

500 http://ftp.fr.debian.org/debian stretch/main amd64 Packages

100 /var/lib/dpkg/status

root@scw:~# apt-cache policy libpam-systemd

libpam-systemd:

Installed: 232-7

Candidate: 232-7

Version table:

*** 232-7 500

500 http://ftp.fr.debian.org/debian stretch/main amd64 Packages

100 /var/lib/dpkg/status

root@scw:~#

 

 

> > 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.

>

 

I try to figure out tomorrow if I can boot one of them....

 

Thanks again

Rainer

 

 

--

Rainer Dorsch

http://bokomoko.de/


Reply to: