Hello, 14.05.08, 20:56, "Nicolas François" <[EMAIL PROTECTED]>: > On Wed, May 14, 2008 at 06:00:51PM +0400, [EMAIL PROTECTED] wrote: ... > > Maybe we should try combined 1/3 approach. 1st on flock-less > > platforms, 3rd of flock-able ones. > > My idea was to let the admin remove the lock file herself.
OK, this is fine on systems which lack flock/lockf, it's like manually performed option #1. > If the system is restarted, or a locker process died for any reason, it > might be better to warn the admin, and let her do the cleanup. I agree, having automatic lock cleanup script to be run on restart is probably not a very good idea, the system administrator may want to implement this himself, if/when the system is prone to occasional reboots in midst of modifying passwd/shadow/group files %) Sysadmin may know better, during which boot stage this can be done best of all (before NFS mount/after NFS mount/before "/tmp" cleanup and so on). > The user/group databases might be inconsistent, and only the admin may > know what append, when, and what operation was ongoing. > I don't know what is the error message currently, but it might be good to > review it (them) to make sure it is helpful (at least to indicate that a > lock file exists). > It would however be too much to indicate that: > * another process might be using the database and she has to retry later > * one process might have die and left lock file. In that case, the user > must audit the system and then remove the lock file manually. In fact, flock/lockf-produced lock on the file wil be cleaned by the system (kernel) when the holding process dies or closes the file. That's why I consider flock/lockf locking as one of the best resource protection methods on unices. You can tell immediately and reliably that the file is/isn't being hold by another process. There are still some problems, but IMO we should implement flock/lockf for passwd.lock, group.lock files. > * there might be a bug in a shadow tool or another tool that avoided the > lock file removal. maybe SIGINT is not explicitly handled or similar. But there's no way to cleanup after itself on SIGKILL ;) (flock/lockf works here) > But that could be mentioned in the manpages (FILES section). Should be mentioned there too. -- WBR, xrgtn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
