[systemd-devel] generators and service symlink

[Frederic Crozat]

Le mardi 23 août 2011 à 17:56 +0200, Lennart Poettering a écrit :
> On Mon, 22.08.11 17:52, Frederic Crozat (fcrozat at suse.com) wrote:
> 
> > Hi,
> > 
> > I'm testing a systemd-generator to create default.target symlink,
> > depending on /etc/inittab content.
> > 
> > Generator is working fine, creating symlink in /run/systemd/generator
> > but systemd isn't noticing the file (it is still using default.target
> > from /lib/systemd/system/ ) until systemctl daemon-reload is started.
> > 
> > Sounds like a bug but I'm not sure where it is..
> 
> Hmm, I am a bit confused. A reload of systemd will cause the generators
> to be run, so yupp, they should be applied in that case.
> 
> Maybe your generator does not work properly during the early boot phase
> since it requires file systems or services which aren't around yet?
> 
> Generators are executed very very early, and can only access data from
> the root fs, not even /usr. Hence writing them in anything but C is not
> really an option.

After digging further, I found the issue :
- generators was not at fault
- unlike what I was thinking, /run/systemd/generator doesn't take
precedence over /lib, so it couldn't work
- but /run/systemd/system is supposed to take precedence over everything
(/lib and /etc).

I've adapted my generator to only create the file in /run/systemd/system
if there was none in /etc/systemd/system.

It didn't work as expected due to a bug in
path-lookup.c:lookup_paths_init which remove from the lookup path lists
empty directories : therefore /run/systemd/system was evicted from the
directory list to monitor and wasn't used at all.

This was added by commit a9dd208208e672a4fe5a3c2405946c1506e034db and it
should be reverted.

I'm also attaching a patch for an error I found while reading
lookup_paths_init code.

-- 
Frederic Crozat <fcrozat at suse.com>
SUSE