LinuxQuestions.org
Share your knowledge at the LQ Wiki.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices


Reply
  Search this Thread
Old 11-27-2014, 08:31 PM   #1
ReaperX7
LQ Guru
 
Registered: Jul 2011
Location: California
Distribution: Slackware64-Current
Posts: 6,450
Blog Entries: 15

Rep: Reputation: 2030Reputation: 2030Reputation: 2030Reputation: 2030Reputation: 2030Reputation: 2030Reputation: 2030Reputation: 2030Reputation: 2030Reputation: 2030Reputation: 2030
[BUG] Slackware64-Current shutdown dismount issue.


After updating my box today to run -Current, I started getting a weird shutdown bug where it says /(root) is still busy at shutdown and failed to dismount, like a daemon/service was still running and didn't shutdown with the kill signal sent by init.

Has anyone else gotten this bug recently?

Luckily I had /(root) partitioned with JFS which kept my data intact.
 
Old 11-27-2014, 09:10 PM   #2
hitest
Guru
 
Registered: Mar 2004
Location: Prince Rupert, B.C., Canada
Distribution: Slackware, OpenBSD
Posts: 6,294

Rep: Reputation: 2544Reputation: 2544Reputation: 2544Reputation: 2544Reputation: 2544Reputation: 2544Reputation: 2544Reputation: 2544Reputation: 2544Reputation: 2544Reputation: 2544
Weird indeed! I'm running Slackware64-current on two of my four Slackware units and they shutdown properly.
 
Old 11-28-2014, 04:02 AM   #3
ReaperX7
LQ Guru
 
Registered: Jul 2011
Location: California
Distribution: Slackware64-Current
Posts: 6,450

Original Poster
Blog Entries: 15

Rep: Reputation: 2030Reputation: 2030Reputation: 2030Reputation: 2030Reputation: 2030Reputation: 2030Reputation: 2030Reputation: 2030Reputation: 2030Reputation: 2030Reputation: 2030
I think I have it narrowed down to either ConsoleKit or D-Bus not closing down properly. I'm going to check the command to kill the services upon the shut down signal and see if there might be something I can retune.
 
Old 11-28-2014, 07:50 AM   #4
fogpipe
Member
 
Registered: Mar 2011
Distribution: Slackware 64 -current,
Posts: 550

Rep: Reputation: 194Reputation: 194
Im running current with xfs and it shuts down without complaint. I was going to post that it was a pretty much vanilla current 64 bit, but i remebered that a while back i did kill console kit.
There were no consequences except that i got back the gig of ram it was using and kdm complains that it isnt running if im using it to start kde.
 
Old 11-28-2014, 08:11 AM   #5
hitest
Guru
 
Registered: Mar 2004
Location: Prince Rupert, B.C., Canada
Distribution: Slackware, OpenBSD
Posts: 6,294

Rep: Reputation: 2544Reputation: 2544Reputation: 2544Reputation: 2544Reputation: 2544Reputation: 2544Reputation: 2544Reputation: 2544Reputation: 2544Reputation: 2544Reputation: 2544
My 2 boxes are running vanilla current 64 bit with the EXT4 file system and XFCE.
 
Old 11-28-2014, 09:30 AM   #6
genss
Member
 
Registered: Nov 2013
Posts: 740

Rep: Reputation: Disabled
if you think it is because of some file not being closed you can find out by putting
lsof > /some/file in rc.6 line ~212 (before umount)
 
Old 11-28-2014, 09:51 AM   #7
GazL
LQ Guru
 
Registered: May 2008
Distribution: CRUX
Posts: 5,507
Blog Entries: 14

Rep: Reputation: 3343Reputation: 3343Reputation: 3343Reputation: 3343Reputation: 3343Reputation: 3343Reputation: 3343Reputation: 3343Reputation: 3343Reputation: 3343Reputation: 3343
When you try and umount / it will not unmount, but instead go 'ro'. There's also an explicit 'mount -o remount,ro /' just after the 'umount -a' in rc.6 so there was never any danger to your filesystem integrity, and the fact you're using a journalled filesystem has no bearing.

Being unable to unmount the rootfs is expected behavour (what do you think init and rc.6 are using? ), it just seems that our umount command is lying to us when it says it has unmounted /, where as yours is telling the truth. No idea why there would be a difference in behaviour, though I vaguely remember seeing 'failed to unmount /' back on 13.37 when I was running rootfs on lvm on luks,
 
Old 11-28-2014, 10:06 AM   #8
Didier Spaier
LQ Addict
 
Registered: Nov 2008
Location: Paris, France
Distribution: Slint64-14.2.1.2 on Lenovo Thinkpad W520
Posts: 9,428

Rep: Reputation: Disabled
Probably irrelevant guess, however...

IIRC you use eudev. Do you observe the same behavior using udev 182?

BTW I could have asked the same question about your issue with btrfs on root.
 
Old 11-28-2014, 05:26 PM   #9
ReaperX7
LQ Guru
 
Registered: Jul 2011
Location: California
Distribution: Slackware64-Current
Posts: 6,450

Original Poster
Blog Entries: 15

Rep: Reputation: 2030Reputation: 2030Reputation: 2030Reputation: 2030Reputation: 2030Reputation: 2030Reputation: 2030Reputation: 2030Reputation: 2030Reputation: 2030Reputation: 2030
I actually am still using the udev-182 package. I haven't touched upgrading to your eudev package yet Didier. I have been meaning to though.

I also just realized in rc.6 there is no shutdown for ConsoleKit. I'll try the lsof first and do a shutdown and see what happens. If it happsn that a service shutdown isn't taking place, the good thing is I can always add a shutdown command sequence in and try to have it close it rather than wait for killall5 to try and possibly fail.

Last edited by ReaperX7; 11-28-2014 at 05:36 PM.
 
Old 11-28-2014, 06:08 PM   #10
hotchili
Member
 
Registered: Sep 2009
Location: Germany
Distribution: slackware64-current
Posts: 89

Rep: Reputation: 31
No such problem here on my current install, my root partition fs is ext4.
 
Old 11-28-2014, 06:11 PM   #11
ReaperX7
LQ Guru
 
Registered: Jul 2011
Location: California
Distribution: Slackware64-Current
Posts: 6,450

Original Poster
Blog Entries: 15

Rep: Reputation: 2030Reputation: 2030Reputation: 2030Reputation: 2030Reputation: 2030Reputation: 2030Reputation: 2030Reputation: 2030Reputation: 2030Reputation: 2030Reputation: 2030
Okay, at this point, I'm not sure what it could be.

fuser says nothing and lsof is more or less uninformative.

I was wondering if perhaps maybe it's a process not closing down completely with killall5. Would using pkill in this way:

Code:
# Stop any remaining processes and core services.
echo "Sending TERM signal to processes..."
pkill --inverse -s0,1 -TERM
sleep 5
echo "Sending KILL signal to processes..."
pkill --inverse -s0,1 -KILL
As either a supplement or replacement for this from rc.6 lines 173~180:

Code:
# Kill all remaining processes.
if [ ! "$1" = "fast" ]; then
  echo "Sending all processes the SIGTERM signal."
  /sbin/killall5 -15 
  /bin/sleep 5
  echo "Sending all processes the SIGKILL signal."
  /sbin/killall5 -9
fi
I'm also curious about line 214:

Code:
/bin/umount -v -a -t no,proc,sysfs
Shouldn't the virtual file system unmount target the following?

nosysfs,noproc,nodevtmpfs,notmpfs

not just

no,proc,sysfs

with flags

-v -r -a -t

not just

-v -a -t

Maybe it's something not being cleanly dismounted like a virtual file system? Other than this, I have no idea...

Last edited by ReaperX7; 11-28-2014 at 08:47 PM.
 
Old 11-28-2014, 09:57 PM   #12
mlslk31
Member
 
Registered: Mar 2013
Location: Florida, USA
Distribution: Slackware, FreeBSD
Posts: 210

Rep: Reputation: 76
Quote:
Originally Posted by ReaperX7 View Post
After updating my box today to run -Current, I started getting a weird shutdown bug where it says /(root) is still busy at shutdown and failed to dismount, like a daemon/service was still running and didn't shutdown with the kill signal sent by init.

Has anyone else gotten this bug recently?
I've had it on all of my x86 boxes at one time or another. I toss some extra sync and sleep statements into /etc/rc.d/rc.6, especially before before the remount,ro of /. There's something about that previous umount command that can take some time. If you can get that partition fully unmounted for checking, run a `jfs_fsck -fnv` on that partition. If both return codes are 0, you don't need to run a regular fsck; otherwise, you do need to run a fsck or a `jfs_fsck -fv`.

jfs_fsck has no problem chucking /etc into /lost+found under the right circumstances, due to it feeling that the /etc directory has been corrupted. If you fear this scenario, back up /etc before running fsck. JFS can read /etc just fine, but jfs_fsck may have a different opinion of it.

Things are a little better if /etc/mtab is a symlink to /proc/mounts, but that takes some tweaking of /etc/rc.d/rc.S and learning to read the output of `mount` again. The symlink does take away that last write to /etc before flushing to disk.

Quote:
Luckily I had /(root) partitioned with JFS which kept my data intact.
Your drives are probably better than mine as well. To get that outstanding JFS reliability, I usually have to shut the write cache off for older drives. Before then, it wasn't so pretty for any file system, seemingly for 2.6 and later kernels, so maybe it's not all the fault of the hardware.
 
Old 11-28-2014, 10:23 PM   #13
ReaperX7
LQ Guru
 
Registered: Jul 2011
Location: California
Distribution: Slackware64-Current
Posts: 6,450

Original Poster
Blog Entries: 15

Rep: Reputation: 2030Reputation: 2030Reputation: 2030Reputation: 2030Reputation: 2030Reputation: 2030Reputation: 2030Reputation: 2030Reputation: 2030Reputation: 2030Reputation: 2030
Probably adding sleep 5?

Oddly when we ran into this same issue on LFS when we transitioned to runit, it partially at first dealt with swap being dismounted before the drive was set into read-only. However, at the time, we were still using killall5 from sysvinit and an assortment of bootscripts before we transitioned to what ArchIgnite was using and started using our own revamped toolpack geared for runit only and switched the kill signal tool in the shutdown script to pkill which shut things down more thoroughly.

https://runit-for-lfs.googlecode.com...rvicescripts/3
 
Old 11-28-2014, 11:25 PM   #14
mlslk31
Member
 
Registered: Mar 2013
Location: Florida, USA
Distribution: Slackware, FreeBSD
Posts: 210

Rep: Reputation: 76
Here at work, there's a sync after swapoff. As a mix into the default Slackware shutdown script, it goes like this soon after that (XFS, write caches on):

Code:
mount -o remount,ro /
sync
# Here is the standard Slackware shutdown of LVM and LUKS, then...
sync
/sbin/hdparm -F /dev/sdb
/sbin/hdparm -F /dev/sda
sleep 3
wait
At home, the safest thing is to shut the drive cache off on boot and never use `hdparm -F`, so it's more like this (JFS, write caches off):

Code:
# Unmounting local file systems step goes here, then...
sync     # this does the brunt of the work and helps JFS catch up.
sleep 2  # one second is sometimes too little.
mount -o remount,ro /
sync
sleep 2
 
Old 11-29-2014, 04:21 PM   #15
ReaperX7
LQ Guru
 
Registered: Jul 2011
Location: California
Distribution: Slackware64-Current
Posts: 6,450

Original Poster
Blog Entries: 15

Rep: Reputation: 2030Reputation: 2030Reputation: 2030Reputation: 2030Reputation: 2030Reputation: 2030Reputation: 2030Reputation: 2030Reputation: 2030Reputation: 2030Reputation: 2030
I added an extra sleep 3 and sync command for the swap dismount and virtual file ssytem dismounts and hopefully it will fix the issue. If not, I might try switching from using killall5 to pkill.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
Maybe a bug in dhcpcd-6.0.5-x86_64-2 on Slackware64-current jhw Slackware 1 10-02-2013 06:08 AM
Slackware64-current GPG Bug t35t Slackware 6 08-30-2012 05:56 AM
[SOLVED] Slackware64-Current Bug in lxc 0.7.5 Jack128 Slackware 7 08-25-2012 12:53 PM
Memory Issue with XFCE Terminal 0.4.6 on Slackware64-current lanir Slackware 2 07-07-2012 06:03 PM
slackware64-current glibc resolver bug? fancylad Slackware 8 01-31-2010 04:47 PM

LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware

All times are GMT -5. The time now is 01:38 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration