[systemd-devel] generators and service symlink

[Lennart Poettering]

On Wed, 24.08.11 13:42, Frederic Crozat (fcrozat at suse.com) wrote:

> > 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

Oh, of course. Generators do indeed not take precedence. And that
ctually makes sense I believe since native configuration should always
take precedence over legacy configuration. The same way as native
services take precedence over sysv. 

In your case the clean solution is to place your stuff in
/run/systemd/system instead (and ignore argv[1]), since you actually
really want to override the default configuration.

> - but /run/systemd/system is supposed to take precedence over everything
> (/lib and /etc).

Yes, correct.

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

Sounds sensible.

> 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.

Hmm, are you suggesting lookup_paths_init() is called before the
generators? That would be wrong. We should definitely strip empty
directories, but of course taking into account everything the generators
might have generated.

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

Thanks, applied.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.