[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20110719220620.GA28373@openwall.com>
Date: Wed, 20 Jul 2011 02:06:20 +0400
From: Solar Designer <solar@...nwall.com>
To: owl-users@...ts.openwall.com
Subject: Re: power outage
On Tue, Jul 19, 2011 at 07:11:41PM +0000, alexis wrote:
> In fact I am running owl as a home server servicing web pages
> (http://akconcept.sytes.net) and other remote programs such as rsync for file
> backup.
BTW, we appreciate links to the Owl homepage from web servers running on
Owl. You may use the buttons from:
http://www.openwall.com/Owl/artwork
Of course, this is entirely up to you.
> The power outage was unexpected. I ran into runlevel 1, unmounted my
> disc partition and ran the command e2fsck -vy /dev/mypartiotion the result was
> "clean file system". An openvz container was mounted when the power outage
> occurred, is it ok or shall I do something else?
I think everything is OK, and you don't need to do anything else. When
things like that occasionally happen to my home router (also running
Owl), I don't bother doing anything.
We made several changes before the Owl 3.0 release to make Owl survive
power outages better:
The rc.sysinit script is aware of fsck exit codes and will automatically
reboot the system a second time if fsck reports that it made significant
changes to the root filesystem (requiring a reboot). It gives the
admin 60 seconds to possibly override the automatic reboot decision, but
doing so is not recommended and there's usually no one at the console
anyway. Most of the time, the journal recovery is sufficient, though,
so this second reboot is very rarely seen.
In our vzctl package, there's a cron job - only enabled when the vz
service is in use - that saves the containers' disk quota info to disk
every 5 minutes. Normally, the disk usage by containers with quota
enabled is recalculated when starting up after unclean shutdown, but
without a cron job like this any manually set per-user and per-group
quotas inside the containers would be lost. With this cron job, only
very recent ones are lost. Also, having a cron job like this gives the
admin the option to disable the disk usage recalculation (and accept the
hopefully small discrepancies) to speedup container startup after
unclean shutdown. (This is important on servers with many/large
containers, with millions of files.)
One trivial thing that we haven't dealt with yet, though, is saving of
system time to the NVRAM. This is currently only done on clean
shutdown, but not when the system is running normally. Maybe we should
add a cron job like this. Running the NTP service helps, but if the
time difference is less than 3 minutes, ntpd will adjust the time
slowly. So it is possible that after an unclean reboot you'll have the
system time off by up to 3 minutes for a while despite of you having the
NTP service enabled. There's room for improvement here.
Alexander
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
