summaryrefslogtreecommitdiff
path: root/source4/torture/rpc
diff options
context:
space:
mode:
authorVolker Lendecke <vl@samba.org>2010-03-02 17:02:01 +0100
committerVolker Lendecke <vl@samba.org>2010-03-10 16:07:10 +0100
commit89c785c47aa0fceba148297116e863f46941bd42 (patch)
treef1c4812e6467614bd542abda6f8bab198af1889d /source4/torture/rpc
parent184afeb57d0daeacfacdb8c976032697efe00214 (diff)
downloadsamba-89c785c47aa0fceba148297116e863f46941bd42.tar.gz
samba-89c785c47aa0fceba148297116e863f46941bd42.tar.bz2
samba-89c785c47aa0fceba148297116e863f46941bd42.zip
s3: Fix a long-standing problem with recycled PIDs
When a samba server process dies hard, it has no chance to clean up its entries in locking.tdb, brlock.tdb, connections.tdb and sessionid.tdb. For locking.tdb and brlock.tdb Samba is robust by checking every time we read an entry from the database if the corresponding process still exists. If it does not exist anymore, the entry is deleted. This is not 100% failsafe though: On systems with a limited PID space there is a non-zero chance that between the smbd's death and the fresh access, the PID is recycled by another long-running process. This renders all files that had been locked by the killed smbd potentially unusable until the new process also dies. This patch is supposed to fix the problem the following way: Every process ID in every database is augmented by a random 64-bit number that is stored in a serverid.tdb. Whenever we need to check if a process still exists we know its PID and the 64-bit number. We look up the PID in serverid.tdb and compare the 64-bit number. If it's the same, the process still is a valid smbd holding the lock. If it is different, a new smbd has taken over. I believe this is safe against an smbd that has died hard and the PID has been taken over by a non-samba process. This process would not have registered itself with a fresh 64-bit number in serverid.tdb, so the old one still exists in serverid.tdb. We protect against this case by the parent smbd taking care of deregistering PIDs from serverid.tdb and the fact that serverid.tdb is CLEAR_IF_FIRST. CLEAR_IF_FIRST does not work in a cluster, so the automatic cleanup does not work when all smbds are restarted. For this, "net serverid wipe" has to be run before smbd starts up. As a convenience, "net serverid wipedbs" also cleans up sessionid.tdb and connections.tdb. While there, this also cleans up overloading connections.tdb with all the process entries just for messaging_send_all(). Volker
Diffstat (limited to 'source4/torture/rpc')
0 files changed, 0 insertions, 0 deletions