IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Traversing a clustered tdb is a pretty expensive operation. If someone
really needs this command-line interface, we can re-add it for the local
node using messaging_dgm_forall. If someone needs that globally, there's
the "onnode all" script that could be used. Alternatively, we could
implement an enhanced ping broadcast message also returning a processes
unique id.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
This used to be a hygiene command for clustered node startup. In
clustered mode, CLEAR_IF_FIRST does not work, records can stay alive
by means of recovery. serverid.tdb will soon die, so remove this
command.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Signed-off-by: Ralph Boehme <slow@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Autobuild-User(master): Jeremy Allison <jra@samba.org>
Autobuild-Date(master): Wed Oct 21 03:10:28 CEST 2015 on sn-devel-104
The only reason for this complex monster was an overload of ctdbd.
When opening files, we unconditionally checked all share modes for
validity. This meant thousands of serverid_exists calls per second
for popular directories. This has long gone, now we only check for
validity if a conflict happens.
The only remaining caller is net serverid wipedbs, an administrative
command. If that loads ctdbd, so be it.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
On two of my opensuse machines i get 3 errors, e.g.:
../source3/utils/net_serverid.c:333:3: error: format ‘%lu’ expects argument of type ‘long unsigned int’, but argument 5 has type ‘uint64_t’ [-Werror=format]
cc1: some warnings being treated as errors
Signed-off-by: Guenter Kukkukk <kukks@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Autobuild-User(master): Jeremy Allison <jra@samba.org>
Autobuild-Date(master): Tue Mar 5 22:49:03 CET 2013 on sn-devel-104
Signed-off-by: Gregor Beck <gbeck@sernet.de>
Reviewed-by: Michael Adam <obnox@samba.org>
Reviewed-by: Stefan Metzmacher <metze@samba.org>
Autobuild-User(master): Michael Adam <obnox@samba.org>
Autobuild-Date(master): Tue Feb 19 13:56:57 CET 2013 on sn-devel-104
TDB2 returns a negative error number on failure. This is compatible
if we always check for < 0 instead of == -1.
Also, there's no tdb_traverse_read in TDB2: we don't try to make
traverse reliable any more, so there are no write locks anyway.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
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
