Re: [systemd-devel] automount fails with generic "resources" error

2018-01-27 Thread Olaf Hering 
On Tue, Jan 23, Lennart Poettering wrote:

> On Mo, 15.01.18 15:13, Olaf Hering (o...@aepfle.de) wrote:
> 
> > '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


signature.asc
Description: PGP signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] automount fails with generic "resources" error

2018-01-23 Thread Lennart Poettering 
On Mo, 15.01.18 15:13, Olaf Hering (o...@aepfle.de) wrote:

> '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
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] automount fails with generic "resources" error

2018-01-15 Thread Olaf Hering 
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:

...
root@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)
root@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)
root@anonymi:~ # lsblk -f
NAMEFSTYPE 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   TW5062f2e1-2c31-4291-8092-07fe74295061
└─sda17 ext3   VM_IMAGES 49f90684-3df3-4157-bb38-b92e3935e1d6
root@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


signature.asc
Description: PGP signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel