Andrei Borzenkov wrote:
05.07.2020 11:09, Per Jessen пишет:
Per Jessen wrote:
No units are generated from fstab?
Correct, no units were auto-generated from fstab (following a daemon-reload).
Anyway, "journalctl -b" with "systemd.log_level=debug" and without "quiet" on kernel command line would be helpful. printk.devkmsg=on may be useful during initrd phase as well.
Okay, I'll add those and get back.
First feedback - adding the above and rebooting, and I see the auto-generated automount units:
UNIT LOAD ACTIVE SUB DESCRIPTION ● home-hostsuisse.automount loaded failed failed home-hostsuisse.automount home-per-Photos.automount loaded active running home-per-Photos.automount home-per-Photos2.automount loaded active running home-per-Photos2.automount ● home-spamchek.automount loaded failed failed home-spamchek.automount
The two 'Photos' mounts both work.
I guess one conclusion is that 'daemon-reload' isn't enough to re-run the fstab generator?
Debug output here - https://files.jessen.ch/office68-journalctl-b.txt.gz I expect the below is the interesting bit ?
# zgrep spamchek /tmp/office68-journalctl-b.txt.gz Jul 05 09:51:33 localhost systemd-fstab-generator[447]: Found entry what=fileserver.local.net:/home/spamchek where=/home/spamchek type=nfs nofail=no noauto=no Jul 05 09:51:33 localhost systemd[1]: home-spamchek.automount: Installed new job home-spamchek.automount/start as 215 Jul 05 09:51:34 localhost systemd[1]: home-spamchek.automount: Changed dead -> waiting Jul 05 09:51:34 localhost systemd[1]: home-spamchek.automount: Job home-spamchek.automount/start finished, result=done Jul 05 09:51:34 localhost systemd[1]: Set up automount home-spamchek.automount. Jul 05 09:52:12 localhost.localdomain systemd[1]: home-spamchek.automount: Got invalid poll event 16 on pipe (fd=40) Jul 05 09:52:12 localhost.localdomain systemd[1]: home-spamchek.automount: Changed waiting -> failed Jul 05 09:52:12 localhost.localdomain systemd[1]: home-spamchek.automount: Unit entered failed state.
You are likely hitting https://bugzilla.opensuse.org/show_bug.cgi?id=1116625 where NM nfs dispatcher script unmounts systemd-automount-managed mount points due to lack of NFS connectivity. At least, "invalid poll event" exactly follows running nm-dispatcher and errors from ping.
The above system (office68) does indeed use NM.
You may want to enable NM debugging instead to get better picture what happens. Unfortunately, enabling debugging often changes timing and makes race condition go away. But still it is better than nothing. In particular, I am not sure why this code would run at boot, but it fits symptoms exactly.
Try change suggested in https://bugzilla.opensuse.org/show_bug.cgi?id=1116625#c32 whether it helps. There was no feedback from reporter.
I've amended that script and re/started the automount units, we'll see what happens. The last comment in the report says "backported" to all supported distros.
Also if you do not need NM, testing with wicked also makes sense.
The other system (office38) uses wicked, but although the fstab generation works, the automount units are dead? I'll add the debug setup to that system too. Thanks for digging out that report. -- Per Jessen, Zürich (27.9°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org