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 564986 - [enh] loglevel option
[enh] loglevel option
Status: RESOLVED FIXED
Product: NetworkManager
Classification: Platform
Component: general
unspecified
Other All
: Normal enhancement
: ---
Assigned To: Dan Williams
Dan Williams
: 577663 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2008-12-18 12:24 UTC by Gunnar Thielebein
Modified: 2010-04-08 17:45 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Gunnar Thielebein 2008-12-18 12:24:47 UTC
NetworkManager spams logfile with a lot of info:

Dec 18 11:45:57 galactica NetworkManager: <info>  Supplicant state changed: 1 
Dec 18 12:07:33 galactica NetworkManager: <info>  Supplicant state changed: 0 
Dec 18 12:07:36 galactica NetworkManager: <info>  Supplicant state changed: 1 

I am not interesting in that stuff. Is there possibility to add loglevel option to NetworkManager daemon for decrease output?

Thanks.
Comment 1 Dan Williams 2009-04-08 22:13:44 UTC
*** Bug 577663 has been marked as a duplicate of this bug. ***
Comment 2 Dan Williams 2009-04-08 22:15:12 UTC
Should really be a combination of dynamic logging levels, plus 'zones' for various pieces of the puzzle like wifi, policy, wired, gsm, serial, ppp, hal, ip, etc.  Thus you could dial up debugging output for only the zones you care about.
Comment 3 Tomislav Vujec 2009-04-09 01:03:02 UTC
I can give it a try. What exactly do you want? Do you want zones to go across all log levels (info, warn, err, etc.), or just debugging? I would instinctively go for latter, but former might make sense as well.
Comment 4 Dan Williams 2009-04-09 14:07:16 UTC
I'd say zones (or ") should go across everything.  I'd imagine something like this:

/* INFO: prints general messages, errors, and warnings */
#define NM_LOG_INFO 0
/* VERBOSE: prints stuff like device state changes, IP & DHCP config, etc */
#define NM_LOG_VERBOSE 1
/* DEBUG: prints stuff like supplicant state changes, DHCP transaction information, etc */
#define NM_LOG_DEBUG 2

Then we have the zones:

typedef enum {
	NM_LOG_ZONE_GENERAL = 0x0000,
	NM_LOG_ZONE_WIFI    = 0x0001,
	NM_LOG_ZONE_WIRED   = 0x0002,
	NM_LOG_ZONE_SERIAL  = 0x0004,
	NM_LOG_ZONE_GSM     = 0x0008,
	NM_LOG_ZONE_CDMA    = 0x0010,
	NM_LOG_ZONE_DHCP    = 0x0020,
	NM_LOG_ZONE_DEVICE  = 0x0040,
	NM_LOG_ZONE_HOTPLUG = 0x0080,
	NM_LOG_ZONE_VPN     = 0x0100,
	NM_LOG_ZONE_SHARING = 0x0200,
	NM_LOG_ZONE_IP4     = 0x0400,
	NM_LOG_ZONE_IP6     = 0x0800,
	NM_LOG_ZONE_AUTOIP4 = 0x1000,
	NM_LOG_TIMESTAMPS   = 0x2000,
} NMLogZone;

and add more as we think about it.  Then, for the actual logging functions, we make a private header somewhere in src/ called nm-debug.h or something that basically does:

#define nm_log_general (level, format, args...) \
    { nm_log (NM_LOG_ZONE_GENERAL, level, format, ##args); }

#define nm_log_wifi (level, format, args...) \
    { nm_log (NM_LOG_ZONE_WIFI, level, format, ##args); }

that sort of thing.  We then implement nm_log() in src/NetworkManagerUtils.c that actually puts together the log string and prints it out.  Sound doable?  If you could even just put together the logging infrastructure we could certainly move stuff over inside NM as time permits.  Just haven't had the time to do that quite yet.  That would rock.
Comment 5 Dan Williams 2009-04-09 14:08:32 UTC
Actually there's already src/nm-logging.c and src/nm-logging.h, we could just add this stuff to those existing files.
Comment 6 Tobias Mueller 2009-12-24 11:18:58 UTC
This issue apparently has been identified as worth fixing. I'm thus setting to NEW.
Comment 7 Dan Williams 2010-04-08 17:45:34 UTC
Granular logging added as of commit 157e9f791dcd01a53188ccec2ab8d552b5a03686.