Bug#719738: [PATCH] Please install the lvm2 systemd generator

Peter Rajnoha prajnoha at redhat.com
Fri Aug 23 14:39:36 UTC 2013


On 08/23/2013 04:03 PM, Bastian Blank wrote:
> On Fri, Aug 23, 2013 at 03:22:18PM +0200, Peter Rajnoha wrote:
>> On 08/23/2013 01:59 PM, Bastian Blank wrote:
>>> Second the init-script and the generated unit have different names, so
>>> systemd won't be able to consider them equal. I have no idea how this
>>> really works anyway.
> 
> The question was about the handling of init-script and systemd-service
> of same name.
> 

If both init-script and systemd service are of the same name, systemd
service prevails. I've read it once in some systemd manual (though
I can't find it now quickly in those tons of systemd doc :) ). I've just
tried that directly and yes, it's systemd service that prevails, the
other one is ignored.

>> The aim of the lvm2-activation-generator is to:
>>  - do nothing if global/use_lvmetad=1 in lvm.conf
> 
> I'm not sure why this is useful. The systemd units would only call
> "vgchange -aay --sysinit", which is already a no-op if lvmetad is
> enabled. Instead of units, which can be overwritten by distribution
> means, dpkg-divert for example, it generates _static_ files within a
> binary.
> 
> I only see that it makes the complexity of the system higher, but I
> don't see the gain.
> 

Well, it depends on the view. The aim is to make the boot clean.
So there are no extra unneeded calls that could make the boot process
unclear (and if the generator is NOP for use_lvmetad=1, we can assure
that). Thing is that we're slowly switching to using lvmetad by
default. And calling direct vgchange on boot will get more and more
deprecated in the future.

Also, if the system is configured in a way that all needed paths
are accessible even during boot time (e.g. using tmpfs for paths
where lvm's file-based locking is used and sockets/fifos placed),
we actually don't even need the --sysinit for vgchange call.
Then the vgchange is not a NOP anymore. And you need to call
that vgchange more than once (e.g. because of the encryption
placed in between layers etc.).

What I want to say is that the generator is here just for the
case when someone backs out of using lvmetad and uses the old
classic event-unaware lvm without lvmetad which should become
rather an exception in the future.

Peter



More information about the pkg-lvm-maintainers mailing list