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.