Bug 950857 - systemd: break ordering cycle starting with systemd-journald.socket/start
Summary: systemd: break ordering cycle starting with systemd-journald.socket/start
Status: NEW
Alias: None
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: Basesystem (show other bugs)
Version: Current
Hardware: x86-64 Other
: P5 - None : Normal (vote)
Target Milestone: ---
Assignee: Marcus Meissner
QA Contact: E-mail List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-10-17 09:56 UTC by Paul Tannington
Modified: 2018-09-29 22:43 UTC (History)
5 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Paul Tannington 2015-10-17 09:56:21 UTC
Since the Tumbleweed 20151012 snapshot I'm seeing this during the initrd stage of system boot:

haveged.service: Job haveged.service/start deleted to break ordering cycle starting with systemd-journald.socket/start



Shown below is all systemd related from dmesg on a fresh boot prior to the line:
"... haveged.service: Job haveged.service/start deleted to break ordering cycle ..."


paul@Orion-Tumble:~$ dmesg | grep -i systemd
[    3.323154] random: systemd urandom read with 23 bits of entropy available
[    3.324085] systemd[1]: systemd 224 running in system mode. (+PAM +AUDIT +SELINUX -IMA +APPARMOR -SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ -LZ4 +SECCOMP +BLKID -ELFUTILS +KMOD +IDN)
[    3.324275] systemd[1]: Detected architecture x86-64.
[    3.324278] systemd[1]: Running in initial RAM disk.
[    3.324306] systemd[1]: Set hostname to <Orion-Tumble>.
[    3.328468] systemd-fstab-generator[86]: Failed to create mount unit file /run/systemd/generator/sysroot.mount, as it already exists. Duplicate entry in /etc/fstab?
[    3.329237] systemd[83]: /usr/lib/systemd/system-generators/systemd-fstab-generator failed with error code 1.
[    3.377028] systemd[1]: systemd-journald.socket: Found ordering cycle on systemd-journald.socket/start
[    3.377036] systemd[1]: systemd-journald.socket: Found dependency on haveged.service/start
[    3.377039] systemd[1]: systemd-journald.socket: Found dependency on systemd-journald.socket/start
[    3.377043] systemd[1]: systemd-journald.socket: Breaking ordering cycle by deleting job haveged.service/start
[    3.377047] systemd[1]: haveged.service: Job haveged.service/start deleted to break ordering cycle starting with systemd-journald.socket/start
[    3.377763] systemd[1]: Reached target Swap.



See also:
https://forums.opensuse.org/showthread.php/510267-systemd-break-ordering-cycle
Comment 1 Andrei Borzenkov 2015-10-18 09:16:40 UTC
The reason is https://build.opensuse.org/request/show/335611 which added dependency on systemd-journald.socket. Systemd automatically adds After dependency on systemd-journald.socket to every service that has any of kmsg, syslog or journal as its output/error.

10:~ # systemctl --no-pager show -p After -p Before haveged.service
Before=systemd-journald.socket sysinit.target systemd-journald.service shutdown.target
After=systemd-journald.socket systemd-random-seed.service system.slice


Unfortunately either you lose output to syslog/journal from haveged (by setting stdout/stderr to NULL) or you have to revert this request.
Comment 2 Marcus Meissner 2015-10-18 11:04:51 UTC
interesting, i was wondering where the dependency came from.

how does it find this out?
Comment 3 Andrei Borzenkov 2015-10-18 11:30:27 UTC
(In reply to Marcus Meissner from comment #2)
> interesting, i was wondering where the dependency came from.
> 
> how does it find this out?

What is `it' and what is `this'?
Comment 4 Marcus Meissner 2015-10-18 11:34:27 UTC
that a program will do syslog or stderr output.

This loop detection seems to happen before the service is started?
Comment 5 Andrei Borzenkov 2015-10-18 11:43:26 UTC
(In reply to Marcus Meissner from comment #4)
> that a program will do syslog or stderr output.

StandardOutput BTW StandardError configuration directives. Quoting man page

This setting defaults to the value set with DefaultStandardOutput= in systemd-system.conf(5), which defaults to journal.

Unit definitions are read and parsed as part of constructing transaction, so before the very first service is started.

What was the reason for this dependency in the first place? Is it not enough to have haveged be ordered before journald *service*? As usual I am not entitled access to mentioned bug report.
Comment 6 Marcus Meissner 2015-10-18 11:59:35 UTC
The problem is the following.

journald uses libgcrypt for sha256 hashing.

libgcrypt in FIPS mode needs randomness on startup (loading of the dll).

In VMs there is lack of randomness this early, so as workaround I need haveged running to inject randomness.

So I need haveged to be started in parallel or before systemd-journald, and the Before dependencies tried to express it but caused this loop.
Comment 7 Bernhard Wiedemann 2015-10-18 12:00:17 UTC
This is an autogenerated message for OBS integration:
This bug (950857) was mentioned in
https://build.opensuse.org/request/show/339598 Factory / haveged
Comment 8 Andrei Borzenkov 2015-10-18 12:29:39 UTC
(In reply to Marcus Meissner from comment #6)
> 
> So I need haveged to be started in parallel or before systemd-journald,

This does not answer my question - why ordering haveged before systemd-journald *service* is not enough.
Comment 9 Marcus Meissner 2015-10-18 13:27:57 UTC
That turned out not to be sufficient in my testing.


The systemd-journald.socket also will start the .service as soon as someone accesses the syslog socket. This might just have been haveged itself with it syslog() call, deadlocking it nicely. :/

I might try to remove syslog output from haveged.
Comment 10 Andrei Borzenkov 2015-10-18 14:52:28 UTC
(In reply to Marcus Meissner from comment #9)
> The systemd-journald.socket also will start the .service as soon as someone
> accesses the syslog socket. This might just have been haveged itself with it
> syslog() call, deadlocking it nicely. :/
> 

That's true. But it also true for haveged stdout/stderr which are connected to journald socket. IOW unit that must be started before journald cannot have its output connected to journald. I wonder if this could be a reason for failure to start journald some people reported (I have observed it myself).