System shutting down (sometimes) after scheduled backup
This has happened only twice. The backup runs at 6:30 and takes about ten minutes. Both times, /var/log/system.log looks like this just before the log entries showing where I started the system again:
Code:
Oct 2 06:41:02 slynew diskarbitrationd[42]: applet [1513]:34843 not responding. I haven't actually witnessed the shutdown, and it doesn't happen every time the backup runs. I'm judging based on the logs and some circumstantial evidence (someone telling me he couldn't ping my system sometime just before 7:30) that the shutdown is happening right after the backup runs. So I don't know that its connected to SuperDuper, but before calling Apple I thought I'd ask if anyone else has experienced this and/or if any of the above is illuminating. |
Basically, it looks like the drive must have failed or stopped responding properly. Very strange. Running any low-level utilities, antivirus, etc?
|
But would a failure to respond at the end of a backup make the system shut down (i.e. the whole Mac)?
In answer to your question, no antivirus or the like is running. The scheduled update seems to have run fine. And I've just noticed that the message "kernel[0]: jnl: close: flushing the buffer cache" is the same given when I unmount the mirror partition myself in Disk Utility (such as just after booting). Speaking of which, is there any possibility that my preference for keeping that partition unmounted, and with other partitions remaining mounted, has anything to do with this? |
It could be indicative of a system-wide failure, yes... and that could be due to a misbehaving drive. No panic.log?
|
No panic.log, no panic screen ("You need to restart your computer," etc.). Just the next morning, my Mac ain't on.
I watched a scheduled backup this time. Everything seemed to work. This is the system.log: Code:
Oct 10 06:30:16 slynew diskarbitrationd[42]: disk1s2 hfs CBADEC29-3F8C-357E-8B45-7D072826D110 Mirror /Volumes/Mirror I guess I'm just going to reschedule this during the day and keep watching it until something happens. |
OK. So, "applet" (which is likely our scheduling driver) has asked for the eject. It stops responding while we're waiting for the system to do it. It flushes the journal and then does eject. That seems reasonable without the shutdown, at least!
|
All times are GMT -4. The time now is 02:31 AM. |
Powered by vBulletin® Version 3.8.9
Copyright ©2000 - 2024, vBulletin Solutions, Inc.