pwd.db/spwd.db file corupption when having unsafe system poweroff

Thu Apr 18 16:40:36 UTC 2013

hi again,

real thanks to all of you; for really complete and clear answers.. it's
amazing to have a clear view of what's on, when you need to deal with it. :)

as a quick conclusion, for now:
1- i inserted a shell file to /usr/local/etc/rc.d/ which runs pwd_mkdb
/etc/master.passwd and tested it.. the error mentioned in this email's
title is no more seen in frequent tests.. (but i don't think it's that good
to use a mkdb command this frequently.. right? for me, it was somehow a
test..)

2- the notes mentioned about fsck was nice.. cause before this, we've faced
uncleaned FS in the mentioned condition and we where in doubt where the
automate fsck had gone?? ;)
 i think it's better to test the foreground fsck just in case.. for sure,
background fsck has its own benefits.. but, any benefits has its own
costs.. :)

3- this "power-key  functionality setting", is what i'll work on, as it
seems helpful, in near future.. but, i think for this thread, it would be
off-topic somehow to talk about its details.. i'll try to write them back,
on related thread, if required and if it was new..

BTW, it was _really_ of  hardware knowledge.. ;)

again, thank you. :)

Best Regards,
t.a.k

On Wed, Apr 17, 2013 at 8:05 PM, Polytropon <freebsd at edvax.de> wrote:

> Allow me a few additions:
>
> On Tue, 16 Apr 2013 16:45:59 -0400, Michael Powell wrote:
> > Pressing the power button for 4 seconds as described is invoking the ACPI
> > layer to stimulate call(s) down to the system BIOS.
>
> No. In most (but of course not all) default settings the
> "long press" will forcedly (and with _no_ message to the OS)
> turn off the system's power.
>
> The "short press" will emit the ACPI signal to the OS to
> deal with the power-off sequence itself.
>
> Still it's possible to have a different programming for the
> button. For example, it seems to be common to have this
> button perform a "ACPI sleep", "ACPI hibernate" or "ACPI
> powersafe" mode on "short press", and (as you mentioned)
> the "ACPI power down" on long press.
>
> But as I said: _What_ the button actually does is defined
> in the CMOS setup.
>
>
> http://en.wikipedia.org/wiki/Advanced_Configuration_and_Power_Interface#Power_states
>
> have a look at this page to find out more about the various
> possible signals (power states).
>
>
>
> > Whatever is set in the
> > BIOS wrt to power control and various power-savings modes are passed
> through
> > the ACPI layer. The problem with this is the acpi module in FreeBSD may,
> or
> > may not, be a perfect implementation for every possible piece of
> hardware in
> > existance.
>
> This statement especially applies in regards to laptops, where
> closing the lid can also trigger a specific signal, and opening
> the device again sends another signal. Vendors don't agree on
> how to "properly" do this, so there are many different ACPI
> implementations.
>
> % ls /boot/kernel/acpi*
> /boot/kernel/acpi.ko*           /boot/kernel/acpi_ibm.ko*
> /boot/kernel/acpi_aiboost.ko*   /boot/kernel/acpi_panasonic.ko*
> /boot/kernel/acpi_asus.ko*      /boot/kernel/acpi_sony.ko*
> /boot/kernel/acpi_dock.ko*      /boot/kernel/acpi_toshiba.ko*
> /boot/kernel/acpi_fujitsu.ko*   /boot/kernel/acpi_video.ko*
> /boot/kernel/acpi_hp.ko*        /boot/kernel/acpi_wmi.ko*
>
> You can see from this example that FreeBSD only supports a
> subset of what can be considered possible. Of course there
> are many "fields of compatibility", but it may still result
> in specific hardware not working properly -- mostly in the
> area of laptops and their accessories (like docking stations).
>
>
>
> > The piece of that which really concerns me are individual
> > manufactuer BIOS quirks can be just enough 'off' so as to misbehave even
> when
> > the FreeBSD acpi implentation is basically sound.
>
> Even though I did not experience that myself, it can be
> considered possible. A sloppy ACPI implementation can
> be the source of many kinds of trouble, even involving
> such "simple" devices like a power button.
>
>
>
> > The jist of this is (IMHO
> > here - YMMV) is I consider it a bad procedure to turn off a server as
> you've
> > described.
>
> Definitely. :-)
>
>
>
> > Use the shutdown command properly instead. I would never do what
> > your coworker did to any of my servers.
>
> A mechanicl protection could prevent that.
>
>
>
> > Caveat being sometimes you have no
> > other choice but to do a hard power-down. A hard power-down is done by
> using
> > the switch on the power supply, and not using the ACPI/BIOS from pressing
> > the power switch on the front.
>
> This is also possible. Both this _and_ the default "forced power off"
> (the "long press" in many defaults) equal the action of pulling the
> power cord.
>
>
>
> > When you do have an 'uh-oh' like this, FreeBSD normally boots back into
> an
> > unclean file system with corresponding whinings and complaints about how
> the
> > file system(s) were not properly dismounted.
>
> This is an intended behaviour. TO prevent further damage and to
> make data recovery possible (worst case), the system does not
> try to "boot by all means", just to make the (clueless) user
> happy. :-)
>
>
>
> > Normally a background fsck
> > ensues after 60 seconds of idle.
>
> This _can_ be dangerous, because at this time, the system has
> already been booted into a "somehow working" state. You should
> ask yourself the question: Can I invest the time to have _no_
> background fsck (i. e., a foreground fsck which maybe will ask
> prior to doing anything "heavy") to make sure my data is consistent,
> because it is important data which _needs_ to be okay? In this
> case, put background_fsck="NO" in /etc/rc.conf -- and wait.
>
> When using UFS, there _may_ be file system damages so severe
> that fsck will _not_ correct them manually (which often leads
> to data loss of important data that could have been saved if
> the proper _user decision_ would have been taken place). This
> will only happen in the "interactive mode" at system startup.
>
>
>
> > In your case whatever files were left open
> > and not properly closed this background fsck, had it been allowed to run
> and
> > complete, would have cleaned this up.
>
> Maybe, maybe not. It highly depends on what actually happened,
> and it's nearly impossible to find that out, especially when
> there is no control about what the background fsck does (while
> the system is already happily running and humming).
>
>
>
> > The problem starts when someone
> > presses the power off button again, and again, before this process
> completes.
> > Using the power button ACPI/BIOS only compounds this situation.
>
> Correct. That's why the time to have fsck perform its task in
> the foreground should be invested, at least after such an abrupt
> action.
>
>
>
> > I would recommend you do NOT use the power button as you described above.
> > Period.
>
> In case of _servers_, this button is commonly considered an
> "emergency button" anyway, and therefor hardly used. :-)
>
>
>
> > In any event pay particular attention to that very first boot after
> > an 'uh-oh' power off event. Look at top and watch for the background
> fsck to
> > kick off and complete, returning the machine to quiescent state BEFORE
> you do
> > ANYTHING else to it. This includes pressing the button on the front.
>
> The "doing anything else" can be the problem with a background fsck.
> Let's say the server starts its services which start accessing the
> partitions currently checked by fsck. Yes, I know, snapshots and all
> this stuff. Sometimes it works. Sometimes it doesn't. My additional
> advice would be: Do not use a background fsck. If you had a power
> failure (for whatever reason), take the time to make sure your system
> boots into a verified state (NOT: boots into a questionable state,
> tries to verify it during normal operations, and pretends "everything
> is fine").
>
>
>
>
>
> --
> Polytropon
> Magdeburg, Germany
> Happy FreeBSD user since 4.0
> Andra moi ennepe, Mousa, ...
> _______________________________________________
> freebsd-questions at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-questions
> To unsubscribe, send any mail to "
> freebsd-questions-unsubscribe at freebsd.org"
>