GNOME Bugzilla – Bug 693746
nm agent 'dies'
Last modified: 2013-04-10 21:49:25 UTC
Sometimes, when I use to vpn switch to get back onto vpn, nothing happens. The logs reveal that NM complains about 'no agent'. This usually happens after using the session for a while, including suspend/resume and dock/undock cycles involving network changes. Restarting the shell brings it back. And it is not a 'works only once' thing, since I can mistype my password and try again - the dialog comes back then.
Is there some way the ShellNetworkAgent could be getting destroyed?
We register and unregister the network agent when going into other modes like the screen shield. http://git.gnome.org/browse/gnome-shell/tree/js/ui/components/networkAgent.js#n586 Maybe there's a bug there, or a bug in the registration system?
oh, yes. setting auto_register doesn't re-register it. You need to call nm_secret_agent_register(). (And there's no need to turn off auto_register when unregistering, since it has no effect when you're unregistered.) But really you shouldn't be unregistering anyway. It would be better to stay registered and just return an error (probably NM_SECRET_AGENT_ERROR_USER_CANCELED), so that NM doesn't look for another network agent.
(In reply to comment #3) > oh, yes. setting auto_register doesn't re-register it. You need to call > nm_secret_agent_register(). (And there's no need to turn off auto_register when > unregistering, since it has no effect when you're unregistered.) That's what the code initially did. See: http://git.gnome.org/browse/gnome-shell/commit/?id=00201f7e6cce22690fae2b672b5759149ec89df4 and the corresponding bug. (In reply to comment #3) > But really you shouldn't be unregistering anyway. It would be better to stay > registered and just return an error (probably > NM_SECRET_AGENT_ERROR_USER_CANCELED), so that NM doesn't look for another > network agent. Does it make sense to have the network agent in gdm or in screen lock? Why would NetworkManager even ask at that point?
Ugh. So the problem is that auto_register controls two different things: behavior on NMSecretAgent creation, and behavior on NetworkManager restart, and it does this in a not totally sane way. But anyway, adding the register() call back to enable() should make everything just work. (There is a race condition in NMSecretAgent, but it looks improbable, and I'm about to fix it anyway.) > Does it make sense to have the network agent in gdm or in screen lock? Why > would NetworkManager even ask at that point? Well, if you have it not remembering your wifi password (or, if your wifi password involves an OTP so it can't remember it), then when you unsuspend your laptop, NM might manage to reconnect to the network before you manage to unlock the lock screen.
(In reply to comment #5) > But anyway, adding the register() call back to enable() (and leaving everything else as-is. ie, keep turning auto_register on and off like now)
(In reply to comment #5) > Well, if you have it not remembering your wifi password (or, if your wifi > password involves an OTP so it can't remember it), then when you unsuspend your > laptop, NM might manage to reconnect to the network before you manage to unlock > the lock screen. Well, having a modal dialog pop up when that happens is just completely wrong. I'd say that implicitly returning USER_CANCELLED is wrong as well. I think it makes sense for network to only reconnect if you're in a user session, but I'd like to get mccann's input.
Well, it's a race condition; NM might manage to reconnect to the network 1/10s after the lock screen goes away too. But anyway, the question is not "what UI do you want to present in this case?", it's "do you want to cede control to any other secret agent that may be running (eg, nm-applet) and let them present some UI instead?". The answer to that is obviously "no", so you should stay registered.
(In reply to comment #8) > But anyway, the question is not "what UI do you want to present in this case?", > it's "do you want to cede control to any other secret agent that may be running > (eg, nm-applet) and let them present some UI instead?". For what it's worth, I *have* seen nm-applet dialogs recently instead of the shell ones, which sounds very well like it may be caused by this. So basically the reasoning that components which are expected to be running throughout the user session (and a locked user session is still a user session, even if we expect those components to behave differently in this case) should not unregister makes sense to me.
Created attachment 236172 [details] [review] networkAgent: Don't register/unregister, just refuse to handle requests
Comment on attachment 236172 [details] [review] networkAgent: Don't register/unregister, just refuse to handle requests looks right to me (I didn't actually test it)
Attachment 236172 [details] pushed as 2498445 - networkAgent: Don't register/unregister, just refuse to handle requests
danw, if there are improvements we can make to the agent auto-register code, lets open a new bug for those. But the point of "auto-register" is to keep you registered automatically, so you don't have to think about it and don't have to handle NM restarts either. I'm not sure how that's incompatible with controlling registration on both agent creation and NM restart.