My Funny Daemons
This is a log of what I’ve done to try and narrow down the source of my XFS daemons in DSL 4.0 release installed to hard drive (not frugal).
B A C K G R O U N D
I did the install around the middle of November (15th, 16th). That computer has not been down except to reset the hostname.
With the exception of extensions from testing, these were mostly off a CD on which I store old settings and favorite and development extensions. I also added a few from testing and a few more that I hadn’t seen and figured I would check out. UCIs were loaded, copied, unloaded, copied back
PS AUX | GREP XFS
root 4914 0.0 0.0 0 0 ? SW Nov16 0:39 [xfsbufd]
root 4915 0.0 0.0 0 0 ? SW Nov16 0:00 [xfslogd/0]
root 4916 0.0 0.0 0 0 ? SW Nov16 0:00 [xfsdatad/0]
dsl 26998 1.0 0.3 1504 444 pts/0 S 02:15 0:00 grep xfs
E X T E N S I O N S
These are the MyDSL extensions I installed — not damn small at all but just to load up the partition as quickly as possible (this list is complete to the best of my knowledge):
* – later deleted
In addition, I’ve installed from source the following:
em-4.0.15-lt.tar.bz2 (microemacs; later deleted)
htop-0.6.6.tar.gz (interactive top monitor)
mc-4.6.1.tar.gz (compiled without any kind of fs support)
slock-0.7.tar.gz (screen lock)
sithwm-1.2.2.tgz (since removed)
T E S T I N G
I installed DSL 4.1 (frugal) and have tried to recreate the same result by adding in ntfsprogs.dsl and the sshfs/fuse extension. So far to no avail.
Sunday, 12:45pm local – I’m presently running the 4.1 CD live and unable to find out where the xfs daemons came from in my hard drive install. It’s not sshfs.dsl. It’s not reiserfsprogs. I think it’s not ntfsprogs.dsl.
Sunday 1:45 pm local – I’m going to try later with DSL 4.0 CD and see if it’s related to that. IIRC, I didn’t see anything like that when running live before doing the HD install. But I also didn’t load and run any extensions.
Sunday, 4:30 pm local – I found my 4.0-release CD and worked back and forth between it and the hard drive install. Here’s a look at DSL’s filesystem modules and their sizes.
dsl@t-Rex:/KNOPPIX/lib/modules/2.4.31/kernel/fs$ du -h
I knew the modules are definitely there. That’s because lsmod showed xfs and hfs/hfsplus loaded. I rmmod’ed them. The only question I have is, Why did they load? Is it something to do with the HD install script? I checked it and saw nothing. I looked through init files grep’ing for xfs and didn’t see anything. I scrounged through some sbin directories to see if there was anything that depends on xfs, then checked the configuration files in my home folder to see if there’s anything that starts those daemons.
Anyway, some of those modules can probably be removed — maybe a MB or more. Make extensions if anyone needs those. BFS/BeFS? It doesn’t need to be included. Dittos for the HFS stuff. Move those to extensions if they’re needed. I would consider doing the same with the ReiserFS module and bundle it with the progs extension.
Second half of the Steelers-Pats is on. Will mess with it later.
Monday 1:30pm local
I played around more last night and at lunch, still no idea why they loaded. I’ll reboot later and see if the XFS daemons start again.
Tuesday 8:15am local
Not much progress on the XFS daemons front, but I found this late last night in sshfs.dsl.
That explains why I’ve had so many module error messages in my console and where the 2.4.26 kernel modules came from on my hard drive install. I know that’s not the source of the XFS issue, but it’s something that should be noted on the extension’s info page since DSL 4+ uses 2.4.31.
Wednesday (12 Dec 2007) 11:30 am local
Since I’d used DSL 2.1b and not upgraded to 3.0+ for so long, I wasn’t aware that fuse and sshfs had been added into DSL. Whoops.
Still no idea what the deal is with XFS daemons starting, but someone else mentioned XFS in another thread. Who knows.
The good news is Robert is open to removing some of the fs modules (and probably more). I don’t see the value of leaving in fs modules if there’s no progs support at all for them, and those modules can be combined into the progs extensions. That should free up a little room. I know there may be some flack from those who use DSL in conjunction with other distros and in which they use ReiserFS. We can’t all get exactly what we want. Some of my hardware requires modules I have to get from extensions. Doesn’t hurt.
I’m letting that take a back seat, but keeping an eye out to see if running some application starts the daemons again. That shouldn’t be a problem if I upgrade since the fs won’t even be there to start with.
M Y S T E R Y S O L V E D
Wednesday (12 Dec 2007) – 11:20 pm local
I think I’ve got it!
I was doing some stuff on my computer tonight and noticed the XFS daemons in my top again. So I started tracing my steps back according to the time shown in ps aux.
That time corresponded to when I re-compiled sithwm. So I started playing around and realized it had nothing to do with any application or DSL extension. I got to looking around in dmesg and found a usb-storage module error at the same time (18:46).
Dec 12 18:46:42 rhapsody user.notice usb.agent: missing kernel or user mode driver usb-storage
I think it has to do with the hotplug script. And it’s not just xfs. There are more (see below).
I’ve written to the forums and on my blog about some quirky behavior I’ve noticed with how mount points (for example) sda1 and sdb1 get set to sda and/or sbd depending on insertion, removal, and re-insertion (proper mounting and umounting). I mentioned it in “Issues” on this page.
It’s been such a problem for me that I’ve set up aliases ckfstab (cat’ing fstab) and vifstab (sudo vim /etc/fstab) so I can check and fix it when needed without deleting points and clearing out fstab entries.
Tonight, I didn’t check before inserting the stick that’s set for /dev/sda. I got a message that there was no mount point in mtab/fstab, etc. So I knew I had to repair the mount point (from sda to sda1) and then mount the device.
I also rmmod’ed xfs because there’s no need to run daemons for a filesystem I don’t have, and for which I don’t have progs. Then after I did that I thought I’d better lsmod to see what else is going on. Here’s what I got:
Module Size Used by Not tainted
hfs 77248 0 (autoclean)
reiserfs 169584 0 (autoclean)
ntfs 50944 0 (autoclean)
sg 25884 0 (autoclean)
minix 19816 0 (autoclean)
ext3 64388 0 (autoclean)
jbd 46804 0 (autoclean) [ext3]
msdos 4684 0 (autoclean)
nls_iso8859-1 2844 18 (autoclean)
nls_cp437 4348 0 (autoclean)
usb-storage 62208 0
cloop 39364 0
i810_audio 25176 0
ac97_codec 12108 0 [i810_audio]
soundcore 3428 2 [i810_audio]
i810_rng 2660 0 (unused)
serial 52196 0 (autoclean)
mousedev 3832 1
keybdev 1792 0 (unused)
hid 22788 0 (unused)
input 3168 0 [mousedev keybdev hid]
ieee1394 183300 0
usb-uhci 21708 0 (unused)
usbcore 58240 1 [usb-storage hid usb-uhci]
apm 9736 1
ide-cd 28768 0
ide-scsi 9264 0
rtc 7004 0 (autoclean)
I hadn’t loaded reiserfs, ntfs, or hfs. Those shouldn’t be loaded because I don’t have those anywhere on my system or in devices I insert (like USB sticks).
I rmmod’ed those again. I ran my alias to check fstab and — as happens over time with inserting and re-inserting USB media in random order — saw the mount point for sdb1 had been set to sdb:
/dev/sdb /mnt/sdb auto noauto,users,exec 0 0
I stuck that (sdb) stick in to a port and tried to mount sbd1 (knowing that it wasn’t a valid mount point anymore). I checked ps aux and there it is:
root 32231 0.0 0.0 0 0 ? SW 22:25 0:00 [xfsbufd]
root 32232 0.0 0.0 0 0 ? SW 22:25 0:00 [xfslogd/0]
root 32233 0.0 0.0 0 0 ? SW 22:25 0:00 [xfsdatad/0]
And in dmesg, the same error as above except 22:25. I also had all those fs modules — hfs, reiserfs, ntfs, etc. — loaded again.
So it’s narrowed down to the hotplug script.
P O S T S C R I P T
Thursday (13 Dec 2007) – 7:45 am local
The bulk of the previous entry last night (“mystery solved” ) was sent to Robert, and he’ll address it. The modprobe xfs problem reported by JohnJS now makes a little more sense, since the module was removed. I don’t know if he has any xfs partitions to mount, but the script can be tweaked so it doesn’t load what’s not there.
I also realize why I couldn’t replicate the problem on my crash test box: it doesn’t have USB. I was working with apples and oranges. Without inserting, removing, and then re-inserting in different orders, my fstab wasn’t being continually rewritten by KNOPPIX. So it wasn’t shotgunning module loads like it does on the affected computer.
That script is clearly intended for short-term live CD use. Perhaps it works well enough for that use. But there’s no need to re-write fstab repeatedly. With my uptime now near a month, I’ve lost track of how many times I’ve had to edit fstab to correct mount points for my USB media — usually more than four or five times a day, depending how many times I mount and umount and in which order. The script apparently doesn’t like it if you go A-B-C-D (which is more likely how it’s used in a live CD environment) and then out of order like B-B-C-A-B-C-A-D — that’s when it rewrites fstab, but that’s what happens when you run a system long enough (rebooting doesn’t help because fstab is persistent on hard drive installs).
If there’s a silver lining to all this, perhaps it’s in additional space and speed as Robert moves some modules out of the base. It doesn’t fit in with DSL’s no-bloat philosophy to include modules that can’t be used because the tools to use them aren’t even in the repository. Some of those filesystem modules for which there are available progs in MyDSL can be added to those extensions. That shouldn’t be too inconvenient for those who actually want to load and use them since the progs are already and extension.