On Thu, 2025-02-13 at 22:07 +0100, Lennart Poettering wrote: > On Mo, 10.02.25 19:09, James Feeney (ja...@nurealm.net) wrote: > > > > > > systemd[1]: Got message type=method_call sender=n/a > > destination=org.freedesktop.systemd1 path=/org/freedesktop/systemd1 > > interface=org.freedesktop.systemd1.Manager member=RestartUnit > > cookie=1 reply_cookie=0 signature=ss error-name=n/a > > error-message=n/a > > A client is explicitly asking for the service to be restarted! > > > The basic question is, why does systemd "enqueue" these running > > service units? And, who or what is "sender=n/a", > > "member=RestartUnit", which appears to be the intermediary for this > > "restart/replace" process? What is the trigger? Why are the udhcp > > and the static address service units not effected in the same way? > > Well, it's not systemd that enqueues those restarts on its own. It's > some D-Bus client. use "busctl monitor" to figure out what that might > be. > > you probably have some script or other service thta issues "systemctl > restart" on the service. figure out which one that is. >
Thanks for your message Lennart. Now I have a `sudo busctl capture` file, which I can view in `wireshark`, but I don´t know what to make of it. Except for a few entries at the start, prior to any reference to the device driver module, no other entries list any "Destination". Most of the "Source" entries are from "org.freedesktop.systemd1". The "Info" fields include: PropertiesChaged, UnitNew, JobNew, JobRemoved, DhcpLeaseUpdated - from `dnsmasq`, and UnitRemoved. JobNew appears to correspond to the initiation of each service unit, and JobRemoved appears to correspond to the completion of each service unit. I can see only one set of JobNew and JobRemoved messages for the sit1 service unit, even though in the systemd log it is seen to be killed with sigterm and restarted. I can see two sets of JobNew and JobRemoved messages for the dhcp6c service unit, and I can bracket messages between the first JobRemoved and the following JobNew. But there are only two pairs of intervening messages regarding dhcp6c. Both pairs show org.freedesktop.systemd1 as Source, and both pairs say "ActiveState: active, FreezeState: running, SubState: running". There are no other sorts of D-Bus messages there. So, the conjecture that there is some script or other service issuing a "systemctl restart" appears unsupported by `busctl` during that portion of the D-Bus log. Is there any way to look deeper? Your theory for now is that there must be a D-Bus message forcing a Restart: > systemd[1]: Got message type=method_call sender=n/a > destination=org.freedesktop.systemd1 path=/org/freedesktop/systemd1 > interface=org.freedesktop.systemd1.Manager member=RestartUnit cookie=1 > reply_cookie=0 signature=ss error-name=n/a error-message=n/a How else should I be reading these D-Bus messages? If I look all the way back at the beginning of the D-Bus log, there are three messages that show org.freedesktop.systemd1 as the Destination. In two cases, the Source is shown as ":1.1", and in the last case, the Source is org.freedesktop.DBus. In the first two cases, I do see "Member: LoadUnit, String: dbus-org.freedesktop.home1.service", and then "Member: StartUnit, String: dbus-org.freedesktop.home1.service, String: replace". That certainly sounds suspicious, "replace". What is "dbus-org.freedesktop.home1.service" and who is ":1.1"? Does that appear to be the source of one or the other of the replace/restart events? That seems to answer the question, Who is "sender-n/a", and answer would be ":1.1". But then, the "replace" message, sent by ":1.1", is marked "Method Call", and the Response, sent by org.freedesktop.systemd1, says "Unit dbus-org.freedesktop.home1.service not found". So, it's not obvious that these messages have anything to do with anything. And I do not see any similar messages relating to the sit1 service unit, which also gets the "replace" treatment. Thoughts?
