RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1745177 - tangd.socket After= lines cause it to try to start before multi-user.target, causing a dependency loop failure.
Summary: tangd.socket After= lines cause it to try to start before multi-user.target, ...
Keywords:
Status: CLOSED DUPLICATE of bug 1679186
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: tang
Version: 8.4
Hardware: x86_64
OS: Linux
medium
unspecified
Target Milestone: rc
: 8.0
Assignee: Sergio Correia
QA Contact: Martin Zelený
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-08-23 18:57 UTC by Tom Crider
Modified: 2023-09-07 20:30 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-10-14 12:44:51 UTC
Type: Bug
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker RHELPLAN-27495 0 None None None 2023-09-07 20:30:08 UTC

Description Tom Crider 2019-08-23 18:57:40 UTC
Description of problem:

tangd.socket After= lines cause it to try to start before multi-user.target, causing a dependency loop failure.

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

tang-7-1.el8.x86_64


How reproducible:

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/system_design_guide/configuring-automated-unlocking-of-encrypted-volumes-using-policy-based-decryption_system-design-guide

Specifically:

# systemctl enable tangd.socket

then rebooting, we hit the issue 

# systemctl status tangd.socket

● tangd.socket - Tang Server socket
   Loaded: loaded (/usr/lib/systemd/system/tangd.socket; enabled; vendor preset>
   Active: inactive (dead)
   Listen: [::]:80 (Stream)
 Accepted: 0; Connected: 0;

# cat /var/log/messages | grep tang:
--------------------------------
Aug 23 13:09:05 localhost systemd[1]: Started tangd-update.path.
Aug 23 13:10:05 localhost systemd[1]: sockets.target: Found ordering cycle on tangd.socket/start
Aug 23 13:10:05 localhost systemd[1]: sockets.target: Found dependency on tangd-update.service/start
Aug 23 13:10:05 localhost systemd[1]: sockets.target: Job tangd.socket/start deleted to break ordering cycle starting with sockets.target/start
Aug 23 13:10:06 localhost systemd[1]: Started tangd-update.path.
--------------------------------


Steps to Reproduce:
# yum install tang
# systemctl enable tangd.socket
# reboot

Actual results:

# systemctl status tangd.socket:

● tangd.socket - Tang Server socket
   Loaded: loaded (/usr/lib/systemd/system/tangd.socket; enabled; vendor preset>
   Active: inactive (dead)
   Listen: [::]:80 (Stream)
 Accepted: 0; Connected: 0;


Expected results:

# systemctl status tangd.socket:

● tangd.socket - Tang Server socket
   Loaded: loaded (/usr/lib/systemd/system/tangd.socket; enabled; vendor preset>
   Active: active (listening) since Fri 2019-08-23 14:51:08 EDT; 2s ago
   Listen: [::]:80 (Stream)
 Accepted: 0; Connected: 0;
   CGroup: /system.slice/tangd.socket

Aug 23 14:51:08 localhost.localdomain systemd[1]: Listening on Tang Server sock>


Additional info:

I noticed that the default socket in the administration guide differs from the one shipped with the tang package (ignore the port on the admin guide socket):

Admin Guide:
--------------------------------
[Unit]
Description=Tang Server socket
Requires=tangd-update.path
Requires=tangd-keygen.service

[Socket]
ListenStream=7500
Accept=true

[Install]
WantedBy=multi-user.target
--------------------------------

RHEL 8:
--------------------------------
[Unit]
Description=Tang Server socket
Requires=tangd-keygen.service
Requires=tangd-update.service
Requires=tangd-update.path
After=tangd-keygen.service
After=tangd-update.service

[Socket]
ListenStream=80
Accept=true

[Install]
WantedBy=multi-user.target
--------------------------------

After removing the After= lines from: /usr/lib/systemd/system/tangd.socket to read:
--------------------------------
[Unit]
Description=Tang Server socket
Requires=tangd-keygen.service
Requires=tangd-update.service
Requires=tangd-update.path

[Socket]
ListenStream=80
Accept=true

[Install]
WantedBy=multi-user.target
--------------------------------

The socket started on reboot as intended. 

The cause of this is because tangd.socket is part of multi-user.target, and when enabled you can see it create the symlink:

# systemctl enable tangd.socket
Created symlink /etc/systemd/system/multi-user.target.wants/tangd.socket → /usr/lib/systemd/system/tangd.socket.

However neither tangd-update.service, tangd-update.path, or tangd-keygen.service are part of that target, which leads me to believe they do not require dbus to run, and therefore start before dbus. By calling tangd.socket to start immediately 'After=' one of these services, it then tries to start it outside of the multi-user.target, "skipping the line" so to speak, since these other services start before dbus, causing the issue. 

Specifically, multi-user.target needs basic.target, and basic.target needs sockets.target.. which needs dbus. You can't run a socket without sockets.target, and you can't run sockets.target without dbus, as far as I'm aware. In this case there's no reason to call After= in the socket because  the services are started before multi-user.target

Comment 1 Martin Zelený 2019-09-18 12:06:12 UTC
Probably connected with bz1679186.

Comment 2 Sergio Correia 2019-10-14 12:44:51 UTC
Closing this as a duplicate of https://bugzilla.redhat.com/show_bug.cgi?id=1679186.

By moving the key generation to tang, this issue gets resolved as well, as we will not have the affected units anymore (tangd-update.path, tangd-update.service and tangd.keygen.service).

*** This bug has been marked as a duplicate of bug 1679186 ***


Note You need to log in before you can comment on or make changes to this bug.