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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
