Discussion:
automount fails with generic "resources" error
(too old to reply)
Olaf Hering
2018-01-15 14:13:52 UTC
Permalink
Since I discovered the automount feature I started to add it to fstab,
as shown below, on several systems with various versions of systemd.
Most of the time it works fine. But sometimes units fail to start.
Google does not give much hints about that, nor a pointer what limits
must be raised to avoid it, nor what (low) limits could be the cause.

Current event, which triggered this message:

...
***@anonymi:~ # systemctl status LEAP42.2.mount
● LEAP42.2.mount - /LEAP42.2
Loaded: loaded (/etc/fstab; generated; vendor preset: disabled)
Active: inactive (dead)
Where: /LEAP42.2
What: /dev/disk/by-label/LEAP42.2
Docs: man:fstab(5)
man:systemd-fstab-generator(8)
***@anonymi:~ # systemctl status LEAP42.2.automount
● LEAP42.2.automount
Loaded: loaded (/etc/fstab; generated; vendor preset: disabled)
Active: failed (Result: resources)
Where: /LEAP42.2
Docs: man:fstab(5)
man:systemd-fstab-generator(8)
***@anonymi:~ # lsblk -f
NAME FSTYPE LABEL UUID MOUNTPOINT
sda
├─sda1 btrfs BOOT d398bdb5-1622-43e4-887c-c7584567078d /chainloader
├─sda2 swap SWAP 815eef7d-9586-4c5a-87a1-f1f81ed6c67a [SWAP]
├─sda3
├─sda5 ext3 SLES11SP2 d393f3fc-5959-4688-af3d-3fd8d7c869b4
├─sda6 ext3 SLES11SP3 f9b6a27b-2fb3-449f-b4d8-a1a7a866da3c
├─sda7 ext3 SLES11SP4 965a3749-06db-4895-8eee-660cedeca9ab
├─sda8 ext4 SLES15SP0 4bf640b6-5d9f-4a5c-98bf-ef63b0543fab /
├─sda9 ext3 SLES12GA 11071484-04e2-46a0-b4ce-d478c702ed28
├─sda10 ext3 SLES12SP1 154174be-edf9-44cc-8bf5-a176c8e66495
├─sda11 ext3 SLES12SP2 26a65e63-bcd4-4482-9750-acd4bc092afc
├─sda12 ext3 SLES12SP3 78d6ab38-79b9-458c-97d0-3bfbbf12ff94
├─sda13 ext3 LEAP42.1 015ce2d3-21ff-4bd6-8057-81acda9515d3
├─sda14 ext3 LEAP42.2 d2530d52-04e2-4574-91ea-65e45f0d7bf0
├─sda15 ext3 LEAP42.3 d436294f-8e8e-4d28-ad2d-5891637732cb
├─sda16 ext3 TW 5062f2e1-2c31-4291-8092-07fe74295061
└─sda17 ext3 VM_IMAGES 49f90684-3df3-4157-bb38-b92e3935e1d6
***@anonymi:~ # grep LEA /etc/fstab
LABEL=LEAP42.1 /LEAP42.1 ext3 ro,noatime,,x-systemd.automount,x-systemd.idle-timeout=11 1 2
LABEL=LEAP42.2 /LEAP42.2 ext3 ro,noatime,,x-systemd.automount,x-systemd.idle-timeout=11 1 2
LABEL=LEAP42.3 /LEAP42.3 ext3 ro,noatime,,x-systemd.automount,x-systemd.idle-timeout=11 1 2
...

'journalctl -b' does not indicate any related failure.

Does anyone happen to know what limits a mount point or an automount
point might have? These systems have plenty of cpus, have plenty of
memory, likely enough to handle these few fstab entries during bootup.

Is there a way to boot with debug enabled, but not spam the serial
console with lots of noise while the issue does not happen?

Olaf
Lennart Poettering
2018-01-23 20:48:25 UTC
Permalink
Post by Olaf Hering
'journalctl -b' does not indicate any related failure.
Does anyone happen to know what limits a mount point or an automount
point might have? These systems have plenty of cpus, have plenty of
memory, likely enough to handle these few fstab entries during bootup.
Is there a way to boot with debug enabled, but not spam the serial
console with lots of noise while the issue does not happen?
"resources" is a bit misleading... It's our catch-all result code if
some kernel API returned an error we didn't expect. Most likely
(hopefully?) there's more info about what operation failed in the
logs. Do you see anything there? If you can reproduce it, can you turn
on "systemd-analyze set-log-level debug" before it maybe to get more
detailed output?

Lennart
--
Lennart Poettering, Red Hat
Olaf Hering
2018-01-27 19:03:36 UTC
Permalink
Post by Lennart Poettering
Post by Olaf Hering
'journalctl -b' does not indicate any related failure.
Does anyone happen to know what limits a mount point or an automount
point might have? These systems have plenty of cpus, have plenty of
memory, likely enough to handle these few fstab entries during bootup.
Is there a way to boot with debug enabled, but not spam the serial
console with lots of noise while the issue does not happen?
"resources" is a bit misleading... It's our catch-all result code if
some kernel API returned an error we didn't expect. Most likely
(hopefully?) there's more info about what operation failed in the
logs. Do you see anything there? If you can reproduce it, can you turn
on "systemd-analyze set-log-level debug" before it maybe to get more
detailed output?
There was nothing obvious in the logs, but debug was not enabled AFAIK.

But it turned out the mount point did not exist in this case. Once
created, all "automount" entries in fstab worked fine.

I have seen this generic error on a few more systems. I will enable
debug once I get the chance to work on these systems.


Olaf

Loading...