Description of problem:

This behaviour was found with BZ #1792173 on RHEL 8.

The systemd.special(7) manpage states the following about "sockets.target":
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
       sockets.target
           A special target unit that sets up all socket units (see systemd.socket(5) for details)
           that shall be active after boot.

           Services that can be socket-activated shall add Wants= dependencies to this unit for their
           socket unit during installation. This is best configured via a WantedBy=sockets.target in
           the socket unit's "[Install]" section.
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------

The wording is confusing because the admin can believe that only sockets installed into "sockets.target" are affected, which is not the case.
In fact, as long as a socket is pulled by some target (e.g. "WantedBy=multi-user.target"), a dependency "After" is added to "sockets.target" for that socket, e.g. with "tangd.socket" which currently is installed in multi-user.target:

-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
# systemctl show sockets.target -p After --no-pager
After=dbus.socket syslog.socket systemd-journald.socket systemd-journald-dev-log.socket cups.socket tangd.socket systemd-journald-audit.socket systemd-udevd-kernel.socket systemd-initctl.socket sssd-kcm.socket systemd-udevd-control.socket
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------

This is problematic because if, for some reason, the admin wants a Unix socket to listen on a remote file system, this creates an ordering cycle, breaking the system boot.

IMHO, only sockets installed in sockets.target should be brought online early to reach sockets.target.


Version-Release number of selected component (if applicable):

systemd-219 (RHEL 7) and later


How reproducible:

Always


Steps to Reproduce:

1. Create a "remote" file system (mount delayed)

  # mkdir /my-delayed-mount
  # semanage fcontext -a -t var_run_t "/my-delayed-mount(/.*)?"
  # restorecon -F /my-delayed-mount
  # echo 'tmpfs			/my-delayed-mount	tmpfs	defaults,_netdev,rootcontext="system_u:object_r:var_run_t:s0"	0 0' >> /etc/fstab

2. Create a custom socket listening on the "remote" file system, started by "multi-user.target"

  # cat > /etc/systemd/system/socket-on-remote-fs.service << EOF
[Service]
ExecStart=/bin/true
EOF

  # cat > /etc/systemd/system/socket-on-remote-fs.socket << EOF
[Socket]
ListenStream=/my-delayed-mount/socket-on-remote-fs.sock

[Install]
WantedBy=multi-user.target
EOF
  
3. Enable the socket and reboot

  # systemctl enable socket-on-remote-fs.socket
  # reboot

Actual results:

[    6.596288] systemd[1]: my\x2ddelayed\x2dmount.mount: Found ordering cycle on network.target/start
[    6.599433] systemd[1]: my\x2ddelayed\x2dmount.mount: Found dependency on NetworkManager.service/start
[    6.602596] systemd[1]: my\x2ddelayed\x2dmount.mount: Found dependency on basic.target/start
[    6.605733] systemd[1]: my\x2ddelayed\x2dmount.mount: Found dependency on sockets.target/start
[    6.609254] systemd[1]: my\x2ddelayed\x2dmount.mount: Found dependency on socket-on-remote-fs.socket/start
[    6.615472] systemd[1]: my\x2ddelayed\x2dmount.mount: Found dependency on my\x2ddelayed\x2dmount.mount/start
[ SKIP ] Ordering cycle found, skipping Network
[ SKIP ] Ordering cycle found, skipping Network Manager
[ SKIP ] Ordering cycle found, skipping A So…stening on a non-local file system
[  OK  ] Stopped Switch Root.
...
[FAILED] Failed to mount /home.
See 'systemctl status home.mount' for details.


Expected results:

No ordering cycle since the socket is WantedBy "multi-user.target", not "sockets.target".


Additional info:

This boot resulted in not having NetworkManager start at all ("network.target" being skipped).
See also BZ #1792173 for actual use case (tangd.socket not starting).