GNOME Bugzilla – Bug 701229
[MM 0.8] ModemManager.service has Alias=dbus-org.freedesktop.ModemManager1.service - does not exist
Last modified: 2013-08-02 10:12:32 UTC
Version : 0.7.990, in Arch Linux The systemd service file has Alias=dbus-org.freedesktop.ModemManager1.service where there is a file /usr/share/dbus-1/system-services/org.freedesktop.ModemManager1.service but no file /usr/lib/systemd/system/dbus-org.freedesktop.ModemManager1.service This produces an error in the log file and ModemManager fails to start - Failed to load configuration for dbus-org.freedesktop.ModemManager1.service: No such file or directory Copying /usr/lib/systemd/system/ModemManager.service to /usr/lib/systemd/system/dbus-org.freedesktop.ModemManager1.service avoids the error, but I'm not sure what you wanted to do here with "Alias=...". James
Here in my self-compiled MM in F18 it seems to work nice: $ sudo systemctl enable ModemManager ln -s '/usr/lib/systemd/system/ModemManager.service' '/etc/systemd/system/dbus-org.freedesktop.ModemManager1.service' ln -s '/usr/lib/systemd/system/ModemManager.service' '/etc/systemd/system/multi-user.target.wants/ModemManager.service' $ sudo systemctl start ModemManager $ sudo systemctl stop ModemManager $ sudo systemctl disable ModemManager rm '/etc/systemd/system/multi-user.target.wants/ModemManager.service' rm '/etc/systemd/system/dbus-org.freedesktop.ModemManager1.service' Am I missing something?
I have Arch Linux systemd 204-2 and modemmanager 0.7.990-4. I set "sudo systemctl disable ModemManager", then reboot the machine. The log file then reports: May 31 11:26:10 jasper dbus-daemon[347]: dbus[347]: [system] Activating via systemd: service name='org.freedesktop.ModemManager1' unit='dbus-org.freedesktop.ModemManager1.service' May 31 11:26:10 jasper dbus[347]: [system] Activating via systemd: service name='org.freedesktop.ModemManager1' unit='dbus-org.freedesktop.ModemManager1.service' May 31 11:26:10 jasper dbus[347]: [system] Activation via systemd failed for unit 'dbus-org.freedesktop.ModemManager1.service': Unit dbus-org.freedesktop.ModemManager1.service failed to load: No such file or directory. See system logs and 'systemctl status dbus-org.freedesktop.ModemManager1.service' for details. May 31 11:26:10 jasper NetworkManager[343]: <warn> error poking ModemManager: GDBus.Error:org.freedesktop.systemd1.LoadFailed: Unit dbus-org.freedesktop.ModemManager1.service failed to load: No such file or directory. See system logs and 'systemctl status dbus-org.freedesktop.ModemManager1.service' for details. May 31 11:26:10 jasper dbus-daemon[347]: dbus[347]: [system] Activation via systemd failed for unit 'dbus-org.freedesktop.ModemManager1.service': Unit dbus-org.freedesktop.ModemManager1.service failed to load: No such file or directory. See system logs and 'systemctl status dbus-org.freedesktop.ModemManager1.service' for details. May 31 11:26:10 jasper systemd[1]: Got D-Bus request: org.freedesktop.systemd1.Activator.ActivationRequest() on /org/freedesktop/DBus May 31 11:26:10 jasper systemd[1]: Got D-Bus activation request for dbus-org.freedesktop.ModemManager1.service May 31 11:26:10 jasper systemd[1]: Failed to load configuration for dbus-org.freedesktop.ModemManager1.service: No such file or directory May 31 11:26:10 jasper systemd[1]: Trying to enqueue job dbus-org.freedesktop.ModemManager1.service/start/replace May 31 11:26:10 jasper systemd[1]: D-Bus activation failed for dbus-org.freedesktop.ModemManager1.service: Invalid argument The error messages in the log will then repeat continuously, every minite or so: May 31 11:28:10 jasper dbus-daemon[347]: dbus[347]: [system] Activating via systemd: service name='org.freedesktop.ModemManager1' unit='dbus-org.freedesktop.ModemManager1.service' May 31 11:28:10 jasper dbus[347]: [system] Activating via systemd: service name='org.freedesktop.ModemManager1' unit='dbus-org.freedesktop.ModemManager1.service' May 31 11:28:10 jasper dbus[347]: [system] Activation via systemd failed for unit 'dbus-org.freedesktop.ModemManager1.service': Unit dbus-org.freedesktop.ModemManager1.service failed to load: No such file or directory. See system logs and 'systemctl status dbus-org.freedesktop.ModemManager1.service' for details. May 31 11:28:10 jasper NetworkManager[343]: <warn> error poking ModemManager: GDBus.Error:org.freedesktop.systemd1.LoadFailed: Unit dbus-org.freedesktop.ModemManager1.service failed to load: No such file or directory. See system logs and 'systemctl status dbus-org.freedesktop.ModemManager1.service' for details. May 31 11:28:10 jasper dbus-daemon[347]: dbus[347]: [system] Activation via systemd failed for unit 'dbus-org.freedesktop.ModemManager1.service': Unit dbus-org.freedesktop.ModemManager1.service failed to load: No such file or directory. See system logs and 'systemctl status dbus-org.freedesktop.ModemManager1.service' for details. May 31 11:28:10 jasper systemd[1]: Got D-Bus request: org.freedesktop.systemd1.Activator.ActivationRequest() on /org/freedesktop/DBus May 31 11:28:10 jasper systemd[1]: Got D-Bus activation request for dbus-org.freedesktop.ModemManager1.service May 31 11:28:10 jasper systemd[1]: Failed to load configuration for dbus-org.freedesktop.ModemManager1.service: No such file or directory May 31 11:28:10 jasper systemd[1]: Trying to enqueue job dbus-org.freedesktop.ModemManager1.service/start/replace May 31 11:28:10 jasper systemd[1]: D-Bus activation failed for dbus-org.freedesktop.ModemManager1.service: Invalid argument May 31 11:28:12 jasper systemd[1]: Got D-Bus request: org.freedesktop.DBus.NameOwnerChanged() on /org/freedesktop/DBus May 31 11:28:13 jasper systemd[1]: Got D-Bus request: org.freedesktop.DBus.NameOwnerChanged() on /org/freedesktop/DBus May 31 11:29:20 jasper systemd[1]: Running GC... May 31 11:29:20 jasper systemd[1]: Collecting dbus-org.freedesktop.ModemManager1.service Notice that the error message is for 'dbus-org.freedesktop.ModemManager1.service', and _not_ for ModemManager.service. Perhaps ask, why is there an "Alias" line in the ModemManager.service unit file for a non-existant dbus-org.freedesktop.ModemManager1.service unit file? But if, then, ModemManager is enabled, "sudo systemctl enable ModemManager", which gives ln -s '/usr/lib/systemd/system/ModemManager.service' '/etc/systemd/system/dbus-org.freedesktop.ModemManager1.service' ln -s '/usr/lib/systemd/system/ModemManager.service' '/etc/systemd/system/multi-user.target.wants/ModemManager.service' the log then reports: May 31 12:00:06 jasper systemd[1]: Accepted connection on private bus. May 31 12:00:06 jasper systemd[1]: Running GC... May 31 12:00:06 jasper systemd[1]: Collecting dbus-org.freedesktop.ModemManager1.service May 31 12:00:06 jasper systemd[1]: Got D-Bus request: org.freedesktop.systemd1.Manager.EnableUnitFiles() on /org/freedesktop/systemd1 May 31 12:00:06 jasper systemd[1]: Looking for unit files in (higher priority first): May 31 12:00:06 jasper systemd[1]: #011/etc/systemd/system May 31 12:00:06 jasper systemd[1]: #011/run/systemd/system May 31 12:00:06 jasper systemd[1]: #011/usr/local/lib/systemd/system May 31 12:00:06 jasper systemd[1]: #011/usr/lib/systemd/system May 31 12:00:06 jasper systemd[1]: SysV init scripts and rcN.d links support disabled May 31 12:00:06 jasper systemd[1]: Got D-Bus request: org.freedesktop.systemd1.Manager.Reload() on /org/freedesktop/systemd1 May 31 12:00:10 jasper dbus-daemon[347]: dbus[347]: [system] Activating via systemd: service name='org.freedesktop.ModemManager1' unit='dbus-org.freedesktop.ModemManager1.service' May 31 12:00:10 jasper dbus[347]: [system] Activating via systemd: service name='org.freedesktop.ModemManager1' unit='dbus-org.freedesktop.ModemManager1.service' May 31 12:00:10 jasper systemd[1]: Got D-Bus request: org.freedesktop.systemd1.Activator.ActivationRequest() on /org/freedesktop/DBus May 31 12:00:10 jasper systemd[1]: Got D-Bus activation request for dbus-org.freedesktop.ModemManager1.service May 31 12:00:10 jasper systemd[1]: Trying to enqueue job ModemManager.service/start/replace May 31 12:00:10 jasper systemd[1]: Installed new job ModemManager.service/start as 624 May 31 12:00:10 jasper systemd[1]: Enqueued job ModemManager.service/start as 624 May 31 12:00:10 jasper systemd[1]: Starting Modem Manager... May 31 12:00:10 jasper systemd[1]: About to execute: /usr/sbin/ModemManager May 31 12:00:10 jasper systemd[1]: Forked /usr/sbin/ModemManager as 1460 May 31 12:00:10 jasper systemd[1]: ModemManager.service changed dead -> start May 31 12:00:10 jasper systemd[1]: Set up jobs progress timerfd. May 31 12:00:10 jasper systemd[1460]: Executing: /usr/sbin/ModemManager May 31 12:00:10 jasper ModemManager[1460]: <info> ModemManager (version 0.7.990) starting... May 31 12:00:10 jasper systemd[1]: Got D-Bus request: org.freedesktop.DBus.NameOwnerChanged() on /org/freedesktop/DBus May 31 12:00:10 jasper dbus-daemon[347]: dbus[347]: [system] Successfully activated service 'org.freedesktop.ModemManager1' May 31 12:00:10 jasper dbus[347]: [system] Successfully activated service 'org.freedesktop.ModemManager1' May 31 12:00:10 jasper systemd[1]: Got D-Bus request: org.freedesktop.DBus.NameOwnerChanged() on /org/freedesktop/DBus May 31 12:00:10 jasper systemd[1]: ModemManager.service's D-Bus name org.freedesktop.ModemManager1 now registered by :1.50 May 31 12:00:10 jasper systemd[1]: ModemManager.service changed start -> running May 31 12:00:10 jasper systemd[1]: Job ModemManager.service/start finished, result=done May 31 12:00:10 jasper systemd[1]: Started Modem Manager. May 31 12:00:10 jasper systemd[1]: Closed jobs progress timerfd. May 31 12:00:10 jasper NetworkManager[343]: <info> ModemManager disappeared from bus May 31 12:00:10 jasper NetworkManager[343]: <info> ModemManager available in the bus So, that is all good and well, but entirely beside the point - that being the "useless" activity trying to start a non-existent and/or a disabled service and the "spamming" of the log file in the process. Perhaps ModemManager has found a bug in systemd? Or is the ModemManager unit service file not properly constructed? And, there is that whole interaction with D-Bus, which complicates this process. Notice that it is "dbus-daemon" which sets-off the whole failed process: dbus-daemon[347]: dbus[347]: [system] Activating via systemd: service name='org.freedesktop.ModemManager1' unit='dbus-org.freedesktop.ModemManager1.service' It is the file "/usr/share/dbus-1/system-services/org.freedesktop.ModemManager1.service" which makes reference to a non-existent file "SystemdService=dbus-org.freedesktop.ModemManager1.service". My instinct would be to either create the file "dbus-org.freedesktop.ModemManager1.service", perhaps as a copy of ModemManager.service, in /usr/lib/systemd/system, or to change the line in the file "/usr/share/dbus-1/system-services/org.freedesktop.ModemManager1.service" to read "SystemdService=ModemManager.service". Notice that the process "sudo systemctl enable ModemManager" explicitly creates a file-entry named "dbus-org.freedesktop.ModemManager1.service" in /etc/systemd/system/, and thus the cause of the error - "No such file or directory" - is resolved. The file is actually an explicit link to "/usr/lib/systemd/system/ModemManager.service". So I'm guessing that one solution would be to create an explicit file or link named "dbus-org.freedesktop.ModemManager1.service" in /usr/lib/systemd/system/. Alternatively, I suspect that "/usr/share/dbus-1/system-services/org.freedesktop.ModemManager1.service" could reference "ModemManager.service" explicitly. For some reason, subsequently _disabling_ ModemManager, "sudo systemctl disable ModemManager", which explicitly removes the file/link "/etc/systemd/system/dbus-org.freedesktop.ModemManager1.service", does not re-trigger the continuous process of failed attempts to start dbus-org.freedesktop.ModemManager1.service. I notice that the log reports: May 31 12:43:58 jasper systemd[1]: Accepted connection on private bus. May 31 12:43:58 jasper systemd[1]: Running GC... May 31 12:43:58 jasper systemd[1]: Got D-Bus request: org.freedesktop.systemd1.Manager.DisableUnitFiles() on /org/freedesktop/systemd1 May 31 12:43:58 jasper systemd[1]: Looking for unit files in (higher priority first): May 31 12:43:58 jasper systemd[1]: #011/etc/systemd/system May 31 12:43:58 jasper systemd[1]: #011/run/systemd/system May 31 12:43:58 jasper systemd[1]: #011/usr/local/lib/systemd/system May 31 12:43:58 jasper systemd[1]: #011/usr/lib/systemd/system May 31 12:43:58 jasper systemd[1]: SysV init scripts and rcN.d links support disabled May 31 12:43:58 jasper systemd[1]: Got D-Bus request: org.freedesktop.systemd1.Manager.Reload() on /org/freedesktop/systemd1 May 31 12:43:58 jasper systemd[1]: Reloading. Perhaps "org.freedesktop.systemd1.Manager.DisableUnitFiles()" is smart enough to put a stop to attempts to re-start dbus-org.freedesktop.ModemManager1.service. But then, failing to do this immediately after boot-up, is that a bug with D-Bus? James
BTW, I am noticing that _all_ of the other files "dbus-org.freedesktop.<...>" in /usr/lib/systemd/system/ are symbolic links to other files in that directory. Is there suppose to simply be a symbolic link "dbus-org.freedesktop.ModemManager1.service" to "ModemManager.service"? But then, none of the other "dbus-org.freedesktop.<...>" referenced files have an "Alias=" line. The "Alias=" line is probably not the cause of any error though, which seemed to begin with the file "/usr/share/dbus-1/system-services/org.freedesktop.ModemManager1.service" and the reference from "SystemdService=dbus-org.freedesktop.ModemManager1.service". As I understand, the existence of these unit service files, either as links or real files, is completely distinct from their state being as "enabled" or "disabled", which is a consequence of links in the "<...>.target.wants" directories. So then, it would do no harm to have these "dbus-org.freedesktop.<...>" links in /usr/lib/systemd/system/, but I also do not understand their necessity. Is there some reason that the form of the file name matter, prefixing all of them with "dbus-org.freedesktop.<...>"? James
I *think* the whole dbus-org thing is moot now, since systemd has handled dbus activation for a really long time, and systemd will disallow dbus-activation of a service that's disabled. I believe those bits of the MM systemd support were from before systemd handled dbus-activation, to ensure that when systemd was enabled, dbus didn't try to autostart the service (the Exec=/bin/false) but systemd knew the real path since it was given in the system unit files. I think we can actually just consolidate down to a single dbus file now, which would be the .service.nosystemd.in and remove the Alias and SystemdService lines from the dbus conf file.
(In reply to comment #4) > I *think* the whole dbus-org thing is moot now, since systemd has handled dbus > activation for a really long time, and systemd will disallow dbus-activation of > a service that's disabled. > > I believe those bits of the MM systemd support were from before systemd handled > dbus-activation, to ensure that when systemd was enabled, dbus didn't try to > autostart the service (the Exec=/bin/false) but systemd knew the real path > since it was given in the system unit files. > > I think we can actually just consolidate down to a single dbus file now, which > would be the .service.nosystemd.in and remove the Alias and SystemdService > lines from the dbus conf file. I tried that, and it doesn't seem to work. If I disable the ModemManager service, DBus clients can still request to autostart it...
So my point of view is that our current approach is close to the correct one. The ModemManager systemd service can be enabled or disabled: * If it is enabled, NetworkManager will succeed getting ModemManager dbus-activated, as systemd allows it. * If it is disabled, NetworkManager will fail to dbus-activate ModemManager (NM tries to poke the MM service, dbus-daemon requests to activate it to systemd, and systemd cannot activate it because it's disabled). The logs shown about the missing dbus-.. file are actually because the ModemManager service is not enabled: error: couldn't create manager: Error calling StartServiceByName for org.freedesktop.ModemManager1: GDBus.Error:org.freedesktop.systemd1.LoadFailed: Unit dbus-org.freedesktop.ModemManager1.service failed to load: No such file or directory. See system logs and 'systemctl status dbus-org.freedesktop.ModemManager1.service' for details. That message is because the ModemManager service is disabled, and dbus-activation is not possible. Now, the Alias= string allows us to have a service that, in addition to being dbus-activated can be enabled or disabled. Whenever the MM service is enabled, the 'dbus-org.freedesktop.ModemManager1.service' link is created and we can allow dbus-activation. When the service is disabled, the 'dbus-org.freedesktop.ModemManager1.service' link is removed and dbus-activation is no longer possible. The periodic errors in the log are maybe something that we can improve. If NetworkManager is not able to start ModemManager, it will retry after 120s. If we didn't have this timeout, and the ModemManager service is stopped, disabled and re-enabled, NetworkManager would never re-poke and restart ModemManager, even if it was enabled back again. Arguably, if the user stopped, disabled and re-enabled it, she could also start the service again herself, instead of letting NetworkManager request it. We could therefore remove the 120s timeout and never retry to dbus-activate ModemManager if we detect a DBus activation failure reported by systemd (GDBus.Error:org.freedesktop.systemd1.LoadFailed), and only leave the 120s retry timeout for other errors. This could be a good compromise... Dan, what do you think?
(In reply to comment #5) > (In reply to comment #4) > > I *think* the whole dbus-org thing is moot now, since systemd has handled dbus > > activation for a really long time, and systemd will disallow dbus-activation of > > a service that's disabled. > > > > I believe those bits of the MM systemd support were from before systemd handled > > dbus-activation, to ensure that when systemd was enabled, dbus didn't try to > > autostart the service (the Exec=/bin/false) but systemd knew the real path > > since it was given in the system unit files. > > > > I think we can actually just consolidate down to a single dbus file now, which > > would be the .service.nosystemd.in and remove the Alias and SystemdService > > lines from the dbus conf file. > > I tried that, and it doesn't seem to work. If I disable the ModemManager > service, DBus clients can still request to autostart it... This is expected, and is a system thing. 'disable' ignores systemd autostart, but the 'mask' command does not. I believe 'disable' simply stops the service from being started by default, but it doesn't stop it from being started explicitly. You need to 'mask' the service to ensure that it never ever starts by default or by bus activation. It's something we've had long, long conversations with the systemd people about but they've declined to fix.
Wow I screwed that up. To clarify: This is expected, and is a *systemd* thing. 'disable' ignores *dbus* autostart, but the 'mask' command does not. I believe 'disable' simply stops the service from being started by default, but it doesn't stop it from being started explicitly.
So we can remove the Alias= line and let users 'mask' instead 'disable' and that would be all good?
Created attachment 246107 [details] [review] Patch. 'mask' and 'unmask' seem to do the trick, they also forbid dbus-activated starts. See attached patch for the simplified systemd service setup.
(In reply to comment #9) > So we can remove the Alias= line and let users 'mask' instead 'disable' and > that would be all good? Yes, with the caveat that you can then never start ModemManager *in any way* through system or dbus if MM is masked. But that's the purpose of 'mask'. You only run afoul of 'mask' if you want to (a) stop MM for a short time but (b) still have MM run on the next boot. There's no way to do this with systemd.
Review of attachment 246107 [details] [review]: Looks good to me.
I pushed the change now. I also updated the debugging tips to reflect that the service needs to get masked if you need to run manually: https://live.gnome.org/NetworkManager/ModemManager/Debugging Will mark it as fixed.
guys, this is all wrong. "systemctl enable" is supposed to enable a service with its default triggers. What those triggers are, is up to the developer. It could be: on-boot, on-hardware, on-bus, on-socket or any combination thereof. However, it does *not* imply activation on-boot. On-boot is just one option of many really. For NM triggers for on-boot + on-bus + on-hardware are a good choice (and is how this is implemented, modulo the on-hardware thing). For MM on-bus + on-hardware sounds like the right choice, since it really makes no sense to run this at boot if nobody uses it and no hw is available for it. "systemctl mask" is a tool for gurus, for hackers, for developers, and admins who (usually temporarily) want to exclude some service from starting. it never should be part of clean codepaths. So, please undo this change. ModemManager should be hooked in from the bus service via the original alias. And if dbus then is too noisy, then dbus should be fixed. Also see: https://bugzilla.redhat.com/show_bug.cgi?id=948404 I'd really like to reopne this bug, but I apparently lack the privs for that...
This is the wrong commit btw: http://cgit.freedesktop.org/ModemManager/ModemManager/commit/?id=91898aa8b0bb8164b61e84ae68534c38cebb1482 (Side note: as I see previously there were two different dbus activation snippets dropped in, one for systemd-less systems and one for systemd systems. The stuff is actually designed so that you can use the same file on both kinds of system. On systemd systems the SystemdService= property will be looked for, on on-systemd systems Exec= is looked for instead.)
To make this very clear: "systemctl disable" should do exactly what the name suggests, disable the service, so that it is not activated anymore automatically, neither on-boot, nor on-hardware, nor on-bus, nor on-socket. With this patch you broke that, so that "systemctl enable"/"systemctl disable" could be used to turn on/off on-boot activation, but bus activation would always and unconditionally happen. And that's a bad thing. We want "disabling" to do exactly what the admins wants, and that is to make sure it is not run automatically anymore.
Could somebody with the appropriate privileges please reopen this bug?
So, is the Alias= setup (the one we had before the commit you pointed out) the correct way to have dbus-activated services properly disabled? Without the Alias, systemd disable would make the service not activated during on-boot, but it wouldn't forbid having it activated via dbus-activation. Is there maybe a simpler way to achieve the same? The other issue was the logs; when that setup with the Alias= file was in place, there were tons of logs in syslog regarding failure of service activation, from all systemd, dbus-daemon and NM itself. The problem with the logs is even a bit worse, because NM currently retries every 30s to reactivate the service by ping-ing the MM interface (for the case when MM is not managed by systemd). I understand that when using systemd the life cycle of the MM service would be controlled by systemd (e.g. it will restart MM if MM crashes and the service is enabled). So we should probably make that 30s retry timeout only applicable when MM is *not* managed by systemd. What I don't know is if there is any way for NetworkManager to detect that at runtime, or if we should just #ifdef the retries logic based on a new configure switch in NM. If we do this, NM will never try to ping the MM interface, just follow name-owner changes and only use MM if it's found. And regarding on-hardware activation... that would be nice to have. We already have udev rules in place to tag devices which need to get probed by ModemManager. If I'm not mistaken, we could then place an additional rule like: TAG+="systemd", ENV{SYSTEMD_WANTS}="modem.target" which would be applicable in the same cases as our own udev tag, and that new target would control whether the ModemManager service is started or not... right?
(In reply to comment #18) > So, is the Alias= setup (the one we had before the commit you pointed out) the > correct way to have dbus-activated services properly disabled? Without the > Alias, systemd disable would make the service not activated during on-boot, but > it wouldn't forbid having it activated via dbus-activation. Is there maybe a > simpler way to achieve the same? Yes, the Alias= indirection is how we recommend making bus services "disabable". When we move to kdbus we will introduce a new unit type ".busname" or so, which can be established at any time without any such hackery, which should solve the thing cleanl. In the meantime the alias trick is what we recommend. > > The other issue was the logs; when that setup with the Alias= file was in > place, there were tons of logs in syslog regarding failure of service > activation, from all systemd, dbus-daemon and NM itself. systemd shouldn't really log about this unless you enable debug logging. dbus daemon certainly does. But that's something to fix there. That said, if you mask MM with "systemctl mask" things certainly are not any quieter... > The problem with the logs is even a bit worse, because NM currently retries > every 30s to reactivate the service by ping-ing the MM interface (for the case > when MM is not managed by systemd). I understand that when using systemd the > life cycle of the MM service would be controlled by systemd (e.g. it will > restart MM if MM crashes and the service is enabled). So we should probably > make that 30s retry timeout only applicable when MM is *not* managed by > systemd. What I don't know is if there is any way for NetworkManager to detect > that at runtime, or if we should just #ifdef the retries logic based on a new > configure switch in NM. If we do this, NM will never try to ping the MM > interface, just follow name-owner changes and only use MM if it's found. We don't automatically restart daemons if the fail, unless that is configured for the specific service using Restart= or so. If this is a logging issue, we should fix this as a logging problem, i.e. fix dbus to downgrade the messages to debug or so. > And regarding on-hardware activation... that would be nice to have. We already > have udev rules in place to tag devices which need to get probed by > ModemManager. If I'm not mistaken, we could then place an additional rule like: > TAG+="systemd", ENV{SYSTEMD_WANTS}="modem.target" Correct. I'd even be willing to ship the modem.target part and its udev rules in systemd, to make this generically available. However, that probably only if the rules are somewhat simple and generic. (i.e. checking for a thousand different VID/PID is probably something that should better stay in MM, and not be done in systemd) > which would be applicable in the same cases as our own udev tag, and that new > target would control whether the ModemManager service is started or not... > right? Yes! Looks good!
(In reply to comment #19) > (In reply to comment #18) > > So, is the Alias= setup (the one we had before the commit you pointed out) the > > correct way to have dbus-activated services properly disabled? Without the > > Alias, systemd disable would make the service not activated during on-boot, but > > it wouldn't forbid having it activated via dbus-activation. Is there maybe a > > simpler way to achieve the same? > > Yes, the Alias= indirection is how we recommend making bus services > "disabable". > > When we move to kdbus we will introduce a new unit type ".busname" or so, which > can be established at any time without any such hackery, which should solve the > thing cleanl. In the meantime the alias trick is what we recommend. Obviously Lennert is the expert here... I'm getting confused between all the things we do in different places, between disabling autostart *completely* (like we do for NM, which is what I thought the Alias stuff plus Exec=/dev/null was for) and only making sure that a disabled service can't be autostarted. > > > > The other issue was the logs; when that setup with the Alias= file was in > > place, there were tons of logs in syslog regarding failure of service > > activation, from all systemd, dbus-daemon and NM itself. > > systemd shouldn't really log about this unless you enable debug logging. dbus > daemon certainly does. But that's something to fix there. That said, if you > mask MM with "systemctl mask" things certainly are not any quieter... But it does... unless I've enabled ebug logging, which I'm pretty sure I haven't. Jun 17 10:49:21 dcbw dbus[413]: [system] Activation via systemd failed for unit 'dbus-org.freedesktop.ModemManager1.service': Unit dbus-org.freedesktop.ModemManager1.service failed to load: No such file or directory. See system logs and 'systemctl status dbus-org.freedesktop.ModemManager1.service' for details. > > The problem with the logs is even a bit worse, because NM currently retries > > every 30s to reactivate the service by ping-ing the MM interface (for the case > > when MM is not managed by systemd). I understand that when using systemd the > > life cycle of the MM service would be controlled by systemd (e.g. it will > > restart MM if MM crashes and the service is enabled). So we should probably > > make that 30s retry timeout only applicable when MM is *not* managed by > > systemd. What I don't know is if there is any way for NetworkManager to detect > > that at runtime, or if we should just #ifdef the retries logic based on a new > > configure switch in NM. If we do this, NM will never try to ping the MM > > interface, just follow name-owner changes and only use MM if it's found. > > We don't automatically restart daemons if the fail, unless that is configured > for the specific service using Restart= or so. Hmm, we'd want to ensure this ModemManager keeps getting restarted. Just because it crashes once doesn't mean it shouldn't get restarted; though I'll assume that systemd has some kind of respawns-too-fast logic. > If this is a logging issue, we should fix this as a logging problem, i.e. fix > dbus to downgrade the messages to debug or so. > > > And regarding on-hardware activation... that would be nice to have. We already > > have udev rules in place to tag devices which need to get probed by > > ModemManager. If I'm not mistaken, we could then place an additional rule like: > > TAG+="systemd", ENV{SYSTEMD_WANTS}="modem.target" > > Correct. I'd even be willing to ship the modem.target part and its udev rules > in systemd, to make this generically available. However, that probably only if > the rules are somewhat simple and generic. (i.e. checking for a thousand > different VID/PID is probably something that should better stay in MM, and not > be done in systemd) They're probably too big for systemd. There's a lot of VID/PID tagging going on, and we want to keep all the rules for specific devices in the same place. But, what we could do, is potentially ship the MM_CANDIDATE rules with systemd, since those are the things that *might* be modems and MM should be started to probe. Those are separate from the VID/PID tagging rules and are quite small.
> > > And regarding on-hardware activation... that would be nice to have. We already > > > have udev rules in place to tag devices which need to get probed by > > > ModemManager. If I'm not mistaken, we could then place an additional rule like: > > > TAG+="systemd", ENV{SYSTEMD_WANTS}="modem.target" > > > > Correct. I'd even be willing to ship the modem.target part and its udev rules > > in systemd, to make this generically available. However, that probably only if > > the rules are somewhat simple and generic. (i.e. checking for a thousand > > different VID/PID is probably something that should better stay in MM, and not > > be done in systemd) > > They're probably too big for systemd. There's a lot of VID/PID tagging going > on, and we want to keep all the rules for specific devices in the same place. > > But, what we could do, is potentially ship the MM_CANDIDATE rules with systemd, > since those are the things that *might* be modems and MM should be started to > probe. Those are separate from the VID/PID tagging rules and are quite small. For the systemd on-hardware activation we would only need to duplicate the MM_CANDIDATE rules with a new rules for systemd. If Lennart can include those systemd-specific rules directly in systemd, that's a plus. I'll play with all this during the following week.
> > > The problem with the logs is even a bit worse, because NM currently retries > > > every 30s to reactivate the service by ping-ing the MM interface (for the case > > > when MM is not managed by systemd). I understand that when using systemd the > > > life cycle of the MM service would be controlled by systemd (e.g. it will > > > restart MM if MM crashes and the service is enabled). So we should probably > > > make that 30s retry timeout only applicable when MM is *not* managed by > > > systemd. What I don't know is if there is any way for NetworkManager to detect > > > that at runtime, or if we should just #ifdef the retries logic based on a new > > > configure switch in NM. If we do this, NM will never try to ping the MM > > > interface, just follow name-owner changes and only use MM if it's found. > > > > We don't automatically restart daemons if the fail, unless that is configured > > for the specific service using Restart= or so. > > Hmm, we'd want to ensure this ModemManager keeps getting restarted. Just > because it crashes once doesn't mean it shouldn't get restarted; though I'll > assume that systemd has some kind of respawns-too-fast logic. > I haven't seen any configuration in systemd to handle this issue. For what I can see, we could do the following: Restart=on-abort RestartSec=30 That RestartSec=30 will make the restart of the service delayed 30s just after the crash, but that also applies to the first crash. What we would want to have is: * MM gets restarted right away if it exits unexpectedly. * If that restart fails, e.g. MM crashes again, we wait 30s before retrying the restart. Lennart, is there currently some way to have this? Dan, is there really a need for this logic? Is this a 'just in case' situation? Or have we already seen in the past new modems making MM crash badly? From my POV, if we have modems making MM crash badly during startup, we should just try to fix the crasher. If a user finds a MM crash loop, instead of keeping the crash loop hidden behind 30s-delayed-restarts, the user should really just disable the MM service all together until the fix is applied. On a side note, I now wonder how the lifecycle of NetworkManager itself is managed, as I didn't see any Restart= line in the service file. Will it be restarted by dbus-activation? Which process is actively requesting dbus-activation of NM?
I reverted the commit that lennart pointed out now, and also merged the systemd/nosystemd dbus files that we had, as he suggested.
(In reply to comment #22) > > > > The problem with the logs is even a bit worse, because NM currently retries > > > > every 30s to reactivate the service by ping-ing the MM interface (for the case > > > > when MM is not managed by systemd). I understand that when using systemd the > > > > life cycle of the MM service would be controlled by systemd (e.g. it will > > > > restart MM if MM crashes and the service is enabled). So we should probably > > > > make that 30s retry timeout only applicable when MM is *not* managed by > > > > systemd. What I don't know is if there is any way for NetworkManager to detect > > > > that at runtime, or if we should just #ifdef the retries logic based on a new > > > > configure switch in NM. If we do this, NM will never try to ping the MM > > > > interface, just follow name-owner changes and only use MM if it's found. > > > > > > We don't automatically restart daemons if the fail, unless that is configured > > > for the specific service using Restart= or so. > > > > Hmm, we'd want to ensure this ModemManager keeps getting restarted. Just > > because it crashes once doesn't mean it shouldn't get restarted; though I'll > > assume that systemd has some kind of respawns-too-fast logic. > > > > I haven't seen any configuration in systemd to handle this issue. For what I > can see, we could do the following: > > Restart=on-abort > RestartSec=30 > > That RestartSec=30 will make the restart of the service delayed 30s just after > the crash, but that also applies to the first crash. What we would want to have > is: > * MM gets restarted right away if it exits unexpectedly. > * If that restart fails, e.g. MM crashes again, we wait 30s before retrying > the restart. > > Lennart, is there currently some way to have this? > > Dan, is there really a need for this logic? Is this a 'just in case' situation? Just in case. > Or have we already seen in the past new modems making MM crash badly? From my > POV, if we have modems making MM crash badly during startup, we should just try > to fix the crasher. If a user finds a MM crash loop, instead of keeping the > crash loop hidden behind 30s-delayed-restarts, the user should really just > disable the MM service all together until the fix is applied. The restart suggestion was just a thought, I think your ideas here about restart after crash are perfectly reasonable too. Most of the crash problems we had were with 0.6 anyway where the probing logic is not as robust. I'm fine with whatever you think best here. > On a side note, I now wonder how the lifecycle of NetworkManager itself is > managed, as I didn't see any Restart= line in the service file. Will it be > restarted by dbus-activation? Which process is actively requesting > dbus-activation of NM? We'd rather *not* have NM restarted via dbus activation, at least not until the next release where it handles restart situations better by smoothly taking over existing config. Stuff can start NM by dbus activation if it just makes method calls on NM but doesn't check whether NM is running first or not. That means that if you've 'systemctl stop NetworkManager' then the GNOME Shell applet might make a dbus call to NM and restart NM underneath you. That was partially due to bugs in libnm-glib not checking whether NM was running or not, but the problem is not specific to libnm-glib at all.
(In reply to comment #24) > (In reply to comment #22) > > > > > The problem with the logs is even a bit worse, because NM currently retries > > > > > every 30s to reactivate the service by ping-ing the MM interface (for the case > > > > > when MM is not managed by systemd). I understand that when using systemd the > > > > > life cycle of the MM service would be controlled by systemd (e.g. it will > > > > > restart MM if MM crashes and the service is enabled). So we should probably > > > > > make that 30s retry timeout only applicable when MM is *not* managed by > > > > > systemd. What I don't know is if there is any way for NetworkManager to detect > > > > > that at runtime, or if we should just #ifdef the retries logic based on a new > > > > > configure switch in NM. If we do this, NM will never try to ping the MM > > > > > interface, just follow name-owner changes and only use MM if it's found. > > > > > > > > We don't automatically restart daemons if the fail, unless that is configured > > > > for the specific service using Restart= or so. > > > > > > Hmm, we'd want to ensure this ModemManager keeps getting restarted. Just > > > because it crashes once doesn't mean it shouldn't get restarted; though I'll > > > assume that systemd has some kind of respawns-too-fast logic. > > > > > > > I haven't seen any configuration in systemd to handle this issue. For what I > > can see, we could do the following: > > > > Restart=on-abort > > RestartSec=30 > > > > That RestartSec=30 will make the restart of the service delayed 30s just after > > the crash, but that also applies to the first crash. What we would want to have > > is: > > * MM gets restarted right away if it exits unexpectedly. > > * If that restart fails, e.g. MM crashes again, we wait 30s before retrying > > the restart. > > > > Lennart, is there currently some way to have this? > > > > Dan, is there really a need for this logic? Is this a 'just in case' situation? > > Just in case. > > > Or have we already seen in the past new modems making MM crash badly? From my > > POV, if we have modems making MM crash badly during startup, we should just try > > to fix the crasher. If a user finds a MM crash loop, instead of keeping the > > crash loop hidden behind 30s-delayed-restarts, the user should really just > > disable the MM service all together until the fix is applied. > > The restart suggestion was just a thought, I think your ideas here about > restart after crash are perfectly reasonable too. Most of the crash problems > we had were with 0.6 anyway where the probing logic is not as robust. I'm fine > with whatever you think best here. > I would then use just the following: Restart=on-abort If MM crashes, systemd will restart it right away. If that leads to a loop of MM crash/reboot, then the user should just disable the service until a fix is released.
(In reply to comment #20) > (In reply to comment #19) > > (In reply to comment #18) > > > So, is the Alias= setup (the one we had before the commit you pointed out) the > > > correct way to have dbus-activated services properly disabled? Without the > > > Alias, systemd disable would make the service not activated during on-boot, but > > > it wouldn't forbid having it activated via dbus-activation. Is there maybe a > > > simpler way to achieve the same? > > > > Yes, the Alias= indirection is how we recommend making bus services > > "disabable". > > > > When we move to kdbus we will introduce a new unit type ".busname" or so, which > > can be established at any time without any such hackery, which should solve the > > thing cleanl. In the meantime the alias trick is what we recommend. > > Obviously Lennert is the expert here... I'm getting confused between all the > things we do in different places, between disabling autostart *completely* > (like we do for NM, which is what I thought the Alias stuff plus Exec=/dev/null > was for) and only making sure that a disabled service can't be autostarted. > > > > > > > The other issue was the logs; when that setup with the Alias= file was in > > > place, there were tons of logs in syslog regarding failure of service > > > activation, from all systemd, dbus-daemon and NM itself. > > > > systemd shouldn't really log about this unless you enable debug logging. dbus > > daemon certainly does. But that's something to fix there. That said, if you > > mask MM with "systemctl mask" things certainly are not any quieter... > > But it does... unless I've enabled ebug logging, which I'm pretty sure I > haven't. > > Jun 17 10:49:21 dcbw dbus[413]: [system] Activation via systemd failed for unit > 'dbus-org.freedesktop.ModemManager1.service': Unit > dbus-org.freedesktop.ModemManager1.service failed to load: No such file or > directory. See system logs and 'systemctl status > dbus-org.freedesktop.ModemManager1.service' for details. > > > > The problem with the logs is even a bit worse, because NM currently retries > > > every 30s to reactivate the service by ping-ing the MM interface (for the case > > > when MM is not managed by systemd). I understand that when using systemd the > > > life cycle of the MM service would be controlled by systemd (e.g. it will > > > restart MM if MM crashes and the service is enabled). So we should probably > > > make that 30s retry timeout only applicable when MM is *not* managed by > > > systemd. What I don't know is if there is any way for NetworkManager to detect > > > that at runtime, or if we should just #ifdef the retries logic based on a new > > > configure switch in NM. If we do this, NM will never try to ping the MM > > > interface, just follow name-owner changes and only use MM if it's found. > > > > We don't automatically restart daemons if the fail, unless that is configured > > for the specific service using Restart= or so. > > Hmm, we'd want to ensure this ModemManager keeps getting restarted. Just > because it crashes once doesn't mean it shouldn't get restarted; though I'll > assume that systemd has some kind of respawns-too-fast logic. > > > If this is a logging issue, we should fix this as a logging problem, i.e. fix > > dbus to downgrade the messages to debug or so. > > > > > And regarding on-hardware activation... that would be nice to have. We already > > > have udev rules in place to tag devices which need to get probed by > > > ModemManager. If I'm not mistaken, we could then place an additional rule like: > > > TAG+="systemd", ENV{SYSTEMD_WANTS}="modem.target" > > > > Correct. I'd even be willing to ship the modem.target part and its udev rules > > in systemd, to make this generically available. However, that probably only if > > the rules are somewhat simple and generic. (i.e. checking for a thousand > > different VID/PID is probably something that should better stay in MM, and not > > be done in systemd) > > They're probably too big for systemd. There's a lot of VID/PID tagging going > on, and we want to keep all the rules for specific devices in the same place. > > But, what we could do, is potentially ship the MM_CANDIDATE rules with systemd, > since those are the things that *might* be modems and MM should be started to > probe. Those are separate from the VID/PID tagging rules and are quite small.
(Sorry for the comment that just included the paste, i really hate my new keyboard, it has the enter key at the wrong spot). (In reply to comment #20) > > systemd shouldn't really log about this unless you enable debug logging. dbus > > daemon certainly does. But that's something to fix there. That said, if you > > mask MM with "systemctl mask" things certainly are not any quieter... > > But it does... unless I've enabled ebug logging, which I'm pretty sure I > haven't. > > Jun 17 10:49:21 dcbw dbus[413]: [system] Activation via systemd failed for unit > 'dbus-org.freedesktop.ModemManager1.service': Unit > dbus-org.freedesktop.ModemManager1.service failed to load: No such file or > directory. See system logs and 'systemctl status > dbus-org.freedesktop.ModemManager1.service' for details. But that's dbus, not systemd. These really should become debug messages in dbus. > > Correct. I'd even be willing to ship the modem.target part and its udev rules > > in systemd, to make this generically available. However, that probably only if > > the rules are somewhat simple and generic. (i.e. checking for a thousand > > different VID/PID is probably something that should better stay in MM, and not > > be done in systemd) > > They're probably too big for systemd. There's a lot of VID/PID tagging going > on, and we want to keep all the rules for specific devices in the same place. > > But, what we could do, is potentially ship the MM_CANDIDATE rules with systemd, > since those are the things that *might* be modems and MM should be started to > probe. Those are separate from the VID/PID tagging rules and are quite small. Hmm, MM_CANDIDATE sounds like it might have false positives? In that case, it probably should stay in MM... In systemd we probably should ship only the really obvious, always-true, minimal cases.
(In reply to comment #22) > I haven't seen any configuration in systemd to handle this issue. For what I > can see, we could do the following: > > Restart=on-abort > RestartSec=30 > > That RestartSec=30 will make the restart of the service delayed 30s just after > the crash, but that also applies to the first crash. What we would want to have > is: > * MM gets restarted right away if it exits unexpectedly. > * If that restart fails, e.g. MM crashes again, we wait 30s before retrying > the restart. > > Lennart, is there currently some way to have this? Hmm, so we will always enforce a start limit, i.e. we will refuse to start a service more often than 5 times per 10s. This is configured with StartLimitInterval=/StartLimitBurst= (see systemd.service(5)). However, after that we will simply refuse, and only retry when the unit is requested explicitly. So basically, this will just turn off the effect of Restart= temporarily until the next explicit start request is issued. (where a start request could be bus activtion). > On a side note, I now wonder how the lifecycle of NetworkManager itself is > managed, as I didn't see any Restart= line in the service file. Will it be > restarted by dbus-activation? Which process is actively requesting > dbus-activation of NM? Yes, modulo that start limit that puts a limit on everything.
(In reply to comment #25) > I would then use just the following: > > Restart=on-abort > > If MM crashes, systemd will restart it right away. If that leads to a loop of > MM crash/reboot, then the user should just disable the service until a fix is > released. So yeah, this sounds like a good choice. And the aforementioned StartLimitInterval=/StartLimitBurst= thing will make sure the thing is not restarted too often...
(In reply to comment #29) > (In reply to comment #25) > > > I would then use just the following: > > > > Restart=on-abort > > > > If MM crashes, systemd will restart it right away. If that leads to a loop of > > MM crash/reboot, then the user should just disable the service until a fix is > > released. > > So yeah, this sounds like a good choice. And the aforementioned > StartLimitInterval=/StartLimitBurst= thing will make sure the thing is not > restarted too often... Sounds good to me. If MM crashes too often, we certainly do need to fix it :)
(In reply to comment #29) > (In reply to comment #25) > > > I would then use just the following: > > > > Restart=on-abort > > > > If MM crashes, systemd will restart it right away. If that leads to a loop of > > MM crash/reboot, then the user should just disable the service until a fix is > > released. > > So yeah, this sounds like a good choice. And the aforementioned > StartLimitInterval=/StartLimitBurst= thing will make sure the thing is not > restarted too often... Ah, that is indeed super cool already :) The defaults 10/5 are also fine I think, I just triggered it by segfaulting during port probing: Jun 25 11:59:22 ares systemd[1]: ModemManager.service start request repeated too quickly, refusing to start. Jun 25 11:59:22 ares systemd[1]: Failed to start Modem Manager. Jun 25 11:59:22 ares systemd[1]: Unit ModemManager.service entered failed state. So regarding the work needed to be done in ModemManager, only the on-abort reboot is missing, which I will push now. I'll also open a new bug in NM to change it so that it doesn't control the lifecycle of MM and leaves it to systemd when this one is found.
New bug 703040 for NM covers the logic change to avoid having MM restarted by NM. New bug 703039 for MM covers the on-hardware activation change, which I don't think is critical right away. I'll set this bug as fixed again, after having pushed the on-abort Restart logic.
Version : 1.0.0-1 in Arch Linux Still, "Failed to load configuration for dbus-org.freedesktop.ModemManager1.service: No such file or directory". This is the problem originally reported back in May. Copious error messages are still "spamming" the log file EVERY TWO MINUTES. The log has: dbus-daemon[255]: dbus[255]: [system] Activating via systemd: service name='org.freedesktop.ModemManager1' unit='dbus-org.freedesktop.ModemManager1.service' dbus[255]: [system] Activating via systemd: service name='org.freedesktop.ModemManager1' unit='dbus-org.freedesktop.ModemManager1.service' systemd[1]: Got D-Bus request: org.freedesktop.systemd1.Activator.ActivationRequest() on /org/freedesktop/DBus systemd[1]: Got D-Bus activation request for dbus-org.freedesktop.ModemManager1.service systemd[1]: Failed to load configuration for dbus-org.freedesktop.ModemManager1.service: No such file or directory systemd[1]: Trying to enqueue job dbus-org.freedesktop.ModemManager1.service/start/replace systemd[1]: D-Bus activation failed for dbus-org.freedesktop.ModemManager1.service: Invalid argument dbus-daemon[255]: dbus[255]: [system] Activation via systemd failed for unit 'dbus-org.freedesktop.ModemManager1.service': Unit dbus-org.freedesktop.ModemManager1.service failed to load: No such file or directory. See system logs and 'systemctl status dbus-org.freedesktop.ModemManager1.service' for details. dbus[255]: [system] Activation via systemd failed for unit 'dbus-org.freedesktop.ModemManager1.service': Unit dbus-org.freedesktop.ModemManager1.service failed to load: No such file or directory. See system logs and 'systemctl status dbus-org.freedesktop.ModemManager1.service' for details. It seems like systemd/dbus still lack a sufficient, or sufficiently comprehensible, "theory of operation" to allow for straightforward configuration. Copying /usr/lib/systemd/system/ModemManager.service to /usr/lib/systemd/system/dbus-org.freedesktop.ModemManager1.service avoids the error. At the next activation, this will give: dbus-daemon[255]: dbus[255]: [system] Activating via systemd: service name='org.freedesktop.ModemManager1' unit='dbus-org.freedesktop.ModemManager1.service' dbus[255]: [system] Activating via systemd: service name='org.freedesktop.ModemManager1' unit='dbus-org.freedesktop.ModemManager1.service' systemd[1]: Got D-Bus request: org.freedesktop.systemd1.Activator.ActivationRequest() on /org/freedesktop/DBus systemd[1]: Got D-Bus activation request for dbus-org.freedesktop.ModemManager1.service systemd[1]: Trying to enqueue job dbus-org.freedesktop.ModemManager1.service/start/replace systemd[1]: Installed new job dbus-org.freedesktop.ModemManager1.service/start as 1050 systemd[1]: Enqueued job dbus-org.freedesktop.ModemManager1.service/start as 1050 systemd[1]: Starting Modem Manager... systemd[1]: About to execute: /usr/bin/ModemManager systemd[1]: Forked /usr/bin/ModemManager as 4587 systemd[1]: dbus-org.freedesktop.ModemManager1.service changed dead -> start systemd[1]: Set up jobs progress timerfd. systemd[4587]: Executing: /usr/bin/ModemManager ModemManager[4587]: <info> ModemManager (version 1.0.0) starting... systemd[1]: Got D-Bus request: org.freedesktop.DBus.NameOwnerChanged() on /org/freedesktop/DBus dbus-daemon[255]: dbus[255]: [system] Successfully activated service 'org.freedesktop.ModemManager1' dbus[255]: [system] Successfully activated service 'org.freedesktop.ModemManager1' systemd[1]: Got D-Bus request: org.freedesktop.DBus.NameOwnerChanged() on /org/freedesktop/DBus systemd[1]: dbus-org.freedesktop.ModemManager1.service's D-Bus name org.freedesktop.ModemManager1 now registered by :1.53 systemd[1]: dbus-org.freedesktop.ModemManager1.service changed start -> running systemd[1]: Job dbus-org.freedesktop.ModemManager1.service/start finished, result=done systemd[1]: Started Modem Manager. systemd[1]: Closed jobs progress timerfd. NetworkManager[251]: <info> ModemManager disappeared from bus NetworkManager[251]: <info> ModemManager available in the bus ModemManager[4587]: <warn> Couldn't find support for device at '/sys/devices/pci0000:00/0000:00:1c.0/0000:02:00.0': not supported by any plugin ModemManager[4587]: <warn> Couldn't find support for device at '/sys/devices/pci0000:00/0000:00:1c.1/0000:03:00.0': not supported by any plugin and then ModemManager is left running, with: $ systemctl status dbus-org.freedesktop.ModemManager1.service dbus-org.freedesktop.ModemManager1.service - Modem Manager Loaded: loaded (/usr/lib/systemd/system/dbus-org.freedesktop.ModemManager1.service; disabled) Active: active (running) since Thu 2013-08-01 09:52:44 MDT; 3min 33s ago Main PID: 4587 (ModemManager) CGroup: name=systemd:/system/dbus-org.freedesktop.ModemManager1.service └─4587 /usr/bin/ModemManager Can someone explain why there is still a reference to a nonexistent "dbus-org.freedesktop.ModemManager1.service" in "/usr/lib/systemd/system/ModemManager.service"? James
> Can someone explain why there is still a reference to a nonexistent > "dbus-org.freedesktop.ModemManager1.service" in > "/usr/lib/systemd/system/ModemManager.service"? > That file is created only when the service is enabled; when MM service is disabled the file won't exist. Still, NM still tries to enable MM by poking the well-known-name every once in a while. Since MM 1.0, the MM service lifecycle is now controlled by systemd itself (when systemd available), meaning that NM now doesn't need to poke MM if e.g. it crashes. So, if the system is using systemd, NM should detect it and avoid the periodic poking; that's a change to be done in NM itself. This change is already reported at bug 703040, please follow up there if you prefer. I'll re-close the MM bug.