After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 686047 - RFE: Overall network status environment variable in dispatcher scripts
RFE: Overall network status environment variable in dispatcher scripts
Status: RESOLVED WONTFIX
Product: NetworkManager
Classification: Platform
Component: general
0.9.x
Other Linux
: Normal normal
: ---
Assigned To: NetworkManager maintainer(s)
NetworkManager maintainer(s)
Depends on:
Blocks: 681301
 
 
Reported: 2012-10-12 17:05 UTC by Orion Poplawski
Modified: 2013-05-06 16:46 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Orion Poplawski 2012-10-12 17:05:34 UTC
It would be nice if there was a variable that dispatcher scripts could check to determine overall network status - whether or not network access is expected or not.  I'm assuming that a message like that is available over dbus - having the equivalent in the dispatcher scripts would be very useful.
Comment 1 Jiri Klimes 2012-10-17 14:25:10 UTC
Technically, it would be possible. But not sure if we want that.
At present we expose stuff like DHCP, IP and the like in dispatcher scripts. These variables are relevant to specific connections which is what most actions (up, down, vpn-up, ...), except 'hostname' action, deal with.

You can always use e.g. nmcli in the dispatcher script to query any information about NM.
For getting overall status use:
LC_ALL=C nmcli -t -f state nm

Or, do you suggest introducing a new action "state-changed" that would call scripts when the state changes?
Comment 2 Orion Poplawski 2012-10-17 15:38:54 UTC
There are times when you need to do things (start/stop services) depending on whether or not a machine is on any network or not.  Thanks for the nmcli suggestion, but it seems that if that is available in NM it should be directly available in the dispatcher script without the overhead of running nmcli.
Comment 3 Orion Poplawski 2012-10-17 21:30:29 UTC
Well, while looking at trying to implement what I wanted to do, I found that it just may be too complicated.  One problem is that service/systemctl does not appear to have a "start-if-enabled" command, which may be solved in the future, but for now it just might not be worth it.  On the other hand, it still probably makes sense to export a NM_STATE variable or similar.
Comment 4 Pavel Simerda 2012-10-18 09:00:44 UTC
> Well, while looking at trying to implement what I wanted to do, I found that it
> just may be too complicated.

Sometimes it's better to at least briefly describe your intentions.

> One problem is that service/systemctl does not
> appear to have a "start-if-enabled" command

What is your use case for that?

> but for now it just might not be worth it.  On the other hand, it still
> probably makes sense to export a NM_STATE variable or similar.

Possibly.
Comment 5 Orion Poplawski 2012-10-22 17:12:45 UTC
I want to run the puppet client only when a network connection is active (and only when puppet is enabled).
Comment 6 Pavel Simerda 2013-05-06 16:46:01 UTC
(In reply to comment #5)
> I want to run the puppet client only when a network connection is active (and
> only when puppet is enabled).

It's been sitting here without reply for some time. I think that the best way to check overall network status is using the dispatcher scripts to *trigger* your action and then *check* the status via public API (a python script using libnm-glib or, if you're not concerned about API stability, a nmcli command line).

Please reopen if that doesn't work for you for some reason or another.