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...

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

On Sun, 17 Mar 2019, 13:55:36 +0100, gumb wrote:

On 17/03/2019 12:08, Manfred Hollstein wrote:

...

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 ;)

snip

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

Is it possible that a similar effect occurs after setting up a Samba share / cifs mount?

To be honest, I don't know enough about Samba wrt/. FWIW, I forgot to mention that the remote file systems like NFS (and even Samba) get auto-mounted using autofs here. This might be the reason why it sometimes causes problems to shut down a system, while sometimes it doesn't (because autofs has unmounted them long enough). FWIW2: I haven't yet installed/configured Samba (SMB/CIFS) on my 15.1 system, so the issue *I* see here is definitely caused by NFS.

gumb

Cheers. l8er manfred

On 3/18/19 12:16 AM, Oleksii Vilchanskyi wrote:

Some keyboards don't support n-key rollover, so to do it on them, you press Alt, press PrtSc (that can be two keys, so in total -- 3 keys pressed), release PrtSc, press R, wait 2-4 seconds, press I, ..., release Alt.

It should say: "press Alt, press PrtSc (that can be two keys, so in total -- 3 keys pressed), release PrtSc, press R, release R, wait 2-4 seconds, press I, ..., release Alt." -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org

Hi Felix, On Wed, 20 Mar 2019, 09:31:24 +0100, Felix Miata wrote:

I started to report a bug, but BOO found a "NEW" opened Nov 2016, in which I have now pointed to this thread: https://bugzilla.opensuse.org/show_bug.cgi?id=1012883

thanks for digging it out! When I wrote earlier the problem appears to be sorted out for me, I decided to re-add plymouth once again to my systems; this is when the trouble started to happen again. I'll now remove plymouth again everywhere, leave the NFS related _fix_ installed and stick with that setup. From your comment in the BOO above, your setup really looks very close to the one I have here. Did you try out, if adding the nfs4leasetime and nfs4gracetime change help with the delays? Cheers. l8er manfred