View Full Version : my computer is resetting each hour
hirohitosan
January 5th, 2009, 16:20
Hi there.
I have a strange problem. I found that my computer is resetting automatically every approximately 1 hour. I discover this accidentally. After each reset fsck_ufs is automatically started. I don't know if this is a software or hardware problem. I don’t know how to solve this.
Any help is appreciated :\
Sylhouette
January 5th, 2009, 16:30
First try to look in your log files.
Secondly try to disable any cronjob that is running, maybe a cronjob is responseable for this!
regards,
Johan Hendriks
graudeejs
January 5th, 2009, 17:13
also take a look at at.
hirohitosan
January 6th, 2009, 14:11
Thanks guys. At this moment I know that is not a harware problem. I started my computer with a live CD and it works more dthen 12 hours.
So I started again FreeBSD and after the system starts here is the output of:
# ps ax
PID TT STAT TIME COMMAND
881 ?? Is 0:00.00 /usr/sbin/cron -s
942 ?? DN 0:01.48 fsck_ufs -p -B /dev/ad8s1f
920 con- I+ 0:00.00 sh /etc/rc autoboot
921 con- I+ 0:00.00 logger -p daemon.notice -t fsck
922 con- IN+ 0:00.00 fsck -B -p
I don't know what logs to check and I think there is something with cron, but where to check
and if I try top command the first process is 942 root 1 -8 4 32812K 13560K biord 0 0:04 0.00% fsck_ufs
any help? thanks
graudeejs
January 6th, 2009, 14:20
show output of
crontab -l root
crontab -l username
replace user name with user name/names
hirohitosan
January 6th, 2009, 14:46
show output of
crontab -l root
crontab -l username
replace user name with user name/names
as root I did
# crontab -l
crontab: no crontab for root
or if I try like this:
#crontab -u root -l
crontab: no crontab for root
# crontab -u user -l
crontab: no crontab for user
or like this:# crontab -l root
crontab: usage error: no arguments permitted after this option
usage: crontab [-u user] file
crontab [-u user] { -e | -l | -r }
DutchDaemon
January 6th, 2009, 14:50
cat /etc/crontab
hirohitosan
January 6th, 2009, 14:51
here is /etc/crontab# cat crontab
# /etc/crontab - root's crontab for FreeBSD
#
# $FreeBSD: src/etc/crontab,v 1.32 2002/11/22 16:13:39 tom Exp $
#
SHELL=/bin/sh
PATH=/etc:/bin:/sbin:/usr/bin:/usr/sbin
HOME=/var/log
#
#minute hour mday month wday who command
#
*/5 * * * * root /usr/libexec/atrun
#
# Save some entropy so that /dev/random can re-seed on boot.
*/11 * * * * operator /usr/libexec/save-entropy
#
# Rotate log files every hour, if necessary.
0 * * * * root newsyslog
#
# Perform daily/weekly/monthly maintenance.
1 3 * * * root periodic daily
15 4 * * 6 root periodic weekly
30 5 1 * * root periodic monthly
#
# Adjust the time zone if the CMOS clock keeps local time, as opposed to
# UTC time. See adjkerntz(8) for details.
1,31 0-5 * * * root adjkerntz -a
DutchDaemon
January 6th, 2009, 14:56
Nothing interesting there.
Try this:
touch /var/log/all.log
Then in /etc/syslog.conf:
*.* /var/log/all.log
(it's probably already in there, just uncomment the line)
followed by
/etc/rc.d/syslogd restart
Then open /etc/newsyslog.conf and put in there:
/var/log/all.log 600 7 * @T00 J
(it may already be in there)
Then wait for the next reboot and look in /var/log/all.log
DutchDaemon
January 6th, 2009, 14:58
Is that reboot at the same exact time every hour, by the way?
lme@
January 6th, 2009, 16:18
Please show us the output of
last crash
and
last reboot
Djn
January 6th, 2009, 18:16
I had an issue like that when the background fsck died (and for some reason took the kernel down with it) on some weird filesystem error - it took roughly the same time to get to the problematic directory after each reboot, so I had the same "crash after x minutes"-feeling.
A manual fsck -y / in singleuser mode cleared it up.
hirohitosan
January 7th, 2009, 12:18
I did what DutchDaemon sugested and I reboot and from now it's works fine since 20 hours.
I don't actually know if I changed something. Anyway here's the outputs.
# last crash
wtmp begins Thu Jan 1 05:11:06 EET 2009
# last reboot
reboot ~ Tue Jan 6 14:05
reboot ~ Tue Jan 6 13:20
reboot ~ Tue Jan 6 12:58
reboot ~ Tue Jan 6 08:24
reboot ~ Tue Jan 6 07:24
reboot ~ Mon Jan 5 14:35
reboot ~ Mon Jan 5 13:26
reboot ~ Mon Jan 5 12:25
reboot ~ Mon Jan 5 10:59
reboot ~ Mon Jan 5 09:59
reboot ~ Mon Jan 5 08:58
reboot ~ Mon Jan 5 07:58
reboot ~ Mon Jan 5 06:57
reboot ~ Mon Jan 5 05:57
reboot ~ Mon Jan 5 04:56
reboot ~ Mon Jan 5 03:56
reboot ~ Mon Jan 5 02:55
reboot ~ Mon Jan 5 01:55
reboot ~ Mon Jan 5 00:54
reboot ~ Sun Jan 4 23:54
reboot ~ Sun Jan 4 22:53
reboot ~ Sun Jan 4 21:53
reboot ~ Sun Jan 4 20:53
reboot ~ Sun Jan 4 19:52
reboot ~ Sun Jan 4 18:52
reboot ~ Sun Jan 4 17:51
reboot ~ Sun Jan 4 16:51
reboot ~ Sun Jan 4 15:50
reboot ~ Sun Jan 4 14:50
reboot ~ Sun Jan 4 13:49
reboot ~ Sun Jan 4 12:49
reboot ~ Sun Jan 4 11:48
reboot ~ Sun Jan 4 10:48
reboot ~ Sun Jan 4 09:47
reboot ~ Sun Jan 4 08:47
reboot ~ Sun Jan 4 07:46
reboot ~ Sun Jan 4 06:46
reboot ~ Sun Jan 4 05:45
reboot ~ Sun Jan 4 04:45
reboot ~ Sun Jan 4 03:44
reboot ~ Sun Jan 4 02:44
reboot ~ Sun Jan 4 01:43
reboot ~ Sun Jan 4 00:43
reboot ~ Sat Jan 3 23:42
reboot ~ Sat Jan 3 22:42
reboot ~ Sat Jan 3 21:42
reboot ~ Sat Jan 3 20:41
reboot ~ Sat Jan 3 19:40
reboot ~ Sat Jan 3 18:40
reboot ~ Sat Jan 3 17:40
reboot ~ Sat Jan 3 16:39
reboot ~ Sat Jan 3 15:39
reboot ~ Sat Jan 3 14:38
reboot ~ Sat Jan 3 13:38
reboot ~ Sat Jan 3 12:37
reboot ~ Sat Jan 3 11:37
reboot ~ Sat Jan 3 10:36
reboot ~ Sat Jan 3 09:36
reboot ~ Sat Jan 3 08:35
reboot ~ Sat Jan 3 07:35
reboot ~ Sat Jan 3 06:34
reboot ~ Sat Jan 3 05:34
reboot ~ Sat Jan 3 04:33
reboot ~ Sat Jan 3 03:33
reboot ~ Sat Jan 3 02:32
reboot ~ Sat Jan 3 01:32
reboot ~ Sat Jan 3 00:31
reboot ~ Fri Jan 2 23:31
reboot ~ Fri Jan 2 22:30
reboot ~ Fri Jan 2 21:30
reboot ~ Fri Jan 2 20:29
reboot ~ Fri Jan 2 19:29
reboot ~ Fri Jan 2 18:28
reboot ~ Fri Jan 2 17:28
reboot ~ Fri Jan 2 16:28
reboot ~ Fri Jan 2 15:27
reboot ~ Fri Jan 2 14:27
reboot ~ Fri Jan 2 13:26
reboot ~ Fri Jan 2 12:26
reboot ~ Fri Jan 2 11:25
reboot ~ Fri Jan 2 10:25
reboot ~ Fri Jan 2 09:24
reboot ~ Fri Jan 2 08:24
reboot ~ Fri Jan 2 07:23
reboot ~ Fri Jan 2 06:23
reboot ~ Fri Jan 2 05:22
reboot ~ Fri Jan 2 04:22
reboot ~ Fri Jan 2 03:21
reboot ~ Fri Jan 2 02:21
reboot ~ Fri Jan 2 01:20
reboot ~ Fri Jan 2 00:20
reboot ~ Thu Jan 1 23:19
reboot ~ Thu Jan 1 22:19
reboot ~ Thu Jan 1 21:18
reboot ~ Thu Jan 1 20:18
reboot ~ Thu Jan 1 19:17
reboot ~ Thu Jan 1 18:17
reboot ~ Thu Jan 1 17:16
reboot ~ Thu Jan 1 16:16
reboot ~ Thu Jan 1 15:15
reboot ~ Thu Jan 1 14:15
reboot ~ Thu Jan 1 13:14
reboot ~ Thu Jan 1 12:14
reboot ~ Thu Jan 1 11:14
reboot ~ Thu Jan 1 10:13
reboot ~ Thu Jan 1 09:13
reboot ~ Thu Jan 1 08:12
reboot ~ Thu Jan 1 07:12
reboot ~ Thu Jan 1 06:11
reboot ~ Thu Jan 1 05:11
wtmp begins Thu Jan 1 05:11:06 EET 2009
DutchDaemon
January 7th, 2009, 13:59
Interesting series. I guess it takes one minute to boot and then start something that executes a reboot exactly one hour later. It's obviously not cron-based. Why it stopped after adding a log entry is beyond me though .. unless there's something in a background fsck that aborts and reboots if something gets stuck for an hour and you performed a fsck -y in single-user mode in the meantime.
anex
March 17th, 2009, 11:11
I have exactly the same problem...
but I've got
background_fsck="NO"
fsck_y_enable="YES"
and resetting is continuing... any help will be appreciated
tangram
March 17th, 2009, 12:50
Did you change anything related to hardware? Like messed with the BIOS, added a new hard drive, new cooler, new PXU, etc?
anex
March 17th, 2009, 13:43
Did you change anything related to hardware? Like messed with the BIOS, added a new hard drive, new cooler, new PXU, etc?
Nothing, the only thing is that I've installed webmin... now it's deinstalled, removed anything related to it...
I didn't tried fsck -y in single user mode cause I have set up in rc.conf not to run fsck in background..
Mel_Flynn
March 18th, 2009, 08:30
Remove any bzip2 compress flags from /etc/newsyslog.conf. If the problem goes away, you likely have one or a series of big log files that stress the CPU. Bzip2 is very good at heating up a CPU.
It is then time to look at the thermal paste.
anex
March 18th, 2009, 13:36
Problem solved after fsck -y was performed in single user mode. Thank anyway.
AlexP
March 23rd, 2009, 07:42
anex,hirohitosan, do you have Intel's motherboard on rebooting machines? Esp. DG33FB, DG33BU models?
hirohitosan
March 23rd, 2009, 19:19
do you have Intel's motherboard on rebooting machines?
yes, I have. But now that problem is gone
anomie
March 23rd, 2009, 19:33
What was the cause, and how did you resolve the problem?
AlexP
March 24th, 2009, 06:18
What was the cause, and how did you resolve the problem?
The cause, I think, is somewhere in hardware, maybe ACPI or RTC subsystems. The problem comes and goes, maybe triggered by abnormal reboots and suppressed by normal shutdowns.
The problem is cross-platform, there are reports on each-hour reboots on Windows and Linux too. One common thing is vendor — Intel and, I think, chipset.
vBulletin® v3.8.7, Copyright ©2000-2013, vBulletin Solutions, Inc.
0