Bug 1018017

Confirmed here.

Currently NetworkManager will periodically ping the MM1 interface to get ModemManager started; and if ModemManager is disabled in the system that is the kind of message that you will end up seeing.

The proper fix would be to skip this periodic ping to the interface in NetworkManager when systemd is detected in the system, as the lifecycle of ModemManager is then managed by systemd itself, not by NetworkManager.

See upstream bug https://bugzilla.gnome.org/show_bug.cgi?id=703040.

As a workaround you could enable ModemManager.service which creates the file which cannot be found.

*** Bug 1019022 has been marked as a duplicate of this bug. ***

If I'm reading things right, this will actually only happen if you have MM installed but disabled. You can fix by re-enabling the service *or* by entirely removing MM, with 'yum remove ModemManager', which you should be able to do without dependency issues.

@Adam Williamson #5: Seem to be right. I uninstalled ModemManager (the ModemManager package itself, not ModemManager-glib which cannot be uninstalled because of dependency issues) and the output is gone.

(In reply to Adam Williamson from comment #5)
> You can fix [...] by
> entirely removing MM, with 'yum remove ModemManager', which you should be
> able to do without dependency issues.

Unfortunately, not with KDE and kde-plasma-nm and it looks like that won't be 
fixed any time soon either.  See Bug 1013838.  The root cause is a dependency on 
ModemManager in libnm-qt according to that bug.

I encountered the same message when I tried to use my Huawei E372 after upgrading from Fedora 19 to Fedora 20.

Before the update everything was working properly.

The proposed solution is helpful because the service was disabled after the update.

Michele

(trusting in the google translator)

I can verify that using "systemctl enable ModemManager.service" removes the annoying log record.

(In reply to Adam Williamson from comment #5)
> You can fix by re-enabling the service ...

"fix"? - ew ...

(In reply to Grega Bremec from comment #9)
> I can verify that using "systemctl enable ModemManager.service" removes the
> annoying log record.

well, I find much more annoying running a service that I do not use rather than having to filter out some noise from logs, but seems that these days people get so easily convinced to throw a few bucks more on better hardware and to open security holes to their systems rather than demand that developers do their job ...

note that the root cause of this is known at least for 3 and half years, I've found this reference:
http://osdir.com/ml/networkmanager-list/2010-08/msg00188.html

and this particular problem was discussed in Arch linux in April 2013 ...

:-(

karel: you rather cut out the bit where I said you can *also* fix it by uninstalling ModemManager.

(In reply to Karel Volný from comment #10)
> (In reply to Adam Williamson from comment #5)
> > You can fix by re-enabling the service ...
> 
> "fix"? - ew ...
> 
> (In reply to Grega Bremec from comment #9)
> > I can verify that using "systemctl enable ModemManager.service" removes the
> > annoying log record.
> 
> well, I find much more annoying running a service that I do not use rather
> than having to filter out some noise from logs, but seems that these days
> people get so easily convinced to throw a few bucks more on better hardware
> and to open security holes to their systems rather than demand that
> developers do their job ...
> 
> note that the root cause of this is known at least for 3 and half years,
> I've found this reference:
> http://osdir.com/ml/networkmanager-list/2010-08/msg00188.html
> 

LoL; that "root cause" you talk about is actually a *feature*. ModemManager can be auto-started via DBus, and that is what NetworkManager does, it pokes ModemManager to start it. If it cannot start it, it will wait some time until it re-pokes. If you don't have MM installed or the service is disabled in systemd, it will just dump some error logs, which actually are emitted in dbus-daemon and systemd.

> and this particular problem was discussed in Arch linux in April 2013 ...
> 
> :-(

Yeah, and the outcome of the discussion was that NetworkManager doesn't need to manage the lifecycle of ModemManager when systemd is in place; i.e. no pokes should be done explicitly by NetworkManager to try to start ModemManager. You may want to follow this bug:

https://bugzilla.gnome.org/show_bug.cgi?id=703040

I'll try to update my patch there in the following days, and hopefully it will be available soon in both NM git master and distributions.

BTW, note that I personally do this in my free time; so a not-even-one-year-old bug is actually pretty new to me ;)

Awww, for f***sake. systemd again. :(

Is this going to become the next bloody holy war about who has the biggest member and should therefore take over system management? /o\

Just get over it, people. Settings are good. Automatic behaviour is stupid for the most part.

NM needs a way for people to tell it to piss off. Implement that already.

(In reply to Karel Volný from comment #10)
And, Karel, I *do* have a modem. Actually, I have *two* modems. The second one is called "a phone". I just don't use it in that way, because I don't have to.

Grega: we did. Years ago. And this is ModemManager, not NetworkManager. And I already explained above that you can avoid this problem just by removing ModemManager.

I really don't know why this corpse has suddenly been reanimated.

(In reply to Grega Bremec from comment #13)
> Awww, for f***sake. systemd again. :(
> 
> Is this going to become the next bloody holy war about who has the biggest
> member and should therefore take over system management? /o\
> 
> Just get over it, people. Settings are good. Automatic behaviour is stupid
> for the most part.
> 
> NM needs a way for people to tell it to piss off. Implement that already.

Settings are good, and that is why when the system uses systemd, we will rely on systemd to manage the life cycle of ModemManager, instead of blindly trying to start it from NetworkManager. If ModemManager is not installed, or the service disabled in systemd, noone will try to start it, simple as that. If the system doesn't use systemd (say Ubuntu for example) we'll default to the old NM behaviour of pinging MM from NM.

Not sure what you're complaining about actually. Relying on the init system to start/stop ModemManager if needed is the way to go, whatever that init system is.
If you don't want NM/MM, just uninstall them :)

(In reply to Adam Williamson from comment #15)
> And this is ModemManager, not NetworkManager.

Sorry, must've been led astray by the fact everything that led to here was NM's fault.

> I really don't know why this corpse has suddenly been reanimated.

Me neither.

(In reply to Aleksander Morgado from comment #16)
> (In reply to Grega Bremec from comment #13)
> > Awww, for f***sake. systemd again. :(
>
> Not sure what you're complaining about actually. Relying on the init system
> to start/stop ModemManager if needed is the way to go, whatever that init
> system is.

Honestly? I am complaining because a certain person involved deeply in systemd development is a complete arse but nobody so far that makes a difference seems to have realised that in full. It's not about the person, it's the product of their work. It is severely handicapped because of that. And that is why the *new* init system is nothing to be relied upon. 'fraid. There, this is as honest as I can get.

This is my professional opinion.

All other comments aside, the error with this log-spamming, while printed by systemd, is really caused by NetworkManager requesting that ModemManager be started.  That is getting fixed as indicated in the upstream gnome.org bug.

So yes, this will be fixed, and NetworkManager will quit poking ModemManager periodically, causing this message.

(In reply to Adam Williamson from comment #11)
> karel: you rather cut out the bit where I said you can *also* fix it by
> uninstalling ModemManager.

... already answered in comment #7?

(In reply to Aleksander Morgado from comment #12)
> LoL; that "root cause" you talk about is actually a *feature*. ModemManager
> can be auto-started via DBus,

so far so good, let's call it a feature ...

> and that is what NetworkManager does,

... and this is where I disagree and call it a bug

why should NetworkManager try to do _anything_ modem-related when no modem connection is configured?


> BTW, note that I personally do this in my free time; so a
> not-even-one-year-old bug is actually pretty new to me ;)

sorry, not meant to offend you - I hope you're not the only one to take care of such things ... I've heard rumours we actually pay some people to fix software we ship(*), so I expected a bit more interest (I've also heard rumours that some  _big_ customers really don't like excessive false-positive log messages)

(*) do I really have to clone everything for RHEL even if it is self-evident that these are the same bits?

... sorry for being a bit snarky, but I'm getting quite tired by the fact that almost no one cares about the precious and valuable time of the users; when it comes to thing like this one, it is okay to leave thousands (ten thousands? hundred thousands? ...) of people wondering what do these messages mean, having to spend time investigating and workarounding, wasting sum of hundreds (thousands? ten thousands? ...) of admin/support-hours, instead of throwing a few (tenths?) developerhours on a proper fix

(oh, and sorry, bugzilla is not a discussion forum for such rants, but I'm really frustrated)

Karel: you're writing as if someone's arguing there isn't a bug here. I haven't seen anyone say that. It's been explicitly acknowledged that there's a bug, and it should be fixed.

All I wanted to point out is that no, this is not a case of OMG SYSTEMD IS EVIL OMG KILL IT WITH FIRE. It's just a bug, in some software. Bugs in software are things that happen (and pay my mortgage, so good job, keep it up :>)

(In reply to Adam Williamson from comment #21)
> All I wanted to point out is that no, this is not a case of OMG SYSTEMD IS
> EVIL OMG KILL IT WITH FIRE.

I feel I have to apologise. I am sorry if I left you with that impression. It must have been the general attitude we get that Karel is also talking about above. Also, not aimed at you at all.

> It's just a bug, in some software. Bugs in software are things that happen
> (and pay my mortgage, so good job, keep it up :>)

Thumbs up for that one. ;) I wish everybody had at least 25% of your wits.

(In reply to Karel Volný from comment #20)
> (In reply to Aleksander Morgado from comment #12)
> > LoL; that "root cause" you talk about is actually a *feature*. ModemManager
> > can be auto-started via DBus,
> 
> so far so good, let's call it a feature ...
> 
> > and that is what NetworkManager does,
> 
> ... and this is where I disagree and call it a bug
> 
> why should NetworkManager try to do _anything_ modem-related when no modem
> connection is configured?
> 

I totally agree with that, and that is why on-hardware activation via systemd for ModemManager is one of the things we want to achieve; i.e. only run ModemManager if a modem is likely to be attached to the system.

But note that a modem connection cannot be configured in NetworkManager if NetworkManager doesn't know anything about modems available in the system. Therefore, until now, NetworkManager would try to autostart ModemManager. By making systemd handle the lifecycle of ModemManager, we're actually transforming the issue into having ModemManager a user-controllable (as in enable-able/disable-able) service, which I personally think is a good idea.

Hi, I stumbled upon this bug because my internal 3g modem stopped working after upgrading from FC19 to FC20. The solution to the problem was indeed to activate the ModemManager service by issuing the command:

 systemctl enable ModemManager.service

I just put it in here in case someone else has a similar problem.

I don't know if the fact that the service was disabled after the upgrade could be considered a bug or if it was something that just happened to me (or at least it doesn't happen to most people upgrading).

I'm on a Dell Latitude E6530 with a Broadcom BCM43228 card running the wl driver.

I found this bug because I my machine seemed very unresponsive.
On the order of half a second between the bash prompt returning with a simple ENTER key.
There was no other load.
'top' found a busy kthread.
I had a look at the logs which showed this issue's description.

When I removed ModemManager the system recovered.

(In reply to Matthew Hannigan from comment #25)
>[ ... ]
> When I removed ModemManager the system recovered.

Fedora 20 64bit, latest updates.

I got here because 32541 lines out of 44595 lines in my /var/log/messages contain the string "ModemManager".  I'm trying to figure out a probably NetworkManager deficiency and this is getting in the way.  (Easily cured, but finding my way here was a distraction.)

I'd have hoped that this apparently simple bug would have been fixed in the 7 months since it was reported.

I've now removed ModemManager package (thanks, Adam Williamson) so the problem should be solved for this machine.

This has been fixed in NetworkManager upstream and is present in F21.  It will be backported to F20 too.

NetworkManager-0.9.9.0-43.git20131003.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/NetworkManager-0.9.9.0-43.git20131003.fc20

Package NetworkManager-0.9.9.0-43.git20131003.fc20:
* should fix your issue,
* was pushed to the Fedora 20 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing NetworkManager-0.9.9.0-43.git20131003.fc20'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2014-8988/NetworkManager-0.9.9.0-43.git20131003.fc20
then log in and leave karma (feedback).

NetworkManager-0.9.9.0-43.git20131003.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.