The directory has had inotifiy watch since the beginning actually, butOn Thu, 2013-03-21 at 12:05 -0500, Robby Workman wrote:
> On Thu, 21 Mar 2013 10:54:59 -0500
> Dan Williams <dcbw redhat com> wrote:
>
> > On Thu, 2013-03-21 at 11:13 +1100, Dan Fruehauf wrote:
> > > Thanks for that guys.
> > >
> > > Sounds like the best thing to do is to actually allow the installed
> > > VPN plugins to control that configuration. i.e. every VPN plugin
> > > can provide a DBUS file that will allow itself to communicate with
> > > NetworkManager. However with the one file - one policy type of
> > > configuration in dbus it'll be rather difficult.
> > >
> > > On the other hand, try to count all the "famous" VPN protocols you
> > > know today, there aren't that many. I don't expect 500 plugins
> > > popping up tomorrow, so perhaps keeping it the way it is is not too
> > > bad and we can have our efforts invested in more important things.
> > >
> > > But that's just my humble opinion.
> >
> > Yeah, best thing to do is probably to have the plugins themselves
> > provide the configuration. However, I can't recall the historic
> > reasons we didn't do that, possibly upgrade-related, though the note
> > there says:
> >
> > <!-- Allow NM to talk to known VPN plugins; due to a bug in
> > the D-Bus daemon, when a plugin is installed and the user
> > immediately tries to use it, the VPN plugin's rules aren't
> > always loaded into dbus-daemon. Those rules allow NM to
> > talk to the plugin. Oops. Work around that by explicitly
> > allowing NM to talk to VPN plugins here.
> > -->
> >
> > This was a huge bug back in the day, and i'm not 100% confident that
> > it's actually been solved in the bus daemon yet. If it was, then we
> > could get rid of this block.
>
>
> I'm pretty sure this isn't needed any more. I may have some details
> wrong, but if my memory serves me correctly, the user would have to
> reload the messagebus config (have it reread its configuration) after
> adding a new file in $sysconfdir/etc/dbus-1/system.d/ -- these days,
> that directory has an inotify watch or some such on it, and the
> daemon automatically reloads its config when a new file appears in
> that directory.
as recently as a couple years ago there were a few race conditions that
would cause a new file dropped there not to be recognized. Which is
what this was working around. You're probably right though, and it's
likely been fixed for quite a while. I tried to find the specific bug
just now but failed.
Dan