You have been subscribed to a public bug by Rafael Lopez (rafael.lopez):
[ 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
[ 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/pull/42/files
There is a minor modification to the diff since the Ubuntu package
source file for tangd.socket has a '.in' extension, upstream does not.
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.
----------
** Affects: tang (Ubuntu)
Importance: Undecided
Status: Fix Released
** Affects: tang (Ubuntu Focal)
Importance: Medium
Assignee: Rafael Lopez (rafael.lopez)
Status: In Progress
** Tags: sts
--
ordering cycle after reboot
https://bugs.launchpad.net/bugs/1930203
You received this bug notification because you are a member of SE ("STS")
Sponsors, which is subscribed to the bug report.
--
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
