[systemd-devel] systemd blocks update kernel partition table

Lennart Poettering lennart at poettering.net
Fri Nov 23 09:26:07 UTC 2018


On Do, 22.11.18 19:57, Eberhard Stoll (e-stl at gmx.de) wrote:

> > It could be that they remain mounted within another mount namespace. You
> > don't have any weird udev rules which call `mount`, do you?
> > 
> > If you have a recent util-linux, run `sudo lsns -t mnt` to see live
> > namespaces. For each non-kernel process ID in the list, run something
> > like `findmnt -F /proc/$PID/mountinfo` (or `cat` the file). If you
> > don't, then `grep mmcblk1 /proc/*/mountinfo` should do the job as well.
> 
> Yes, i found a udev rule which should mount any usb drive which is plugged
> in. This is also true for my emmc device:
> 
>     # Media automounting
>     SUBSYSTEM=="block", ACTION=="add"    RUN+="/etc/udev/scripts/mount.sh"
>     SUBSYSTEM=="block", ACTION=="remove" RUN+="/etc/udev/scripts/mount.sh"
>     SUBSYSTEM=="block", ACTION=="change", ENV{DISK_MEDIA_CHANGE}=="1"
> RUN+="/etc/udev/scripts/mount.sh"
> 
> And systemd-udevd is running in an own namespace:
>     root at t1000-multi:~# lsns -t mnt
>     NS TYPE NPROCS   PID USER             COMMAND
>     4026531840 mnt      88     1 root             /sbin/init
>     4026531861 mnt       1    18 root             kdevtmpfs
>     4026532470 mnt       1   125 root /lib/systemd/systemd-udevd
>     4026532483 mnt       1   194 systemd-timesync
> /lib/systemd/systemd-timesyncd
>     4026532484 mnt       1   212 systemd-network
> /lib/systemd/systemd-networkd
>     4026532502 mnt       1   262 systemd-resolve
> /lib/systemd/systemd-resolved
> 
> I wonder what is the preferred way to automount removable media especially
> in embedded devices?
> 
> Is using 'MountFlags=shared' for systemd-udevd a common solution? Or should
> i prefer systemd automounting?
> With systemd automount i have to declare all devices statically. This could
> be a disadvantage.
> 
> Do you have some hints for me?

Use the "systemd-mount" tool for removable media. It's *the* tool of
choice, as it will ensure that fsck is run before the media is
mounted, and it will use the kernel's automount logic so that that the
fs appears continously mounted while the file system is actually
unmounted quickly after each access. Both of these means that the best
guarantees tha the fs on the removable remains in a clean state.

systemd-mount also means that fsck/mount are called in service
context as children from PID 1, hence aren't affected by the fs
namespacing applied to udev.

Lennart

-- 
Lennart Poettering, Red Hat


More information about the systemd-devel mailing list