Mailinglist Archive: opensuse-support (155 mails)

< Previous Next >
Re: [opensuse-support] A stop job is running for User Manager for UID 0 (nnnnnnnnn/2min)
Hi there,

On Sun, 17 Mar 2019, 10:53:51 +0100, stakanov wrote:
In data domenica 17 marzo 2019 06:44:46 CET, Felix Miata ha scritto:
This huge reboot/shutdown delay is highly annoying. When shutdown needs to
happen, it needs to happen now, not at the whim of systemd. I haven't
figured out what triggers it, but it seems like maybe something that
happens during zypper dup related to KDM(3 or 4) or Plasma5. It doesn't
always happen. Last to happen here was on TW20190314 host big31 on first
post-dup boot. What make ps -A produce " 983 ? 00:00:00 (sd-pam)"?
What exactly is "User Manager"? Is this just happening to me?
No, to me too, in TW recently.

It happens normally if you close in one user the machine while having a
second
session open. If not second user is open, it might be a regression of sddm
holding open some files of that user after he she it has been logged off.
sd-pam is the user manager for the authorizations of systemd if I am not
wrong.
A short search shows: no, definitely you are NOT the only one.

https://www.startpage.com/do/dsearch?query=sd-pam&cat=web&pl=ext-ff&language=english

funnily it happened to me yesterday that I finally was so frustrated not
knowing what this might be caused by, that I started looking at
potential reasons, and, I believe I found a solution which appears to
work for me.

It does (did) not only happen on Tumbleweed, but also on Leap 15.0 and
even on 42.3, though admittedly not so often.

TLDR; I found out this is caused by some time'ing defaults of the NFS
server. Dunno if you are using it, but if nfs-kernel-server installed on
your system, read on ;)

When I started to try out 15.1 I decided to start with a minimal (the
Server role) installation. Luckily I failed to see such delays when
shutting down or rebooting. I then installed additional packages which I
usually need on all my systems, followed by a reboot just to see if
something might have a bad result. After I installed the
nfs-kernel-server, configured it, rebooted, VOILA, the system waited for
something to happen, but didn't tell what.

I then remembered some messages on Leap 15.0 systems related with NFS
services:

nfsdcltrack[10193]: Unable to write to /proc/fs/nfsd/v4_end_grace: Device or
resource busy

Auntie Google then revealed that we're not alone; Red Hat users are
seeing similar behaviour in that accessing NFS shares is delayed after
the service is started or restarted. I then tried out their proposal
which means to set nfsv4leasetime to something lower than the default 90
seconds; the Red Hat fix also described to set nfsv4gracetime to a
similarly lower value to cure the delayed mount requests.

I have now configured this on all my systems including Leap 42.3, and,
knock on wood, none of the systems showed the delays when rebooting or
shutting down!

These are the changes on my systems:

# cat /etc/sysctl.d/90-nfs.conf
fs/nfs/nlm_grace_period = 10
# grep -i leasetime /etc/sysconfig/nfs
NFSV4LEASETIME="10"

On Leap 15.0 and newer the following needs to be done in addition:

# cat >> /etc/sysconfig/nfs << '__EOF__'

## Path: Network/File systems/NFS server
## Description: Grace time for NFSv4 leases
## Type: integer
## Default: ""
#
# Set the grace time for the NFSv4 and NLM (for NFSv2 and
# NFSv3). New file open requests (NFSv4) and new file locks
# (NLM) will not be allowed until after this time has passed
# to allow clients to recover state.
NFSV4GRACETIME="10"
__EOF__
# /etc/nfs.conf.local
[nfsd]
grace-time=$NFSV4GRACETIME


Again, when you know NFS plays a role on your systems, I'd suggest you
look into this, too.

HTH, cheers.

l8er
manfred
< Previous Next >
Follow Ups
References