On Tue, Feb 25, 2025 at 03:40:10PM -0300, Antonio Terceiro wrote:

Well, kernel-related packages cannot ignore the kernel, and this is why
we have QEMU support so those get tested with the kernel from the same
suite as the package being tested.

Ok, the latest failure has some interesting info:

Mar 02 19:00:50 host (controld)[1803]: dlm.service: Referenced but unset environment variable evaluates to an empty string: DLM_CONTROLD_OPTS
Mar 02 19:00:50 host dlm_controld[1803]: 32 dlm_controld 4.3.0 started
Mar 02 19:01:00 host dlm_controld[1803]: 42 cannot find device /dev/misc/dlm-control with minor 123
Mar 02 19:01:00 host systemd[1]: dlm.service: Main process exited, code=exited, status=1/FAILURE
Mar 02 19:01:00 host systemd[1]: dlm.service: Failed with result 'exit-code'. Mar 02 19:01:00 host systemd[1]: Failed to start dlm.service - dlm control daemon.
https://ci.debian.net/packages/d/dlm/unstable/amd64/58436189/

It seems like the service fails after 10 seconds if the device /dev/misc/dlm-control does not exist.

--
Valentin

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Valentin Vidic <vvidic@debian.org> writes:

Ok, the latest failure has some interesting info:

Mar 02 19:00:50 host (controld)[1803]: dlm.service: Referenced but unset environment variable evaluates to an empty string: DLM_CONTROLD_OPTS
Mar 02 19:00:50 host dlm_controld[1803]: 32 dlm_controld 4.3.0 started
Mar 02 19:01:00 host dlm_controld[1803]: 42 cannot find device /dev/misc/dlm-control with minor 123
Mar 02 19:01:00 host systemd[1]: dlm.service: Main process exited, code=exited, status=1/FAILURE
Mar 02 19:01:00 host systemd[1]: dlm.service: Failed with result 'exit-code'. Mar 02 19:01:00 host systemd[1]: Failed to start dlm.service - dlm control daemon.
https://ci.debian.net/packages/d/dlm/unstable/amd64/58436189/

It seems like the service fails after 10 seconds if the device /dev/misc/dlm-control does not exist.

Thanks for the quick upload, Valentin! I kept triggering CI runs until
one finally failed again, but didn't have the time to actually look at the logs. Udev losing the race against dpkg configuring a bunch of packages
is rather unexpected, but apparently can happen from time to time. We
were probably bitten by https://github.com/systemd/systemd/issues/2913
here; what do you think about saving the full journal as a test artifact
in case anything similar crops up in the future?
--
Regards,
Feri.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thu, Mar 06, 2025 at 07:04:54PM +0100, Ferenc Wágner wrote:

Thanks for the quick upload, Valentin! I kept triggering CI runs until
one finally failed again, but didn't have the time to actually look at the logs. Udev losing the race against dpkg configuring a bunch of packages
is rather unexpected, but apparently can happen from time to time. We
were probably bitten by https://github.com/systemd/systemd/issues/2913
here; what do you think about saving the full journal as a test artifact
in case anything similar crops up in the future?

I see, you mean the missing log messages. Yes, that is a good idea if the service is not starting properly, I'll try to add that in git.

--
Valentin

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)