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

Polytropon freebsd at
Wed May 1 09:01:46 UTC 2013

On Wed, 1 May 2013 12:58:49 +0430, takCoder wrote:
> Excuse me again..
> i was trying to test the situation explained here, so i just defined a user
> with pw command, waited for 2minutes and then power off the system.. Again
> i couldn't login anymore..
> if we assume that, pw is still working with db files after 2 minutes, the
> question is that, is it usual for a command to keep db files busy, this
> long??
> or is it pw problem?
> or is t something else that i'm missing??

For login processes, the plain text files and the database
files are involved. The pw command will modify all of them
if you add a new user. The "2 minutes problem" should not
be related to pw (or pwd_mkdb), but maybe due to syncing.
File system access (here: write) is done asynchronously,
so the system will decide when it will sync the memory
buffers with the (non-volatile) disk content. This task
involves both the sync() call and how the actual disk
driver acts to it. Note: Just because someone calls sync()
does _not_ imply that the synchronisation takes place in
that exact moment. But it should not require several
minutes to complete the write and bring the files into
the required state (on disk).

Furthermore, file system corruption due to an abrupt
cut of power should be avoided. Whenever the system comes
up in a non-clean state, fsck should be run first, _then_
the boot process should continue. Still it's possible that
this process leaves truncated files behind (e. g. the
binary database files with a length of zero, which implies
they will have to be rebuilt by pwd_mkdb).

Alternatively to pw, you could try adduser, which is more
an interactive program, but can perform the same tasks.
Again, it would take care of updating all required files.
This is the situation one would expect after the program
ended, or at least some seconds after one got back to the
root prompt.

During the 2 minutes, you could use programs like lsof
(it's in ports) to check if a program has a file open,
so you could capture the "power off while writing to
file" incident.

After you could not login again, did you check the
files involved in the login process? Those should include:


Probably also /etc/login.conf and /etc/login.conf.db, but
I think those are not critical to the success of a login
attempt per se.

Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...

More information about the freebsd-questions mailing list