From: Raphael Lisicki <raphael.lisicki@siemens.com>
To: Jan Kiszka <jan.kiszka@siemens.com>,
"Bezdeka, Florian" <florian.bezdeka@siemens.com>,
"isar-users@googlegroups.com" <isar-users@googlegroups.com>,
Quirin Gylstorff <quirin.gylstorff@siemens.com>
Subject: Re: expand-on-first-boot and surprising umounts
Date: Thu, 27 Oct 2022 16:36:20 +0200 [thread overview]
Message-ID: <328a0684-0c8a-2066-f20e-c6268aeee4aa@siemens.com> (raw)
In-Reply-To: <4535d7d7-359a-0cf6-633b-2ca06c3cee8a@siemens.com>
On 21.10.22 18:38, Jan Kiszka wrote:
>
> I recall our theory that a delayed device removal/replug event from the
> kernel after the partition table manipulation of expand-on-first-boot
> may confuse systemd to unmount but not remount the data partition again.
>
> Jan
>
I have enabled debug for systemd and udevd, gladly, this did not fix the
race condition but bombarded me with logs and confirms that suspicion:
for /data:
Oct 27 10:04:09 localhost systemd-udevd[289]: sda7: Device (SEQNUM=1809, ACTION=add) processed
Oct 27 10:04:10 localhost systemd-udevd[273]: sda7: Device (SEQNUM=2082, ACTION=remove) processed
Oct 27 10:04:10 localhost systemd-udevd[273]: sda7: Device (SEQNUM=2083, ACTION=add) processed
Oct 27 10:04:10 localhost systemd-udevd[288]: sda7: Device (SEQNUM=2095, ACTION=change) processed
while for / (sda1):
Oct 27 10:04:09 localhost systemd-udevd[279]: sda1: Device (SEQNUM=1803, ACTION=add) processed
Oct 27 10:04:10 localhost systemd-udevd[279]: sda1: Device (SEQNUM=2089, ACTION=change) processed
Unfortunantely, the reason why the remova action is produced is not
completely obvios, but the nearest hit is:
Oct 27 10:04:09 localhost systemd-udevd[272]: sda: Inotify event: 8 for /dev/sda // IN_CLOSE_WRITE
...
Oct 27 10:04:09 localhost systemd-udevd[272]: sda: device is closed, synthesising 'change' on /sys/devices/pci0000:00/0000:00:1f.2/ata1/host0/target0:0:0/0:0:0:0/block/sda
Oct 27 10:04:09 localhost systemd-udevd[272]: sda: device is closed, synthesising 'change' on /sys/devices/pci0000:00/0000:00:1f.2/ata1/host0/target0:0:0/0:0:0:0/block/sda/sda1
Oct 27 10:04:09 localhost systemd-udevd[272]: sda: device is closed, synthesising 'change' on /sys/devices/pci0000:00/0000:00:1f.2/ata1/host0/target0:0:0/0:0:0:0/block/sda/sda2
Oct 27 10:04:09 localhost systemd-udevd[272]: sda: device is closed, synthesising 'change' on /sys/devices/pci0000:00/0000:00:1f.2/ata1/host0/target0:0:0/0:0:0:0/block/sda/sda3
Oct 27 10:04:09 localhost systemd-udevd[272]: sda: device is closed, synthesising 'change' on /sys/devices/pci0000:00/0000:00:1f.2/ata1/host0/target0:0:0/0:0:0:0/block/sda/sda4
Oct 27 10:04:09 localhost systemd-udevd[272]: sda: device is closed, synthesising 'change' on /sys/devices/pci0000:00/0000:00:1f.2/ata1/host0/target0:0:0/0:0:0:0/block/sda/sda5
Oct 27 10:04:09 localhost systemd-udevd[272]: sda: device is closed, synthesising 'change' on /sys/devices/pci0000:00/0000:00:1f.2/ata1/host0/target0:0:0/0:0:0:0/block/sda/sda6
Oct 27 10:04:09 localhost systemd-udevd[272]: sda: device is closed, synthesising 'change' on /sys/devices/pci0000:00/0000:00:1f.2/ata1/host0/target0:0:0/0:0:0:0/block/sda/sda7
Oct 27 10:04:09 localhost systemd-udevd[272]: sda7: Inotify event: 8000 for /dev/sda7 // IN_IGNORED ?
Oct 27 10:04:09 localhost systemd-udevd[272]: sda7: Removing watch
What would be the correct solution here, as the IN_IGNORED means "Watch
was removed explicitly (inotify_rm_watch(2)) or automatically (file was
deleted, or filesystem was unmounted)." So looks like systemd behavior looks
fine, and the only option would be to cancel contradicting events, which would
be the next race condition.
Sounds to me like the only fix is to make sure that all event-queues are processed
before proceeding with mounting stuff, after expand-on-first-boot, right?
best regards
raphael
next prev parent reply other threads:[~2022-10-27 14:36 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-21 7:48 Raphael Lisicki
2022-10-21 8:45 ` Bezdeka, Florian
2022-10-21 9:36 ` Raphael Lisicki
2022-10-21 9:41 ` Bezdeka, Florian
2022-10-21 13:05 ` Jan Kiszka
2022-10-21 16:38 ` Jan Kiszka
2022-10-27 14:36 ` Raphael Lisicki [this message]
2022-10-21 16:24 ` Raphael Lisicki
2022-10-21 11:15 ` Henning Schild
2022-10-21 15:41 ` Roberto A. Foglietta
2022-10-21 16:15 ` Bezdeka, Florian
2022-10-21 17:35 ` Roberto A. Foglietta
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=328a0684-0c8a-2066-f20e-c6268aeee4aa@siemens.com \
--to=raphael.lisicki@siemens.com \
--cc=florian.bezdeka@siemens.com \
--cc=isar-users@googlegroups.com \
--cc=jan.kiszka@siemens.com \
--cc=quirin.gylstorff@siemens.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