RE: removing a connection from python - stuck
Ok, The familiar "finding the solution soon after posting" happened again.Sorry. I finally after many hours made some sense of the code. I am afraid I have collected code from so many samples the result is almost unreadable.Time to clean up. Anyway the solution is of course that I need to create an interface (and use capital D on delete) con_proxy = bus.get_object(service_name, path) settings_connection = dbus.Interface(con_proxy, "org.freedesktop.NetworkManager.Settings.Connection") settings_connection.Delete() //J From: jonas_vikst...@hotmail.com To: networkmanager-list@gnome.org Subject: removing a connection from python - stuck Date: Sat, 5 May 2012 19:55:22 + Hello,I am completely stuck again. I really hope some one can give me a hint.I can do most of the basic operations from python now but I cant figure out how to delete a connection. I would like to use the connection.delete() method but all "connections" I can find seem to be paths and not really the connection object.I have no clue how to deal with that. E.g.service_name = "org.freedesktop.NetworkManager"proxy = bus.get_object(service_name, "/org/freedesktop/NetworkManager/Settings") settings = dbus.Interface(proxy, "org.freedesktop.NetworkManager.Settings") conn = settings.GetConnectionByUuid(uuid)conn.delete() givesAttributeError: 'dbus.ObjectPath' object has no attribute 'delete' am I on the wrong track or what do I miss? best regards, Jonas ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
removing a connection from python - stuck
Hello,I am completely stuck again. I really hope some one can give me a hint.I can do most of the basic operations from python now but I cant figure out how to delete a connection. I would like to use the connection.delete() method but all "connections" I can find seem to be paths and not really the connection object.I have no clue how to deal with that. E.g.service_name = "org.freedesktop.NetworkManager"proxy = bus.get_object(service_name, "/org/freedesktop/NetworkManager/Settings") settings = dbus.Interface(proxy, "org.freedesktop.NetworkManager.Settings") conn = settings.GetConnectionByUuid(uuid)conn.delete() givesAttributeError: 'dbus.ObjectPath' object has no attribute 'delete' am I on the wrong track or what do I miss? best regards, Jonas ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
[PATCH] Use SIGKILL to be able to immediately start a new dnsmasq afterwards
Hey,
attached you will find a patch which fixes a problem with dnsmasq for me. Quote
from the commit message:
Use SIGKILL to be able to immediately start a new dnsmasq afterwards
This fixes the problem that when updating the DNS configuration, dnsmasq would
fail to start up with a message like this:
May 5 14:43:47 x200 dnsmasq[5172]: failed to create listening socket for
127.0.0.1: Address already in use
May 5 14:43:47 x200 dnsmasq[5172]: FAILED to start up
The reason for that is that the other dnsmasq instance is still running — it
doesn’t react to SIGTERM at all, so it was still running and NM was waiting for
the 2-second timeout to happen.
You can easily verify that dnsmasq doesn’t react to SIGTERM:
x200 ~ $ ps aux | grep '[d]nsmasq'
nobody 26820 0.0 0.0 31136 1320 ?S14:58 0:00
/usr/sbin/dnsmasq --no-resolv --keep-in-foreground --no-hosts --bind-interfaces
--pid-file=/var/run/nm-dns-dnsmasq.pid --listen-address=127.0.0.1
--conf-file=/var/run/nm-dns-dnsmasq.conf --cache-size=400 --proxy-dnssec
x200 ~ $ sudo kill -TERM 26820
x200 ~ $ ps aux | grep '[d]nsmasq'
nobody 26820 0.0 0.0 31136 1320 ?S14:58 0:00
/usr/sbin/dnsmasq --no-resolv --keep-in-foreground --no-hosts --bind-interfaces
--pid-file=/var/run/nm-dns-dnsmasq.pid --listen-address=127.0.0.1
--conf-file=/var/run/nm-dns-dnsmasq.conf --cache-size=400 --proxy-dnssec
(This is dnsmasq 2.58)
Best regards,
Michael
>From 2ea9960a9d8f4b878adda2526d06e935899a9ccf Mon Sep 17 00:00:00 2001
From: Michael Stapelberg
Date: Sat, 5 May 2012 14:56:51 +0200
Subject: [PATCH] Use SIGKILL to be able to immediately start a new dnsmasq
afterwards
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
This fixes the problem that when updating the DNS configuration, dnsmasq would
fail to start up with a message like this:
May 5 14:43:47 x200 dnsmasq[5172]: failed to create listening socket for
127.0.0.1: Address already in use
May 5 14:43:47 x200 dnsmasq[5172]: FAILED to start up
The reason for that is that the other dnsmasq instance is still running — it
doesn’t react to SIGTERM at all, so it was still running and NM was waiting for
the 2-second timeout to happen.
You can easily verify that dnsmasq doesn’t react to SIGTERM:
x200 ~ $ ps aux | grep '[d]nsmasq'
nobody 26820 0.0 0.0 31136 1320 ?S14:58 0:00
/usr/sbin/dnsmasq --no-resolv --keep-in-foreground --no-hosts --bind-interfaces
--pid-file=/var/run/nm-dns-dnsmasq.pid --listen-address=127.0.0.1
--conf-file=/var/run/nm-dns-dnsmasq.conf --cache-size=400 --proxy-dnssec
x200 ~ $ sudo kill -TERM 26820
x200 ~ $ ps aux | grep '[d]nsmasq'
nobody 26820 0.0 0.0 31136 1320 ?S14:58 0:00
/usr/sbin/dnsmasq --no-resolv --keep-in-foreground --no-hosts --bind-interfaces
--pid-file=/var/run/nm-dns-dnsmasq.pid --listen-address=127.0.0.1
--conf-file=/var/run/nm-dns-dnsmasq.conf --cache-size=400 --proxy-dnssec
(This is dnsmasq 2.58)
---
src/dns-manager/nm-dns-plugin.c | 21 ++---
1 files changed, 6 insertions(+), 15 deletions(-)
diff --git a/src/dns-manager/nm-dns-plugin.c b/src/dns-manager/nm-dns-plugin.c
index e997948..f7dc074 100644
--- a/src/dns-manager/nm-dns-plugin.c
+++ b/src/dns-manager/nm-dns-plugin.c
@@ -224,21 +224,12 @@ gboolean nm_dns_plugin_child_kill (NMDnsPlugin *self)
}
if (priv->pid) {
- KillInfo *info;
-
- if (kill (priv->pid, SIGTERM) == 0) {
- info = g_malloc0 (sizeof (KillInfo));
- info->pid = priv->pid;
- info->progname = g_strdup (priv->progname);
- g_timeout_add_seconds (2, ensure_killed, info);
- } else {
- kill (priv->pid, SIGKILL);
-
- /* ensure the child is reaped */
- nm_log_dbg (LOGD_DNS, "waiting for %s pid %d to exit", priv->progname, priv->pid);
- waitpid (priv->pid, NULL, 0);
- nm_log_dbg (LOGD_DNS, "%s pid %d cleaned up", priv->progname, priv->pid);
- }
+ kill (priv->pid, SIGKILL);
+
+ /* ensure the child is reaped */
+ nm_log_dbg (LOGD_DNS, "waiting for %s pid %d to exit", priv->progname, priv->pid);
+ waitpid (priv->pid, NULL, 0);
+ nm_log_dbg (LOGD_DNS, "%s pid %d cleaned up", priv->progname, priv->pid);
priv->pid = 0;
g_free (priv->progname);
priv->progname = NULL;
--
1.7.5.4
___
networkmanager-list mailing list
networkmanager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [MM] [PATCH 2/5] novatel: Use the ALLOWED_SINGLE_AT property. Saves 5 seconds on probing.
Dan Williams writes: > Port layout of the Novatel 551L (LTE Band 13 device similar to the E362 > this Nathan's plugin targets, but USB instead of PCI-E minicard) is as > follows: > > 0: AT commands > 1: DM > 2: another DM > 3: unknown (probably QMI; doesn't respond to $GPS_START) > 4/5: CDC Ether > > Odd that we have two DM ports. If Intf3 is really QMI then we should > make sure it's blacklisted in 'option' so we don't have to do > serial-related junk with it. what sort of endpoins does interface 3 have? Is the 4/5 configured as a standard CDC Ether class interface set with the appropriate CDC functional descriptors and class codes? I assume it's configured using either AT commands or DM? I wonder... QMI could also be embedded in the CDC Ether control interface. But then you should see "CDC: unexpected notification 01!" messages from time to time from cdc_ether, assuming that the device sends unsolicited indications. Most (all?) QMI devices seem to do that. They send a QMI_CTL SYNC indication during startup at the very least. Bjørn ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [MM] [PATCH 3/5] novatel: Implement load_access_technologies.
> > Also, do we plan to support the older non-LTE/non-QMI devices with the > 'novatel' plugin? Or should we rename this plugin to 'novatel-qmi' and > have a 'novatel-gsm' and 'novatel-cdma' for the legacy (MDM < 9xxx) > devices? > The current novatel plugin in git master should really be "novatel-4g" or "novatel-lte"; the old one still needs to be ported. -- Aleksander ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
