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.

Weird indeed! I'm running Slackware64-current on two of my four Slackware units and they shutdown properly.

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.

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.

My 2 boxes are running vanilla current 64 bit with the EXT4 file system and XFCE.

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)

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,

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.

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.

No such problem here on my current install, my root partition fs is ext4.

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:

As either a supplement or replacement for this from rc.6 lines 173~180:

I'm also curious about line 214:

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

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.

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.

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

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

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

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.