Bug 76126

Summary: Missing entries in journal since systemd 210
Product: systemd Reporter: Maciej Puzio <e2270733>
Component: generalAssignee: systemd-bugs
Status: RESOLVED FIXED QA Contact: systemd-bugs
Severity: normal    
Priority: medium CC: brent.saner
Version: unspecified   
Hardware: ARM   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Attachments: journald.conf

Description Maciej Puzio 2014-03-13 16:38:19 UTC
Since the upgrade from systemd 208 to systemd 210 I noticed that some entries that were previously logged during boot to the journal are missing. Specifically this includes "Starting [service name]" and "Started [service name]" lines. Below are excerpts from journal for OpenLDAP's slapd, however many other services are affected. It appears that this issue occurs during a specific phase of the boot (encompassing several services), and services started before and after are logged properly. As far as I can tell, services start as expected and the only problem is with journal logging.

I am not sure whether this problem started with systemd 209 or 210, as I did not test version 209. While the problem has been noticed on an ARM machine (RaspberryPi), I assume it is not ARM-specific.

Entries for slapd.service on machine running systemd 210:

Mar 12 13:53:41 nine slapd[122]: @(#) $OpenLDAP: slapd 2.4.39 (Feb  2 2014 15:15:20) $
                                         nobody@root-armv6-copy:/build/openldap/src/openldap-2.4.39/servers/slapd
Mar 12 13:53:41 nine slapd[122]: daemon: IPv6 socket() failed errno=97 (Address family not supported by protocol)
Mar 12 13:53:43 nine slapd[156]: slapd starting

Information about this machine:
Arch Linux ARM on RaspberryPi Model B
# uname -a
Linux nine 3.10.33-1-ARCH #1 PREEMPT Sat Mar 8 02:21:59 MST 2014 armv6l GNU/Linux
# pacman -Q systemd
systemd 210-3

Entries for slapd.service on machine running systemd 208:

Mar 03 19:14:55 nano systemd[1]: Starting OpenLDAP server daemon...
Mar 03 19:14:55 nano slapd[126]: @(#) $OpenLDAP: slapd 2.4.39 (Feb  2 2014 15:15:20) $
                                         nobody@root-armv6-copy:/build/openldap/src/openldap-2.4.39/servers/slapd
Mar 03 19:14:56 nano slapd[126]: daemon: IPv6 socket() failed errno=97 (Address family not supported by protocol)
Mar 03 19:14:56 nano slapd[156]: slapd starting
Mar 03 19:14:56 nano systemd[1]: Started OpenLDAP server daemon.

Information about this machine:
Arch Linux ARM on RaspberryPi Model B
# uname -a
Linux nano 3.10.32-1-ARCH #1 PREEMPT Mon Feb 24 02:03:19 MST 2014 armv6l GNU/Linux
# pacman -Q systemd
systemd 208-11

Contents of /etc/systemd/journald.conf is the same on both machines and does not specify any non-default settings (file attached).

Thank you
Maciej Puzio
Comment 1 Maciej Puzio 2014-03-13 16:39:13 UTC
Created attachment 95728 [details]
journald.conf
Comment 2 Maciej Puzio 2014-03-26 12:26:59 UTC
Problem still present in systemd 211.
Comment 3 Maciej Puzio 2014-04-09 12:48:34 UTC
Problem still present in systemd 212.
Comment 4 Maciej Puzio 2014-06-06 19:48:23 UTC
Problem still present in systemd 213.

If anyone is reading this, may I ask for a comment as a confirmation that this bug tracker is monitored. For nearly three months I have received no reply, nor any indication that anyone whatsoever pays attention to bug reports posted here. I will stop monitoring this bug if this situation continues.
Comment 5 Maciej Puzio 2014-06-25 17:58:03 UTC
Problem still present in systemd 214-2.1
This is my last post for this bug, due to lack of response.
Comment 6 Zbigniew Jedrzejewski-Szmek 2014-06-26 11:56:43 UTC
Can you attach the whole log with 'journalctl -o short-monotonic -b'?
Comment 7 Lennart Poettering 2014-07-03 14:10:52 UTC
I cannot reproduce this here. Would be good to get an strace of PID 1 while you start a service.
Comment 8 Lennart Poettering 2016-06-07 13:11:47 UTC
Closing due to lack of response and I am assuming that this got fixed already.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.