GNU bug report logs - #76688
[PATCH] services: network-manager: Handle existing configuration directory.

Previous Next

Full log

Message #23 received at 76688 <at> debbugs.gnu.org (full text, mbox):

From: Vagrant Cascadian <vagrant <at> debian.org>
To: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
Cc: 76688 <at> debbugs.gnu.org, Arnaud Daby-Seesaram <ds-ac <at> nanein.fr>,
 45mg <45mg.writes <at> gmail.com>
Subject: Re: [bug#76688] [PATCH] services: network-manager: Handle existing
 configuration directory.
Date: Sat, 22 Mar 2025 09:52:32 -0700

[Message part 1 (text/plain, inline)]

On 2025-03-22, Maxim Cournoyer wrote:
> Vagrant Cascadian <vagrant <at> debian.org> writes:
>> I hit this bug as well, and it actually caused a boot failure, had to
>> boot to an older generation to get things working again!
>>
>> Have not yet tried the patch, though it looks like it should fix this
>> exact problem...

I did get a chance to test the patch, and it worked to allow me to
reconfigure multiple times and still be able to reboot into the new
generation.

Though I did notice that nothing seems to clean up
/etc/NetworkManager/conf.d if you switch to a generation where the
configuration file is not present, so if you want to remove the
configuration you need to do so manually, which seems to break the
delcarative system configuration a bit.


>> But... I am wondering if it wouldn't be more elegant to avoid using
>> /etc/NetworkManager/conf.d entirely, instead call NetworkManager
>> pointing the --config-dir arguments directly at the relevent store
>> directory, much like the configuration is passed using the --config
>> argument. That way there would be no leftovers between different system
>> generations...
>
> The thing is that NetworkManager, among other tools, make use of inotify
> to monitor configuration changes, which is very useful as it avoids the
> user having to restart the daemon or worst, reboot to have the changes
> effected post a reconfiguration.  On such example was udev; see commit
> e9fa17eb98efbd6211ab44ab49b8c078d4b73e04 that changed it from using a
> store value for its config file to a /etc/udev/rules.d fixed location.

Fair! Though the conf.d symlink just points to the store (at least in
the configuration I tried) or, or will it notice when the symlink
changes? Are there cases where it would change from a single conf.d
symlink to a conf.d directory with multiple symlinks into the store? (so
far, I only tested with a single configuration file)

Regardless, I still wonder if it might be worth using
/run/NetworkManager/conf.d instead of /etc as this would at least get
automatically cleaned up between reboots.

live well,
  vagrant

[signature.asc (application/pgp-signature, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.