Bug#728486: Current patch for resolving lvm/systemd compatibility

2014-01-30 Thread Michael Stapelberg
Hi Don,

Don Armstrong  writes:
> Do you have an updated patch with this change and a documentation of the
> tmpfiles.d change?
>
> I will draft a resolution shortly to implement this patch, and will
> open it for discussion.
Bastian has uploaded lvm2 2.02.104-1 which contains my patch:
http://packages.qa.debian.org/l/lvm2/news/20140129T214940Z.html

I tested that new version of lvm2 on my test VM and it addresses the
issue we have been seeing before.

Therefore, I think there is no need to update my patch :).

-- 
Best regards,
Michael


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/x6ppn94wqq@midna.zekjur.net



Bug#728486: Current patch for resolving lvm/systemd compatibility

2014-01-29 Thread Don Armstrong
On Sat, 18 Jan 2014, Michael Stapelberg wrote:
> Bastian Blank  writes:
> > On Sat, Jan 18, 2014 at 11:47:11AM +0100, Michael Stapelberg wrote:
> >> --- /dev/null
> >> +++ b/debian/lvm2-activation-early.service
> >
> > Wrong name.
> Renaming them to lvm2{,-early}.service as you suggested is fine with me.

Do you have an updated patch with this change and a documentation of the
tmpfiles.d change?

I will draft a resolution shortly to implement this patch, and will
open it for discussion.

-- 
Don Armstrong  http://www.donarmstrong.com

PowerPoint is symptomatic of a certain type of bureaucratic
environment: one typified by interminable presentations with lots of
fussy little bullet-points and flashy dissolves and soundtracks masked
into the background, to try to convince the audience that the goon
behind the computer has something significant to say.
 -- Charles Stross _The Jennifer Morgue_ p33


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140129163739.ga22...@teltox.donarmstrong.com



Bug#728486: Current patch for resolving lvm/systemd compatibility

2014-01-22 Thread Michael Biebl
Am 19.01.2014 11:59, schrieb Bastian Blank:
> On Sat, Jan 18, 2014 at 11:33:32PM +0100, Michael Biebl wrote:
>> On Sat, Jan 18, 2014 at 01:20:41PM +0100, Bastian Blank wrote:
>>> - lvm2.service is statically hooked to local-fs.target, as all local
>>>   mounts.
>> lvm2.service is not a local mount, so that is not really a justification for
>> enabling the service statically.
> 
> Please show me a better target.  This is what the generator does, so I
> assume there exists none.

This is a misunderstanding. The target is fine. I was just saying that
using the target as justification for enabling the service statically is
flawed.
That said, I don't really care if you hook up the service statically.
I'm just a bit surprised since you objected the generator as you wanted
the possibility to disable the service.

> 
>>> +ExecStartPre=/bin/udevadm settle
>> Please don't run udevadm directly. This is a udev command.
> 
> Can you please describe what will be broken by this?

The more important question is: what are you trying to fix with this?
The cryptsetup.target will only be active once all hooked up devices are
ready. There is no point adding a udevadm settle. That is purely useless.
So again, what are you trying to do/fix here?

>> Wants=systemd-udev-settle.service
>> After=systemd-udev-settle.service ...
>> (as the original .service file does).
> 
> The generated service files uses both variants:
> - The pre-cryptsetup and pre-local-fs services uses
>   systemd-udev-settle.service.


> - The pre-remote-fs service, which is not included here currently, uses
>   ExecStartPre.

You don't include that service. And also, just because
pre-remote-fs.service uses the ExecStartPre hack is no justification for
using that in lvm2.service. pre-remote-fs.service is a completely
different beast.

If you need more information, please ask. But please don't cook up your
own patch just for the sake of it. This bug has been open for far too long.

Michael


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature


Bug#728486: Current patch for resolving lvm/systemd compatibility

2014-01-19 Thread Josh Triplett
Bastian Blank wrote:
>On Sat, Jan 18, 2014 at 11:33:32PM +0100, Michael Biebl wrote:
>> Wants= will make sure the systemd-udev-settle.service is started
>> dynamically and After= ensures the correct ordering.
> 
> It only makes sure that systemd-udev-settle.service was started
> somewhere _before_.  It does however not make sure it is called again
> for the second round or third round.

It doesn't matter if you run "udevadm settle" once, twice, or twelve
times; it still won't guarantee that more devices won't show up later.
Dynamic hardware detection does not work the way you wish it did, and
"udevadm settle" will not change that; it will only slow down the boot
process for everyone.  Calling it once for all broken services is quite
enough.

On a different note, this patch also has a serious limitation: it
doesn't automatically disable itself when use_lvmetad=1, which seems
like the right way to handle dynamic hardware detection in any
environment that lvmetad can handle (anything other than a multi-host
cluster, as far as I can tell).

- Josh Triplett


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140119192453.GA1572@leaf



Bug#728486: Current patch for resolving lvm/systemd compatibility

2014-01-19 Thread Bastian Blank
On Sat, Jan 18, 2014 at 11:33:32PM +0100, Michael Biebl wrote:
> On Sat, Jan 18, 2014 at 01:20:41PM +0100, Bastian Blank wrote:
> > - lvm2.service is statically hooked to local-fs.target, as all local
> >   mounts.
> lvm2.service is not a local mount, so that is not really a justification for
> enabling the service statically.

Please show me a better target.  This is what the generator does, so I
assume there exists none.

> > +ExecStartPre=/bin/udevadm settle
> Please don't run udevadm directly. This is a udev command.

Can you please describe what will be broken by this?

> Wants=systemd-udev-settle.service
> After=systemd-udev-settle.service ...
> (as the original .service file does).

The generated service files uses both variants:
- The pre-cryptsetup and pre-local-fs services uses
  systemd-udev-settle.service.
- The pre-remote-fs service, which is not included here currently, uses
  ExecStartPre.

> Wants= will make sure the systemd-udev-settle.service is started
> dynamically and After= ensures the correct ordering.

It only makes sure that systemd-udev-settle.service was started
somewhere _before_.  It does however not make sure it is called again
for the second round or third round.

Bastian

-- 
You!  What PLANET is this!
-- McCoy, "The City on the Edge of Forever", stardate 3134.0


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140119105901.ga14...@mail.waldi.eu.org



Bug#728486: Current patch for resolving lvm/systemd compatibility

2014-01-18 Thread Michael Biebl
On Sat, Jan 18, 2014 at 01:20:41PM +0100, Bastian Blank wrote:
> Untested patch:
> 
> - Static services with the correct name.

Well, the original names from the upstream patch weren't really incorrect.
You just have to make sure that the lvm2 sysv init script is correcly
"shadowed" by the native service file. Using Alias=lvm2 would have
worked as well.

That said, if you prefer those names, that is ok.


> - lvm2.service is statically hooked to local-fs.target, as all local
>   mounts.

lvm2.service is not a local mount, so that is not really a justification for
enabling the service statically. That said, if you want to ship the
symlinks in the package and not allow systemctl enable|disable (via
[Install] WantedBy=), this is something I'd be personally fine with.

> \ No newline at end of property
> Index: debian/tree/lvm2/lib/systemd/system/lvm2-early.service
> ===
> --- debian/tree/lvm2/lib/systemd/system/lvm2-early.service(revision 0)
> +++ debian/tree/lvm2/lib/systemd/system/lvm2-early.service(working copy)
> @@ -0,0 +1,11 @@
> +[Unit]
> +Description=Activation of LVM2 logical volumes
> +Documentation=man:lvm(8) man:vgchange(8)
> +DefaultDependencies=no
> +After=systemd-udev-settle.service
> +Before=cryptsetup.target local-fs.target shutdown.target
> +
> +[Service]
> +ExecStartPre=/bin/udevadm settle

Please don't run udevadm directly. This is a udev command.

Instead please use
[Unit]
...
Wants=systemd-udev-settle.service
After=systemd-udev-settle.service ...

(as the original .service file does).

Wants= will make sure the systemd-udev-settle.service is started
dynamically and After= ensures the correct ordering.


> +ExecStart=/sbin/lvm vgchange -aay --sysinit
> +Type=oneshot
> Index: debian/tree/lvm2/lib/systemd/system/lvm2.service
> ===
> --- debian/tree/lvm2/lib/systemd/system/lvm2.service  (revision 0)
> +++ debian/tree/lvm2/lib/systemd/system/lvm2.service  (working copy)
> @@ -0,0 +1,11 @@
> +[Unit]
> +Description=Activation of LVM2 logical volumes
> +Documentation=man:lvm(8) man:vgchange(8)
> +DefaultDependencies=no
> +After=lvm2-early.service cryptsetup.target
> +Before=local-fs.target shutdown.target
> +
> +[Service]
> +ExecStartPre=/bin/udevadm settle

Please remove this ExecStartPre (see above)


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140118223327.ga9...@pluto.milchstrasse.xx



Bug#728486: Current patch for resolving lvm/systemd compatibility

2014-01-18 Thread Michael Stapelberg
Hi Bastian,

Bastian Blank  writes:
> On Sat, Jan 18, 2014 at 11:47:11AM +0100, Michael Stapelberg wrote:
>> --- /dev/null
>> +++ b/debian/lvm2-activation-early.service
>
> Wrong name.
Renaming them to lvm2{,-early}.service as you suggested is fine with me.

>> +[Unit]
>> +Description=Activation of LVM2 logical volumes
>> +Documentation=man:lvm(8) man:vgchange(8)
>> +DefaultDependencies=no
>> +After=systemd-udev-settle.service
>> +Before=cryptsetup.target
>
> This have to be "cryptdisks.service"
No. cryptdisks{,-early}.service are actually masked in the systemd
package. cryptsetup.target is the correct unit to refer to here, see
also systemd.special(7):

cryptsetup.target
A target that pulls in setup services for all encrypted block devices.

Units called e.g. systemd-cryptsetup@sda2_crypt.service are dynamically
generated from /etc/crypttab using a systemd generator and will then be
part of cryptsetup.target.

>> +usr/lib/tmpfiles.d/lvm2.conf
>
> Undocumented in the changelog.
The changelog was merely an example, so feel free to phrase that as you
want. In case you want some input from me, I’d call it “Install
tmpfiles.d(5) configuration for systemd”.

As for your other mail which suggests shipping symlinks to enable the
unit files, are you sure that there is absolutely no use-case in which
users might want to disable the service files? Having the symlinks in
the package will prevent that entirely.

Also, why do you want lvm2-early.service hooked into cryptsetup.target
instead of local-fs.target, as upstream suggests?

-- 
Best regards,
Michael


--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/x6r485jrla@midna.zekjur.net



Bug#728486: Current patch for resolving lvm/systemd compatibility

2014-01-18 Thread Laurent Bigonville
Le Sat, 18 Jan 2014 10:43:30 +0100,
Laurent Bigonville  a écrit :

> Hi,

After a small discussion with Bastian I realized that I was confused
with the generator and lvmetad (I should have done my homework a bit
more carefully).

> Just came here to add my 2¢ about this in the light of my recent
> experience I had with an other package (nut) where devices were not
> present when the daemon was starting.
> 
> My initial solution was also to depends against udev-settle.service
> service. This was ensuring that the devices were present in /dev in
> some, but certainly, not all the cases, especially if the device was
> slow to initialize.
> 
> After some discussion on #udev, it turns out that "udevadm settle" is
> merely flushing the queue of already generated events and it, of
> course, cannot guarantee in anyway that all the events have been
> generated by the kernel.
> 
> So IMHO, adding udev-settle.service shouldn't be the long term
> solution, it will make things work in more case, but not all. And the
> correct solution is to have something like the generator that will
> allow to handle events when they are generated and not at one
> synchronization point during boot.

My concern of devices not being present in the /dev during boot is still
valid IMHO but can only be solved with the introduction of lvmetad (see:
#704759) and not the generator, but this is outside of the scope of this
issue. Sorry for the confusion.

But I still think that installing the generator has an added value when
lvmetad will be used. In this case the central volume group activation
will not be needed anymore as the job will be delegated to the daemon.
The generator will detect this and the .service will not be created,
that means that in this condition the call to udevadm trigger will be
omitted leading to a faster boot.

I unfortunately still doesn't understand on which technical ground the
installation of the generator is being refused and why debian should
diverge on what upstream is proposing.

Anyway I'm happy that this situation will be resolved and that our users
will have a more reliable boot when using LVM. I still think this is
not the optimal solution.

> 
> My 2¢
> 
> Laurent Bigonville


--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140118151114.1a9af...@fornost.bigon.be



Bug#728486: Current patch for resolving lvm/systemd compatibility

2014-01-18 Thread Bastian Blank
Untested patch:

- Static services with the correct name.
- lvm2.service is statically hooked to local-fs.target, as all local
  mounts.
- lvm2-early.service is statically hooked to cryptsetup.target, as all
  crypto devices.

| drwxr-xr-x root/root 0 2014-01-18 12:32 ./lib/systemd/
| drwxr-xr-x root/root 0 2014-01-18 12:49 ./lib/systemd/system/
| -rw-r--r-- root/root   310 2014-01-18 12:34 
./lib/systemd/system/lvm2-early.service
| -rw-r--r-- root/root   301 2014-01-18 12:48 
./lib/systemd/system/lvm2.service
| drwxr-xr-x root/root 0 2014-01-18 12:49 
./lib/systemd/system/cryptsetup.target.wants/
| drwxr-xr-x root/root 0 2014-01-18 12:49 
./lib/systemd/system/local-fs.target.wants/
| lrwxrwxrwx root/root 0 2014-01-18 12:49 
./lib/systemd/system/cryptsetup.target.wants/lvm2-early.service -> 
../lvm2-early.service
| lrwxrwxrwx root/root 0 2014-01-18 12:49 
./lib/systemd/system/local-fs.target.wants/lvm2.service -> ../lvm2.service

Index: 
debian/tree/lvm2/lib/systemd/system/cryptsetup.target.wants/lvm2-early.service
===
--- 
debian/tree/lvm2/lib/systemd/system/cryptsetup.target.wants/lvm2-early.service  
(revision 0)
+++ 
debian/tree/lvm2/lib/systemd/system/cryptsetup.target.wants/lvm2-early.service  
(working copy)
@@ -0,0 +1 @@
+link ../lvm2-early.service
\ No newline at end of file

Property changes on: 
debian/tree/lvm2/lib/systemd/system/cryptsetup.target.wants/lvm2-early.service
___
Added: svn:special
## -0,0 +1 ##
+*
\ No newline at end of property
Index: debian/tree/lvm2/lib/systemd/system/local-fs.target.wants/lvm2.service
===
--- debian/tree/lvm2/lib/systemd/system/local-fs.target.wants/lvm2.service  
(revision 0)
+++ debian/tree/lvm2/lib/systemd/system/local-fs.target.wants/lvm2.service  
(working copy)
@@ -0,0 +1 @@
+link ../lvm2.service
\ No newline at end of file

Property changes on: 
debian/tree/lvm2/lib/systemd/system/local-fs.target.wants/lvm2.service
___
Added: svn:special
## -0,0 +1 ##
+*
\ No newline at end of property
Index: debian/tree/lvm2/lib/systemd/system/lvm2-early.service
===
--- debian/tree/lvm2/lib/systemd/system/lvm2-early.service  (revision 0)
+++ debian/tree/lvm2/lib/systemd/system/lvm2-early.service  (working copy)
@@ -0,0 +1,11 @@
+[Unit]
+Description=Activation of LVM2 logical volumes
+Documentation=man:lvm(8) man:vgchange(8)
+DefaultDependencies=no
+After=systemd-udev-settle.service
+Before=cryptsetup.target local-fs.target shutdown.target
+
+[Service]
+ExecStartPre=/bin/udevadm settle
+ExecStart=/sbin/lvm vgchange -aay --sysinit
+Type=oneshot
Index: debian/tree/lvm2/lib/systemd/system/lvm2.service
===
--- debian/tree/lvm2/lib/systemd/system/lvm2.service(revision 0)
+++ debian/tree/lvm2/lib/systemd/system/lvm2.service(working copy)
@@ -0,0 +1,11 @@
+[Unit]
+Description=Activation of LVM2 logical volumes
+Documentation=man:lvm(8) man:vgchange(8)
+DefaultDependencies=no
+After=lvm2-early.service cryptsetup.target
+Before=local-fs.target shutdown.target
+
+[Service]
+ExecStartPre=/bin/udevadm settle
+ExecStart=/sbin/lvm vgchange -aay --sysinit
+Type=oneshot


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140118122041.ga11...@mail.waldi.eu.org



Bug#728486: Current patch for resolving lvm/systemd compatibility

2014-01-18 Thread Bastian Blank
On Sat, Jan 18, 2014 at 11:47:11AM +0100, Michael Stapelberg wrote:
> --- /dev/null
> +++ b/debian/lvm2-activation-early.service

Wrong name.

> +[Unit]
> +Description=Activation of LVM2 logical volumes
> +Documentation=man:lvm(8) man:vgchange(8)
> +DefaultDependencies=no
> +After=systemd-udev-settle.service
> +Before=cryptsetup.target

This have to be "cryptdisks.service"

> +++ b/debian/lvm2-activation.service

Wrong name.

> +After=lvm2-activation-early.service cryptsetup.target

The same: cryptdisks.service

> +usr/lib/tmpfiles.d/lvm2.conf

Undocumented in the changelog.

Bastian

-- 
Punishment becomes ineffective after a certain point.  Men become insensitive.
-- Eneg, "Patterns of Force", stardate 2534.7


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140118111043.ga11...@mail.waldi.eu.org



Bug#728486: Current patch for resolving lvm/systemd compatibility

2014-01-18 Thread Michael Stapelberg
Hi Don,

Don Armstrong  writes:
> Michael: can you go ahead and prepare the patch to fix #728486 which
> does not use generators so that once the CTTE has resolved the init
> system question we have a patch in front of us that we can rule on?
Of course!

Attached you can find a patch against the current lvm2 version in Debian
which adds two static service files that contain exactly the same
content as what the generator produces¹. The patch also enables
installation of the tmpfiles.d(5) configuration file and makes sure that
the service files are enabled according to best practices². I tested
this on the same test virtual machine that I used all along, and it has
the same effect as enabling the generator, i.e. it fixes the problem.

For convenience, I also attached lvm2.debdiff which shows the
differences in what files are installed, the package’s dependencies, and
how the control files are modified. Best viewed with:

  colordiff --difftype=debdiff < /tmp/lvm2.debdiff

Please let me know if the patch should be changed in any way to better
accomodate the CTTE in ruling on it.

① I removed the SourcePath= directory which is only reasonable in
  generated units. Furthermore I added an [Install] section with
  WantedBy=local-fs.target, which is normally done outside of the unit
  by the generator.

② See https://wiki.debian.org/Systemd/Packaging

-- 
Best regards,
Michael
>From 4eecd2d3168ceb30fc5cc4a9049dfe50e462a8f1 Mon Sep 17 00:00:00 2001
From: Michael Stapelberg 
Date: Sat, 18 Jan 2014 11:07:03 +0100
Subject: [PATCH] systemd support

---
 debian/changelog |7 +++
 debian/control   |2 +-
 debian/lvm2-activation-early.service |   22 ++
 debian/lvm2-activation.service   |   21 +
 debian/lvm2.install  |3 +++
 debian/rules |3 +++
 6 files changed, 57 insertions(+), 1 deletion(-)
 create mode 100644 debian/lvm2-activation-early.service
 create mode 100644 debian/lvm2-activation.service

diff --git a/debian/changelog b/debian/changelog
index 25245bb..c94b8c9 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+lvm2 (2.02.98-6systemd1) unstable; urgency=low
+
+  * Add static systemd service files to fix lvm activation edge cases
+(closes: #728486)
+
+ -- Michael Stapelberg   Sat, 18 Jan 2014 11:02:32 +0100
+
 lvm2 (2.02.98-6) unstable; urgency=low
 
   * Update init script:
diff --git a/debian/control b/debian/control
index a280da0..c4e9a7a 100644
--- a/debian/control
+++ b/debian/control
@@ -3,7 +3,7 @@ Section: admin
 Priority: optional
 Maintainer: Debian LVM Team 
 Uploaders: Bastian Blank 
-Build-Depends: dpkg-dev (>= 1.16.1~), debhelper (>= 8.1.3~), automake, libcman-dev (>> 2), libcorosync-dev, libdlm-dev (>> 2), libreadline-gplv2-dev, libselinux1-dev, libudev-dev, openais-dev, pkg-config
+Build-Depends: dpkg-dev (>= 1.16.1~), debhelper (>= 8.1.3~), automake, libcman-dev (>> 2), libcorosync-dev, libdlm-dev (>> 2), libreadline-gplv2-dev, libselinux1-dev, libudev-dev, openais-dev, pkg-config, dh-systemd
 Standards-Version: 3.9.1
 Homepage: http://sources.redhat.com/lvm2/
 Vcs-Svn: svn://svn.debian.org/pkg-lvm/lvm2/trunk/
diff --git a/debian/lvm2-activation-early.service b/debian/lvm2-activation-early.service
new file mode 100644
index 000..21ba959
--- /dev/null
+++ b/debian/lvm2-activation-early.service
@@ -0,0 +1,22 @@
+# Automatically generated by lvm2-activation-generator.
+#
+# This unit is responsible for direct activation of LVM2 logical volumes
+# if lvmetad daemon is not used (global/use_lvmetad=0 lvm.conf setting),
+# hence volume autoactivation is not applicable.
+# Direct LVM2 activation requires udev to be settled!
+
+[Unit]
+Description=Activation of LVM2 logical volumes
+Documentation=man:lvm(8) man:vgchange(8)
+DefaultDependencies=no
+After=systemd-udev-settle.service
+Before=cryptsetup.target
+Before=local-fs.target shutdown.target
+Wants=systemd-udev-settle.service
+
+[Service]
+ExecStart=/sbin/lvm vgchange -aay --sysinit
+Type=oneshot
+
+[Install]
+WantedBy=local-fs.target
diff --git a/debian/lvm2-activation.service b/debian/lvm2-activation.service
new file mode 100644
index 000..9b273fd
--- /dev/null
+++ b/debian/lvm2-activation.service
@@ -0,0 +1,21 @@
+# Automatically generated by lvm2-activation-generator.
+#
+# This unit is responsible for direct activation of LVM2 logical volumes
+# if lvmetad daemon is not used (global/use_lvmetad=0 lvm.conf setting),
+# hence volume autoactivation is not applicable.
+# Direct LVM2 activation requires udev to be settled!
+
+[Unit]
+Description=Activation of LVM2 logical volumes
+Documentation=man:lvm(8) man:vgchange(8)
+DefaultDependencies=no
+After=lvm2-activation-early.service cryptsetup.target
+Before=local-fs.target shutdown.target
+Wants=systemd-udev-settle.service
+
+[Service]
+ExecStart=/sbin/lvm vgchange -aay --sysinit
+Type=oneshot
+
+[Install]
+WantedBy=local-fs.target

Bug#728486: Current patch for resolving lvm/systemd compatibility

2014-01-18 Thread Laurent Bigonville
Hi,

Just came here to add my 2¢ about this in the light of my recent
experience I had with an other package (nut) where devices were not
present when the daemon was starting.

My initial solution was also to depends against udev-settle.service
service. This was ensuring that the devices were present in /dev in
some, but certainly, not all the cases, especially if the device was
slow to initialize.

After some discussion on #udev, it turns out that "udevadm settle" is
merely flushing the queue of already generated events and it, of course,
cannot guarantee in anyway that all the events have been generated by
the kernel.

So IMHO, adding udev-settle.service shouldn't be the long term
solution, it will make things work in more case, but not all. And the
correct solution is to have something like the generator that will
allow to handle events when they are generated and not at one
synchronization point during boot.

My 2¢

Laurent Bigonville


--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140118104330.13df2...@fornost.bigon.be



Bug#728486: Current patch for resolving lvm/systemd compatibility

2014-01-17 Thread Don Armstrong
Michael: can you go ahead and prepare the patch to fix #728486 which
does not use generators so that once the CTTE has resolved the init
system question we have a patch in front of us that we can rule on?

Thanks.

-- 
Don Armstrong  http://www.donarmstrong.com

Judge if you want.
We are all going to die.
I intend to deserve it.
 -- a softer world #421
http://www.asofterworld.com/index.php?id=421


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140118044801.ge12...@teltox.donarmstrong.com



Bug#728486: Current patch for resolving lvm/systemd compatibility

2014-01-16 Thread Bastian Blank
On Mon, Dec 02, 2013 at 03:11:03PM -0800, Don Armstrong wrote:
> On Mon, 02 Dec 2013, Bastian Blank wrote:
> > On Sun, Dec 01, 2013 at 05:49:13PM -0800, Don Armstrong wrote:
> > > Bastian: Would such a patch be acceptable in principle?
> > After systemd was fixed, yes.
> Can you let me know which part of systemd needed to be fixed? [What bug#
> is this?]

It is #720850.  systemd breaks backward compatibility.

> Can you also clarify for me why the patch needs to wait for systemd to
> be fixed?

Because the lvm2 service would fail the same way then the init script.

Bastian

-- 
We have found all life forms in the galaxy are capable of superior
development.
-- Kirk, "The Gamesters of Triskelion", stardate 3211.7


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140116134756.ga2...@mail.waldi.eu.org



Bug#728486: Current patch for resolving lvm/systemd compatibility

2013-12-02 Thread Don Armstrong
On Mon, 02 Dec 2013, Bastian Blank wrote:
> On Sun, Dec 01, 2013 at 05:49:13PM -0800, Don Armstrong wrote:
> > Bastian: Would such a patch be acceptable in principle?
> 
> After systemd was fixed, yes.

Can you let me know which part of systemd needed to be fixed? [What bug#
is this?]

Can you also clarify for me why the patch needs to wait for systemd to
be fixed?

-- 
Don Armstrong  http://www.donarmstrong.com

Leukocyte... I am your father.
 -- R. Stevens http://www.dieselsweeties.com/archive.php?s=1546


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131202231103.gm4...@rzlab.ucr.edu



Bug#728486: Current patch for resolving lvm/systemd compatibility

2013-12-02 Thread Steve Langasek
Hi Michael,

On Mon, Dec 02, 2013 at 11:48:54PM +0100, Michael Stapelberg wrote:
> Hi Don,

> Don Armstrong  writes:
> > I'd like to get this particular bug discussion restarted.
> Thanks for your mail.

> > From my understanding, a static, non generator version of
> > lvm2_activation_generator_systemd_red_hat.c will allow for the
> > activation of lvm2 after the addition of an lvm device by udev/systemd.
> >
> > Michael: Is this correct?
> To the best of my knowledge, a static non-generator patch will make lvm2
> work with systemd, yes.

> I offer to work on producing an easily mergable patch, should Bastian
> agree to that.

This was my concern with the technical implementation as well.  I would be
happy with lvm2/systemd integration that used a static configuration instead
of requiring a generator.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature


Bug#728486: Current patch for resolving lvm/systemd compatibility

2013-12-02 Thread Bastian Blank
On Sun, Dec 01, 2013 at 05:49:13PM -0800, Don Armstrong wrote:
> Bastian: Would such a patch be acceptable in principle?

After systemd was fixed, yes.

Bastian

-- 
Conquest is easy. Control is not.
-- Kirk, "Mirror, Mirror", stardate unknown


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131202225150.ga9...@mail.waldi.eu.org



Bug#728486: Current patch for resolving lvm/systemd compatibility

2013-12-02 Thread Michael Stapelberg
Hi Don,

Don Armstrong  writes:
> I'd like to get this particular bug discussion restarted.
Thanks for your mail.

> From my understanding, a static, non generator version of
> lvm2_activation_generator_systemd_red_hat.c will allow for the
> activation of lvm2 after the addition of an lvm device by udev/systemd.
>
> Michael: Is this correct?
To the best of my knowledge, a static non-generator patch will make lvm2
work with systemd, yes.

I offer to work on producing an easily mergable patch, should Bastian
agree to that.

-- 
Best regards,
Michael


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/x67gbmamy1@midna.lan



Bug#728486: Current patch for resolving lvm/systemd compatibility

2013-12-01 Thread Don Armstrong
I'd like to get this particular bug discussion restarted.

From my understanding, a static, non generator version of
lvm2_activation_generator_systemd_red_hat.c will allow for the
activation of lvm2 after the addition of an lvm device by udev/systemd.

Michael: Is this correct?

Bastian: Would such a patch be acceptable in principle?

-- 
Don Armstrong  http://www.donarmstrong.com

Let us chat together a moment, my friend. There are still several
hours until dawn, and I have the whole day to sleep.
 -- Count Orlock in _Nosferatu (1922)_


--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131202014913.ge6...@teltox.donarmstrong.com