** Description changed: [ Impact ] The enabled tangd.socket service starting on boot is unreliable, due to the start job being deleted as a result of a systemd ordering cycle. Users relying on tangd to be started on boot have to manually check that the service started after a reboot, or implement custom workarounds to ensure the same. The fix removes the opportunity for an ordering cycle to occur in the unit by moving dependencies out of the socket unit and changing the WantedBy to sockets.target (what it should be for a socket unit). [ Test Plan ] The bug is reproduced by installing 'tang' (version 7-1build1) on a machine running Focal 20.04.6 or earlier. The unit should be enabled by default. `sudo apt install tang` After installing the package, ensure the tang service is enabled. `systemctl is-enabled tang` reboot the server, and check that the tangd.socket service is running `systemctl status tangd.socket` The service may or may not be running depending how systemd ordered the startup jobs for this boot. You can simply repeat rebooting the server and eventually at some point the service will not come up after a boot. Regardless if the service is started on boot, you can see similar messages to these in the system log: Apr 5 05:01:05 tangtest-vm-2 kernel: systemd[1]: sockets.target: Found ordering cycle on tangd.socket/start Apr 5 05:01:05 tangtest-vm-2 kernel: systemd[1]: sockets.target: Found dependency on tangd-update.service/start Apr 5 05:01:05 tangtest-vm-2 kernel: systemd[1]: sockets.target: Found dependency on basic.target/start Apr 5 05:01:05 tangtest-vm-2 kernel: systemd[1]: sockets.target: Found dependency on sockets.target/start Apr 5 05:01:05 tangtest-vm-2 kernel: systemd[1]: sockets.target: Job tangd.socket/start deleted to break ordering cycle starting with sockets.target/start + The fix requires modifying the tangd.socket unit WantedBy from multi- + user.target to sockets.target. This means the 'enabled' status relies on + links in a different directory before and after upgrade. The upgrade + ought to remove the old multi-user.target link. So assuming the unit is + 'enabled', the only links existing should be: + + Before upgrade: + /etc/systemd/system/multi-user.target.wants/tangd.socket + + After upgrade: + /etc/systemd/system/sockets.target.wants/tangd.socket + [ Where problems could occur ] The tang service may not start correctly. If it is made to be part of a systemd dependency chain with other services, those services may also be impacted/fail to start. Since the systemd units are altered, even if the service starts it may change the way the tang service was originally configured to run. Other applications/clients relying on the tang service may experiences issues if the service is not running as originally configured in prior release. [ Other Info ] The proposed fix is derived from an upstream fix: https://github.com/latchset/tang/commit/77785125fb56 There is a minor modification to the diff since the Ubuntu package source file for tangd.socket has a '.in' extension, upstream does not. Versions starting with v8 already contain the fix: $ git describe --contains 77785125fb56 v8~9 + Since we are updating the WantedBy link from multi-user to socket via a + change in postinst, a downgrade using `apt install tang={version}` will + not have a postinst to account for this. The best way to downgrade is to + remove the package, and then install the desired version to add the + correct link. + Original bug text below: ---------- I had the same issue, described here: https://bugzilla.redhat.com/show_bug.cgi?id=1792173 This issue was found, because tangd didn't provide the advertisement payload anymore, after reboot. Ubuntu version: 20.04.2 Package version of tang: 7-1build1 The bug could be fixed by the recommended changes from Renaud Métrich 2020-01-17 08:35:08 UTC. ----------
-- You received this bug notification because you are a member of SE ("STS") Sponsors, which is subscribed to the bug report. https://bugs.launchpad.net/bugs/1930203 Title: ordering cycle after reboot Status in tang package in Ubuntu: Fix Released Status in tang source package in Focal: Incomplete Bug description: [ Impact ] The enabled tangd.socket service starting on boot is unreliable, due to the start job being deleted as a result of a systemd ordering cycle. Users relying on tangd to be started on boot have to manually check that the service started after a reboot, or implement custom workarounds to ensure the same. The fix removes the opportunity for an ordering cycle to occur in the unit by moving dependencies out of the socket unit and changing the WantedBy to sockets.target (what it should be for a socket unit). [ Test Plan ] The bug is reproduced by installing 'tang' (version 7-1build1) on a machine running Focal 20.04.6 or earlier. The unit should be enabled by default. `sudo apt install tang` After installing the package, ensure the tang service is enabled. `systemctl is-enabled tang` reboot the server, and check that the tangd.socket service is running `systemctl status tangd.socket` The service may or may not be running depending how systemd ordered the startup jobs for this boot. You can simply repeat rebooting the server and eventually at some point the service will not come up after a boot. Regardless if the service is started on boot, you can see similar messages to these in the system log: Apr 5 05:01:05 tangtest-vm-2 kernel: systemd[1]: sockets.target: Found ordering cycle on tangd.socket/start Apr 5 05:01:05 tangtest-vm-2 kernel: systemd[1]: sockets.target: Found dependency on tangd-update.service/start Apr 5 05:01:05 tangtest-vm-2 kernel: systemd[1]: sockets.target: Found dependency on basic.target/start Apr 5 05:01:05 tangtest-vm-2 kernel: systemd[1]: sockets.target: Found dependency on sockets.target/start Apr 5 05:01:05 tangtest-vm-2 kernel: systemd[1]: sockets.target: Job tangd.socket/start deleted to break ordering cycle starting with sockets.target/start The fix requires modifying the tangd.socket unit WantedBy from multi- user.target to sockets.target. This means the 'enabled' status relies on links in a different directory before and after upgrade. The upgrade ought to remove the old multi-user.target link. So assuming the unit is 'enabled', the only links existing should be: Before upgrade: /etc/systemd/system/multi-user.target.wants/tangd.socket After upgrade: /etc/systemd/system/sockets.target.wants/tangd.socket [ Where problems could occur ] The tang service may not start correctly. If it is made to be part of a systemd dependency chain with other services, those services may also be impacted/fail to start. Since the systemd units are altered, even if the service starts it may change the way the tang service was originally configured to run. Other applications/clients relying on the tang service may experiences issues if the service is not running as originally configured in prior release. [ Other Info ] The proposed fix is derived from an upstream fix: https://github.com/latchset/tang/commit/77785125fb56 There is a minor modification to the diff since the Ubuntu package source file for tangd.socket has a '.in' extension, upstream does not. Versions starting with v8 already contain the fix: $ git describe --contains 77785125fb56 v8~9 Since we are updating the WantedBy link from multi-user to socket via a change in postinst, a downgrade using `apt install tang={version}` will not have a postinst to account for this. The best way to downgrade is to remove the package, and then install the desired version to add the correct link. Original bug text below: ---------- I had the same issue, described here: https://bugzilla.redhat.com/show_bug.cgi?id=1792173 This issue was found, because tangd didn't provide the advertisement payload anymore, after reboot. Ubuntu version: 20.04.2 Package version of tang: 7-1build1 The bug could be fixed by the recommended changes from Renaud Métrich 2020-01-17 08:35:08 UTC. ---------- To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/tang/+bug/1930203/+subscriptions -- Mailing list: https://launchpad.net/~sts-sponsors Post to : sts-sponsors@lists.launchpad.net Unsubscribe : https://launchpad.net/~sts-sponsors More help : https://help.launchpad.net/ListHelp