Source: smcroute Version: 2.4.2-4 Severity: important User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu disco
Hi Joachim, Thanks for the fixes to the smcroute autopkgtests in 2.4.2-4. I've synced this new version into Ubuntu, and the autopkgtests have now passed on all architectures *except* for i386: autopkgtest [11:06:00]: test daemon-init-scripts: [----------------------- 1..11 ok 1 - Starting smcroute (via systemctl): smcroute.service. # ok 2 - smcroute is running (pid 888) ok 3 - stopping smcroute ok 4 - smcroute is really stopped ok 5 - stopping smcroute twice in a row ok 6 - smcroute is really stopped ok 7 - starting smcroute not ok 8 - smcroute is really running # Failed test 'smcroute is really running' # at /tmp/autopkgtest.Fz4BvX/build.HSu/src/debian/tests/daemon-init-scripts line 36. # got: '1' # expected: '0' ok 9 - smcroute pid changed ( != 888) ok 10 - starting smcroute twice in a row ok 11 - smcroute is really running (pid 1147) # Looks like you failed 1 test of 11. autopkgtest [11:06:01]: test daemon-init-scripts: -----------------------] (http://autopkgtest.ubuntu.com/packages/s/smcroute/disco/i386) Considering that the behavior of the tests here is to: check whether smcroute is running, then restart it, then check again if it's running; and only the first check fails; this looks to me like it might be a startup race. Examining the systemd unit for this service, I see that there is definitely a startup race present. smcroute.service.in has: [Service] Type=simple ExecStart=@SBINDIR@/smcrouted -n -s And systemd.service(5) has this to say about Type=simple: In this mode, if the process offers functionality to other processes on the system, its communication channels should be installed before the daemon is started up (e.g. sockets set up by systemd, via socket activation), as systemd will immediately proceed starting follow-up units. So, since you are starting the service and then immediately checking if the service is running (using pgrep), it's possible that this is running into a race because systemd is returning success immediately. But even if that's not the cause of the autopkgtest failure, since smcrouted is a daemon that provides a socket IPC interface, this would still be a bug (race condition) in the startup of the service since systemd can definitely return before smcrouted is listening on the socket. If on the other hand this is NOT the cause of the i386 test failure, then I think the tests will need to have their verbosity increased in order to debug it. Perhaps checking the output of 'service smcrouted status' would be useful here. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org
signature.asc
Description: PGP signature
