[SOLVED] Current hangs in shutdown on fuser command

vulcan59 · 07-07-2021, 08:51 AM

I have found a problem in rc.0/rc.6 on -current.

On 14.2 there is a command /usr/bin/fuser -k -m $dir & which works fine

On -current the command has changed to /usr/bin/fuser -k -M -m $dir & so -M has been added.

On my machine shutdown now hangs at the fuser command. If I run the command with -M and background it, it never returns without me pressing return to get back to the command prompt. Backgrounding the command without -M works fine.

Is anyone else seeing this?

lovemeslk · 07-07-2021, 11:10 AM

Vulcan59 you do realize right Slackware current uses Elogind
and that is still being changed and rebuilt as we speak. And always will.
Why because it is tied to systemd as it changes.

Before people go off on this ask your self why we had to go to Elongind.
Many programs need that for loging. So Elogind takes the calls
that are needed by some programs that are built to use systemd.
we know it will be just like Pulseaudio take about 20 years to get it right.

It is a moving target.

bassmadrigal · 07-07-2021, 12:04 PM

Quote:

Originally Posted by lovemeslk

Vulcan59 you do realize right Slackware current uses Elogind
and that is still being changed and rebuilt as we speak. And always will.
Why because it is tied to systemd as it changes.

Before people go off on this ask your self why we had to go to Elongind.
Many programs need that for loging. So Elogind takes the calls
that are needed by some programs that are built to use systemd.
we know it will be just like Pulseaudio take about 20 years to get it right.

It is a moving target.

What does this have to do with OP's hang during a shutdown? It shouldn't matter whether Slackware was using ConsoleKit2 or elogind, a hang during a shutdown is an issue.

@OP, I haven't had any issues with my system, but my NFS shares are being mounted within kodi and not separately in the filesystem. Have you tried adding a -v for verbose mode to see if it dumps anything beneficial to the CLI? What happens if you run the command without backgrounding and including your nfs mount points?

vulcan59 · 07-08-2021, 06:58 AM

After a bit more investigation, I have found that rc.0 is not hanging on the fuser command as I originally thought. It actually hangs at the wait command further down.

# This is to ensure all processes have completed on SMP machines
wait

I am not on an SMP machine.
The hang only happens if I have an NFS mount at the time of the shutdown. It doesn't matter if is in use or not.

If I remove that wait my machine shuts down successfully with the NFS filesystem mounted.

At the moment I have no idea why this happens. Any ideas?

timsoft · 07-08-2021, 09:43 AM

have you tried since the kernel in current got updated to 5.12.15 yesterday. that should have fixed an kernel related nfs issue mentioned elsewhere, which might be related.

bassmadrigal · 07-08-2021, 10:59 AM

Try adding the below to rc.0 right above the wait command. That should show you any backgrounded jobs that have not closed yet, which will let us find out for sure what the command is causing the hang (although, based on your previous message, I imagine it is the fuser command since it hangs if you run it manually).

Code:

for i in $(jobs -p); do
  ps -hq $i -o command,user
done

vulcan59 · 07-08-2021, 12:38 PM

Quote:

Originally Posted by timsoft

have you tried since the kernel in current got updated to 5.12.15 yesterday. that should have fixed an kernel related nfs issue mentioned elsewhere, which might be related.

Just tried 5.12.15 and it made no difference.

vulcan59 · 07-08-2021, 12:46 PM

Quote:

Originally Posted by bassmadrigal

Try adding the below to rc.0 right above the wait command. That should show you any backgrounded jobs that have not closed yet, which will let us find out for sure what the command is causing the hang (although, based on your previous message, I imagine it is the fuser command since it hangs if you run it manually).

Code:

for i in $(jobs -p); do
  ps -hq $i -o command,user
done

I added your code and it output

/usr/bin/fuser -k -M -m -v root

As suspected it is the fuser command.

bassmadrigal · 07-08-2021, 01:26 PM

Do you have NFS shares mounted? The fuser command doesn't show any directories after -m, which should be mount points for any NFS shares.

If you don't have NFS shares, can you add the red line to the for loop and see if that helps shutdown? It should exit the loop if dir is blank before running the fuser command.

Code:

for dir in $(/bin/mount | grep -e 'type nfs ' -e 'type nfs4 ' | sed -e 's|.* on ||g' | cut -d ' ' -f 1) ; do
  [ -z "$dir" ] && break   
  echo "Killing processes holding NFS mount $dir open..."
  # Background this to prevent fuser from also blocking shutdown:
  /usr/bin/fuser -k -M -m "$dir" &
  FUSER_DELAY=5
done

If you do have NFS shares, can you provide the output of the following command?

Code:

mount | grep -e 'type nfs ' -e 'type nfs4 '

vulcan59 · 07-08-2021, 03:06 PM

Yes I do have one NFS mount. As I said earlier, the wait command doesn't hang unless there is an NFS mount.

mount | grep -e 'type nfs ' -e 'type nfs4 '

freenas:/mnt/pool1/slackware on /mnt/slackware type nfs (rw,vers=4,minorversion=1,addr=192.168.1.4,clientaddr=192.168.1.200)

bassmadrigal · 07-08-2021, 03:47 PM

I'm not sure if you tried this, since your post doesn't specifically state it, but what happens if you run the fuser command with "/mnt/slackware" after the -m, does it still hang?

Code:

fuser -k -M -m /mnt/slackware &

It seems the command being run by the for loop doesn't include /mnt/slackware in it, so I'm curious why that's happening...

lovemeslk · 07-08-2021, 04:03 PM

Quote:

Originally Posted by bassmadrigal

What does this have to do with OP's hang during a shutdown? It shouldn't matter whether Slackware was using ConsoleKit2 or elogind, a hang during a shutdown is an issue.

@OP, I haven't had any issues with my system, but my NFS shares are being mounted within kodi and not separately in the filesystem. Have you tried adding a -v for verbose mode to see if it dumps anything beneficial to the CLI? What happens if you run the command without backgrounding and including your nfs mount points?

Did I miss read it bass sorry
I belive we are using that as an init now for slackware current correct me if I miss read.
this seems to be an init issue

Quote:

op I have found a problem in rc.0/rc.6 on -current.

clean my glasses.
your so kind.

bassmadrigal · 07-08-2021, 06:15 PM

Quote:

Originally Posted by lovemeslk

Did I miss read it bass sorry
I belive we are using that as an init now for slackware current correct me if I miss read.
this seems to be an init issue

clean my glasses.
your so kind.

elogind has nothing to do with the startup and shutdown of Slackware. It is used to help manage user logins. Here's an excerpt of their github README:

Quote:

Elogind is the systemd project's "logind", extracted out to be a standalone daemon. It integrates with PAM to know the set of users that are logged in to a system and whether they are logged in graphically, on the console, or remotely. Elogind exposes this information via the standard org.freedesktop.login1 D-Bus interface, as well as through the file system using systemd's standard /run/systemd layout. Elogind also provides "libelogind", which is a subset of the facilities offered by "libsystemd". There is a "libelogind.pc" pkg-config file as well.

lovemeslk · 07-09-2021, 09:50 AM

Quote:

Originally Posted by bassmadrigal

elogind has nothing to do with the startup and shutdown of Slackware. It is used to help manage user logins. Here's an excerpt of their github README:

Thanks Bass I learn something new everyday. I got it mixed up.
like duh.

vulcan59 · 07-09-2021, 11:19 AM

Quote:

Originally Posted by bassmadrigal

I'm not sure if you tried this, since your post doesn't specifically state it, but what happens if you run the fuser command with "/mnt/slackware" after the -m, does it still hang?

Code:

fuser -k -M -m /mnt/slackware &

It seems the command being run by the for loop doesn't include /mnt/slackware in it, so I'm curious why that's happening...

I did as you suggest and it still hangs.

I still have your code just before the wait to show background processes not closed. This is the output.

/usr/bin/fuser -k -M -m /mn root

Very odd!