From: Andy Kittner <andy.kittner@gmail.com>
To: linux-lvm@redhat.com
Subject: [linux-lvm] Race condition in udev_is_running check when running under systemd
Date: Sun, 18 May 2014 23:44:07 +0200 [thread overview]
Message-ID: <llb9j7$b01$1@ger.gmane.org> (raw)
Hi all,
first of I hope I have come to the right place for reporting (possible)
bugs, if not feel free to give me a gentle kick in the right direction
;)
After updating to systemd-212 I was experiencing problems with
cryptsetup for a while. systemd would open and close my encrypted
partitions in rapid succession, causing dependent services like fsck to
fail most of the time because the device vanished again.
After some discussion on the systemd mailing list and a bit of debugging
I found that the root of the issue is, that when systemd calls cryptsetup
the _check_udev_is_running() function (in ./libdm/libdm-common.c) would
still return false.
This causes libdm to create some device nodes itself, and that in turn
apparently to causes the problems with systemd thinking the device has
vanished.
According to the systemd developers this issue should be fixed on the
libdm side. To quote the relevant part from the mails there:
>On 15/05/14 23:38, Lennart Poettering wrote:
>> On Thu, 15.05.14 23:15, Andy Kittner (andy.kittner@gmail.com) wrote:
>>> Anyway, my conclusion from this is that either the LVM guys need to
>>> use another method to detect that udev is running, or systemd should
>>> not start the cryptsetup stuff until udev is fully initialized.
>>
>> Nope, we don't need more synchronization. The LVM guys should stop doing
>> mknod() on their own.
For full details see the thread here
http://thread.gmane.org/gmane.comp.sysutils.systemd.devel/18992/focus=19069
Regards,
Andy
next reply other threads:[~2014-05-18 21:50 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-18 21:44 Andy Kittner [this message]
2014-05-19 8:00 ` [linux-lvm] Race condition in udev_is_running check when running under systemd Peter Rajnoha
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='llb9j7$b01$1@ger.gmane.org' \
--to=andy.kittner@gmail.com \
--cc=linux-lvm@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).