`mountpoint(1)` gives two different results?

stefan · 2014-10-12 16:12:23

At the same time, `mountpoint /media/NIKON_D7100` returns `yes` and
`no`, depending on whether it's called from within `udev` or not. Why
is that?

I'm playing with `udev` to automount a pendrive, without using any
desktop environment (that's why gnom-centric approaches like `udisks`
are out of the game).

Anyways, even if you don't agree with the approach, the following
observation is scary.

I've started with a `udev` rule from stackexchange [1], with minor
modifications. If you plug in a pendrive with a partition named
`NIKON_D7100`, it should create a directory `/media/NIKON_D7100`, and
mount the partition there.

This is `/etc/udev/rules.d/11-media-by-label-auto-mount.rules`:

KERNEL!="sd[d-z][0-9]", GOTO="media_by_label_auto_mount_end"

# Import FS infos
IMPORT{program}="/sbin/blkid -o udev -p %N"

# Get a label if present, otherwise specify one
ENV{ID_FS_LABEL}!="", ENV{dir_name}="%E{ID_FS_LABEL}"
ENV{ID_FS_LABEL}=="", ENV{dir_name}="usbhd-%k"

# Global mount options
ACTION=="add", ENV{mount_options}="users,relatime"
# Filesystem-specific mount options
ACTION=="add", ENV{ID_FS_TYPE}=="vfat|ntfs", ENV{mount_options}="$env{mount_options},utf8,umask=002"

# Mount the device
ACTION=="add", RUN+="/bin/mkdir -p '/media/$env{dir_name}'", RUN+="/bin/mount -o '$env{mount_options}' '/dev/%k' '/media/$env{dir_name}'"

# Mount the device, debugging version
#ACTION=="add", RUN+="/bin/media_automount '$env{mount_options}' '/dev/%k' '/media/$env{dir_name}'"

# Clean up after removal
ACTION=="remove", ENV{dir_name}!="", RUN+="/bin/umount -l '/media/$env{dir_name}'", RUN+="/bin/rmdir '/media/$env{dir_name}'"

# Exit
LABEL="media_by_label_auto_mount_end"

Do not forget to run `udevadm control --reload-rules` after editing
the file!

But this never worked. The directory `/media/NIKON_D7100` was
created, but the mounting never happened — or so I guess. For
debugging, I've decided to move the functionality to a helper script,
see the section marked with `Mount the device, debugging version`.

If you uncomment the debugging version, comment the non-debugging
version, and run `udevadm control --reload-rules` again, the helper
should be used:

It relies on the helper script `/bin/media_automount`:

#!/bin/bash

mkdir -p "$3" 2>&1 | logger -t media
mount -v -o "$1" "$2" "$3" 2>&1 | logger -t media

# check for successful mounting, twice!
mountpoint "$3" | logger -t media
sleep 10;
mountpoint "$3" | logger -t media

Now the funny thing: `journalctl -fl` will show

Oct 12 17:59:28 tauhou media[5237]: /media/NIKON_D7100 is a mountpoint
Oct 12 17:59:38 tauhou media[5242]: /media/NIKON_D7100 is a mountpoint

but when I ask on the terminal, just between the two messages popping
ub in the journal, I'll get a different answer:

# mountpoint /media/NIKON_D7100
/media/NIKON_D7100 is not a mountpoint

Why?

____________________
[1] http://unix.stackexchange.com/questions … eplacement

falconindy · 2014-10-13 12:52:39

stefan wrote:

I'm playing with `udev` to automount a pendrive [...]

You can't mount things from udev rules -- the mounting occurs in a separate namespace which isn't propagated back to the "root" namespace (where you're running mountpoint from).

stefan · 2014-10-14 00:04:24

falconindy wrote:

You can't mount things from udev rules -- the mounting occurs in a separate namespace

Namespace? I've never heared that word in this context. Where can I find more docs?

Thx,
Stefan

stefan · 2014-10-15 08:38:41

I have extended my script `/bin/media_automount` from above with the
line

mountpoint "$3" && logger -t media "$3 is a mountpoint" && date > "$3/lastmount"

and this actually writes the file `/media/NIKON_D7100/lastmount` when
I plug in the pendrive. Although all mount information available to
the user claims that neither the device is mounted, nor the mountpoint
is a mountpoint.

I consider this a bug:

Different “namespaces” seem to have different concepts of whether a
device is mounted or not. So someone may unplug a device because he
is told the device would not be mounted, while it actually is mounted
(and used) in another namespace. This may lead to unplugging a
mounted device, with all the dreaded consequences.

There is only one device in reality, and it should be mounted, or it
should be save to remove. Anything else feels just wrong to me.

I need to learn more (i.e.: why am I wrong here) or I'll file a bug
report. Does anybody know what's the correct place to do so? Is it a
Kernel bug? or what?

--Stefan

deepsoul · 2015-04-22 13:36:32

Sorry for posting so late. I had / have the same problem and have solved it as described here.

This seems to have broken recently - removing or changing the MountFlags option has no effect any more. In the long run, the only solution will be to create a relay or proxy that redirects the information coming from udev to a program running in the same namespace and control group that normal users see. This is a braindead thing necessitated by systemd's tendency to break things on purpose. Every post I have found on the topic simply says "systemd-udevd does not allow you to do that" without even questioning why this is a good idea. Supposedly mounts may take too long to complete and cause problems that way, but I have never encountered any; and in any case this tradeoff should be decided by the owner/administrator, not Lord Poettering.

Arch Linux

#1 2014-10-12 16:12:23

`mountpoint(1)` gives two different results?

#2 2014-10-13 12:52:39

Re: `mountpoint(1)` gives two different results?

#3 2014-10-14 00:04:24

Re: `mountpoint(1)` gives two different results?

#4 2014-10-15 08:38:41

Re: `mountpoint(1)` gives two different results?

#5 2015-04-22 13:36:32

Re: `mountpoint(1)` gives two different results?

Board footer