SlackwareThis Forum is for the discussion of Slackware Linux.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
Originally posted by dhave You could wait until an upgrade of the kid is available. I did this, and the current version of my son (he's at v. 17.4 now) is no longer goofing things up on my computer. In fact, he helps fix it. When my kid was at v. 2.x and even v. 3.x, however, I had a lot of problems of the type you describe.
I should warn you, however, that there are other bugs that have been introduced with the more recent versions. Still, I'm generally happy with this app.
#last says it's rebooting every morning at 04:40 every day for the past 8 days.
I figured if it's happening at the exact same time every day, maybe it IS a cron job. Well I noticed that whenever I ran slocate it said the database hasn't been updated in 8 days (!) So I ran the "slocate" script in /etc/cron.daily, which runs updatedb. I did this a few times. Each time, it would either reboot or lock up. I tried running updatedb myself instead of using the script in cron.daily and it still rebooted or froze. I guess we found the culprit.
Is there a way to get updatedb working again, or am I going to have to disable that cron job? If the latter, how do I disable it?
To the last 2 replies... are you saying that even though it happens at the exact same time every morning, and it appears to be the updatedb command causing the reboot, that you still believe it to be a hardware issue?
Originally posted by yuchai Given that it seems to be an updatedb issue. I would think it's 1 of 2 things:
1. There are corruptions in the filesystems that updatedb is performing on.
2. It's a harddrive issue so when certain spots of the harddrive (bad sectors?) are accessed the system becomes unstable.
Not a linux expert so can't comment further. Good luck.
We've posted at the same time -- yes I'd come to the same conclusion. Why not run a disk check or updatedb manually? In etiher case all corners of the hdd will be accessed and we'll see if there's a hardware problem.
I'm confused by the comment about me trying to keep it running all day... isn't keeping it running all day a good thing? It runs servers... :\
I just wanted to be sure I understood the situation correctly. My idea is that throughout the day the hardware inside the box build up a great amount of heat., and heat has a dramatic effect on overall system performance. If you have a small box or the inside of the box loaded with disk drives and cables and high performance cards then it's going to create a LOT of heat. After a while this can cause performance loss and even system "hiccups". That's why I asked about current ventilation and cooling.
Updatedb (the slocate script in /etc/cron.daily) runs at 4:40AM every day by default. You've found the problem.
Running updatedb or slocate -u uses lots of resources. It's very IO intensive on the hard drive and also uses lots of CPU cycles.
The fact that the machine reboots or freezes every time this command means that the machine will probably reboot or freeze under any other similar command that puts a good amount of stress on the system. A great stress test for this sort of thing is recompiling the kernel.
First things to check: make sure the CPU fan isn't blocked by a misplaced cable or large amounts of dust accumulation.
Also check the BIOS to see if you can get CPU / Motherboard temperature readings.
Try switching out the power supply, if you have another available. When you get large current draws from high system loads, the power may fluctuate from the PS which may in turn reboot the machine.
It seems to me that either heat on the CPU or a bad power supply are at fault here.
Originally posted by Seiken See, I work nights so his mother gets up with him in the morning... but when she gets up, she's been falling asleep on the couch! So he gets to run around and do whatever he wants until she or I get up.
First of all, A 2 year old should NEVER EVER be left to run around and do whatever they want!!!!!!!!!!!!!!!!!
One of these days you or your wife will wake up and find your 2 year old has wandered outside and got hit by a car!!!!!! NEVER leave a two year old alone and unwatched!!!
Thanks Dr. Phil, but I was quite aware of that already. I see you've never made mistakes before, and therefore don't understand. That aside, he's not capable of undoing all of the locks to get outside. And even if he was capable of that, he still can't undo the deadbolt for the outside door, which requires a key.
Anyway, this is hardly relevent to LinuxQuestions.org. If you'd like to talk to me about parenting, you can email me at email@example.com.
Could it be possible that we're overengineering the problem here?
Have you tried reinstalling the updatedb package and checking your filesystem? It might be a corrupt binary for whatever reason ... thinking about it, you might want to consider a reinstall of glibc, too, just in case that bit got corrupted somewhere along the line.
I'm sort of clutching at straws here, but reinstallation is cheaper than buying new hardware to replace possibibly faulty hardware. Like yuchai and Ilgar I highly recommend doing a manual disk check. Do you have a custom kernel? Perhaps there's some kernel level problem with disk access. I would rule out software problems before I started chasing hardware gremlins, personally.