Huge Log files

[WizardOz]

I had the same problem and did a revert and reinstalled the OxNas.
Clean install... and added a swapfile...
udevd eats all CPU but the logs are not increasing.

top - 03:43:20 up 8 min, 1 user, load average: 1.06, 1.15, 0.64
Tasks: 69 total, 2 running, 67 sleeping, 0 stopped, 0 zombie
Cpu(s): 29.2%us, 21.1%sy, 0.0%ni, 49.7%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 125816k total, 123548k used, 2268k free, 748k buffers
Swap: 131064k total, 0k used, 131064k free, 81408k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
379 root 20 0 2128 900 648 R 100 0.7 8:10.83 udevd
1072 root 20 0 2260 1040 852 R 1 0.8 0:00.23 top

[Socaltom]

In an effort to track the cause, I reformated the boot partition, extracted the fs and copied over the mac_addr and cloudengines stuff.

The first boot udev is taking 100% of cpu as reported by top

could this mean anything?
$this->bbcode_second_pass_code('', '
Dec 31 18:01:11 alarm /usr/sbin/crond[938]: (CRON) STARTUP (1.4.7)
Dec 31 18:01:11 alarm /usr/sbin/crond[938]: (CRON) INFO (Syslog will be used instead of sendmail.): No such file or directory
Dec 31 18:01:11 alarm /usr/sbin/crond[938]: (CRON) INFO (running with inotify support)
')

[Socaltom]

I turned on the udev debug level logging. Does this help?
$this->bbcode_second_pass_code('', ':48 alarm udevd[353]: worker [582] exit
Jun 4 21:11:48 alarm udevd[353]: worker [582] cleaned up
Jun 4 21:11:48 alarm udevd[353]: worker [583] exit
Jun 4 21:11:48 alarm udevd[353]: worker [583] cleaned up
Jun 4 21:11:48 alarm udevd[353]: worker [584] exit
Jun 4 21:11:48 alarm udevd[353]: worker [584] cleaned up
Jun 4 21:11:48 alarm udevd[353]: worker [585] exit
Jun 4 21:11:48 alarm udevd[353]: worker [585] cleaned up
Jun 4 21:11:48 alarm udevd[353]: worker [586] exit
Jun 4 21:11:48 alarm udevd[353]: worker [586] cleaned up
Jun 4 21:11:48 alarm udevd[353]: worker [587] exit
Jun 4 21:11:48 alarm udevd[353]: worker [587] cleaned up
Jun 4 21:11:48 alarm udevd[353]: worker [589] exit
Jun 4 21:11:48 alarm udevd[353]: worker [589] cleaned up
Jun 4 21:11:48 alarm udevd[353]: worker [590] exit
Jun 4 21:11:48 alarm udevd[353]: worker [590] cleaned up
Jun 4 21:11:48 alarm udevd[353]: worker [591] exit
Jun 4 21:11:48 alarm udevd[353]: worker [591] cleaned up
Jun 4 21:11:48 alarm udevd[353]: worker [592] exit
Jun 4 21:11:48 alarm udevd[353]: worker [592] cleaned up
Jun 4 21:11:48 alarm udevd[353]: worker [582] cleaned up
Jun 4 21:11:48 alarm udevd[353]: worker [583] exit
Jun 4 21:11:48 alarm udevd[353]: worker [583] cleaned up
Jun 4 21:11:48 alarm udevd[353]: worker [584] exit
Jun 4 21:11:48 alarm udevd[353]: worker [584] cleaned up
Jun 4 21:11:48 alarm udevd[353]: worker [585] exit
Jun 4 21:11:48 alarm udevd[353]: worker [585] cleaned up
Jun 4 21:11:48 alarm udevd[353]: worker [586] exit
Jun 4 21:11:48 alarm udevd[353]: worker [586] cleaned up
Jun 4 21:11:48 alarm udevd[353]: worker [587] exit
Jun 4 21:11:48 alarm udevd[353]: worker [587] cleaned up
Jun 4 21:11:48 alarm udevd[353]: worker [589] exit
Jun 4 21:11:48 alarm udevd[353]: worker [589] cleaned up
Jun 4 21:11:48 alarm udevd[353]: worker [590] exit
Jun 4 21:11:48 alarm udevd[353]: worker [590] cleaned up
Jun 4 21:11:48 alarm udevd[353]: worker [591] exit
Jun 4 21:11:48 alarm udevd[353]: worker [591] cleaned up
Jun 4 21:11:48 alarm udevd[353]: worker [592] exit
Jun 4 21:11:48 alarm udevd[353]: worker [592] cleaned up
Jun 4 21:11:48 alarm udevd[353]: worker [594] exit
Jun 4 21:11:48 alarm udevd[353]: worker [594] cleaned up
') I don't know what it means.
Tom

[WarheadsSE]

It means that there is a child process that it is trying to fire up, but is taking a crap on that eror every time and then instantly dies & is restarted.

[Cybertimber2009]

Warhead: I wonder... this is only happening on the OXNAS boards right? I wonder if something was left behind, likely in udevd, that is trying to check PCI slots.

Edit: I had another thought... maybe udevd is starting too early? Before something else that it needs? This seems possible since killing it and restarting it seems to quiet it.
====================

PS, to everyone else:
$this->bbcode_second_pass_code('', 'killall udevd')
Will stop the logging & process hog... however it also kills automounting of any devices you plug in. I used udevadm monitor to watch it and it does restart (as its supposed to) and it shows that a device should be added, but it doesn't mount it. However, running
$this->bbcode_second_pass_code('', 'udevd &') will put it back in the background (properly), and it will auto connect newly plugged in devices. The difference is, it doesn't take up processor time or fill up /var/log.

I might recommend (at your risk) torun
$this->bbcode_second_pass_code('', 'rm -rf /var/log/*')
periodically or else your drive space will disappear.

[slycat]

Hold up, is udevd ONLY for automounting? Can I rip the whiney S.O.B. out of the boot-up and still launch Arch Linux ARM? And just have fstab mount drives?

To me automounting when devices are plugged in is useless. I've actually commented out my entire rules.d files.

[Cybertimber2009]

$this->bbcode_second_pass_quote('slycat', 'H')old up, is udevd ONLY for automounting? Can I rip the whiney S.O.B. out of the boot-up and still launch Arch Linux ARM? And just have fstab mount drives?

To me automounting when devices are plugged in is useless. I've actually commented out my entire rules.d files.

[devr]

Cybertimber2009,

There are a couple threads about this issue. You are right that if after killing udevd, you start it again, logging stays fine. It isn't until you run a particular udev command (issued in the rc startup) where things go awry. Reference my post in the other thread for more info.

[WarheadsSE]

Also,

It's not just the OXNAS boards, it's now appearing on *all* plugs.

[pepedog]

I don't have troubles, 3 dockstars with the older u-Boot, and trimslice, all with hard drives (ext2).
$this->bbcode_second_pass_code('', '[root@PBLinux ~]# df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/root 307663800 12243256 279792112 5% /
tmpfs 10240 136 10104 2% /run
udev 10240 4 10236 1% /dev
shm 61536 0 61536 0% /dev/shm
[root@PBLinux ~]# mount
/dev/root on / type ext2 (rw,relatime,errors=continue)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
tmpfs on /run type tmpfs (rw,nosuid,nodev,noexec,relatime,size=10240k,mode=755)
udev on /dev type tmpfs (rw,nosuid,relatime,size=10240k,mode=755)
devpts on /dev/pts type devpts (rw,relatime,mode=600)
shm on /dev/shm type tmpfs (rw,nosuid,nodev,relatime)
fusectl on /sys/fs/fuse/connections type fusectl (rw,relatime)')
Notice archlinux now has 171-2