Control: block -1 by 1100418 Control: affects 1100418 + cloud.debian.org On Thu, Mar 13, 2025 at 07:23:24PM +0100, Bastian Blank wrote: > > Yep. One of my earlier updates contains the full debug output from > > systemd. Interestingly, it doesn't seem like systemd logs anything at > > all when it sends a SIGTERM (at least to generators). > > That mail did not make it to the list. I also don't see any code path > that would do explicit SIGTERM.
I think the TERM comes from https://github.com/systemd/systemd/blob/main/src/shared/exec-util.c#L271 The mail is here and the log is at https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=1100338;filename=journal.fail;msg=10, but I don't think that matters anymore. > > You mentioned on IRC that you've observed this on the generic images, > > and I've now observed the same thing. Note that it doesn't occur only > > on first boot; it appears that it can happen on any reboot (or > > presumably on daemon-reload, as generators are executed then as well). > > > > One potentially interesting entry from the debug logs is: > > [ 3.398752] boot-failure1 (sd-gens)[271]: (sd-exec-strv) failed with > > exit status 1. > > Yes. This code bails out on all and every error with exit(1). > > Okay, found it: > > wait_for_terminate_and_check: > | log_full(prio, "%s terminated by signal %s.", strna(name), > signal_to_string(status.si_status)); > | return -EPROTO; > > do_execute: > | r = wait_for_terminate_and_check(…); > | if (r < 0) return r; > > execute_strv: > | r = do_execute(…) > | _exit(r < 0 ? EXIT_FAILURE : r); > > So the SIGABRT of netplan short circuits the error handling and kills > off all other generators. Yep, that's basically the path I was on, too. That explains the intermittent nature of the failures, too, since it's possible for the ABRT to happen after some generators have already completed successfully. I wonder what's going on with netplan-generator... noah
