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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
notifyd_send() is called as part of smbd initialization both in normal daemon
mode after a fork, but also in interactive mode. In interactive mode, notifyd
should not modify the global signal state with BlockSignals(). This patch moves
the signal blocking to the place where we know that notifyd is a child daemon.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Autobuild-User(master): Jeremy Allison <jra@samba.org>
Autobuild-Date(master): Wed Jul 20 09:04:00 CEST 2016 on sn-devel-144
When notifyd is restarted, the parent will broadcast that fact to all workers.
They will then re-register their notify requests.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Using smbd_reinit_after_fork() rather then reinit_after_fork() ensures
am_parent is reset to NULL. Otherwise, when exiting for some reason, the
inherited atexit handler killkids() calls kill(0,SIGTERM) terminating
our whole process group including the main smbd.
Bug: https://bugzilla.samba.org/show_bug.cgi?id=12016
Signed-off-by: Ralph Boehme <slow@samba.org>
Reviewed-by: Volker Lendecke <vl@samba.org>
Using smbd_reinit_after_fork() rather then reinit_after_fork() ensures
am_parent is reset to NULL. Otherwise, when exiting for some reason, the
inherited atexit handler killkids() calls kill(0,SIGTERM) terminating
our whole process group including the main smbd.
Bug: https://bugzilla.samba.org/show_bug.cgi?id=12016
Signed-off-by: Ralph Boehme <slow@samba.org>
Reviewed-by: Volker Lendecke <vl@samba.org>
"child" has been free'd via "tmp"
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Autobuild-User(master): Jeremy Allison <jra@samba.org>
Autobuild-Date(master): Fri Jun 24 14:07:56 CEST 2016 on sn-devel-144
Signed-off-by: Peter Somogyi <psomogyi@hu.ibm.com>
Reviewed-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Martin Schwenke <martin@meltin.net>
Autobuild-User(master): Volker Lendecke <vl@samba.org>
Autobuild-Date(master): Mon Jun 6 16:10:19 CEST 2016 on sn-devel-144
message_send_all traverses serverid.tdb, which can be expensive
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Ralph Boehme <slow@samba.org>
Autobuild-User(master): Volker Lendecke <vl@samba.org>
Autobuild-Date(master): Mon Nov 16 17:55:36 CET 2015 on sn-devel-104
This walks brlock.tdb, which can be time-consuming.
This adds a new includes.h include. It's too much of a pain for me now to
make locking/proto.h clean to include on its own.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Ralph Boehme <slow@samba.org>
The consolidation will soon be done by a separate process. We need to
avoid the getpid() call in smbprofile_cleanup().
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Ralph Boehme <slow@samba.org>
We do way too much stuff in the parent smbd in remove_child_pid(). In
particular accessing ctdbd is not a good idea when ctdbd is stuck in something.
We've had a case where smbd exited itself with "ctdb timeout" being set to 60
seconds. ctdb was just stuck doing recoveries, and the parent smbd was sitting
in serverid_exists trying to retrieve a record for a child that had exited. Not
good.
This daemon sits there as parent->cleanupd and receives MSG_SMB_NOTIFY_CLEANUP
messages that hold the serverid and exit status of a former child. The next
commits will step by step empty remove_child_pid in the parent and move the
tasks to the helper.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Ralph Boehme <slow@samba.org>
for those trying to debug stuff.
Signed-off-by: Richard Sharpe <rsharpe@samba.org>
Reviewed-by: Ira Cooper <ira@samba.org>
Autobuild-User(master): Richard Sharpe <sharpe@samba.org>
Autobuild-Date(master): Thu Oct 8 08:48:06 CEST 2015 on sn-devel-104
This will allow an early return from ctdbd_msg_call_back so that we can also
handle CTDB_SRVID_RELEASE_IP via register_with_ctdbd.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
For this we need the kernel change notify stuff to be global: There's only one
notifyd and we have to pass over the kernel change notify watch function
Signed-off-by: Volker Lendecke <vl@samba.org>
This way we can remove the ctdb-specific includes from messages_ctdbd.c
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Michael Adam <obnox@samba.org>
Move functionality out of ctdbd_conn to its right place into smbd
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Stefan Metzmacher <metze@samba.org>
Replace all callers with direct calls to server_id_str_buf without
talloc_tos()
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
The Samba fss_agent RPC server is an implementation of the File Server
Remote VSS (Volume Shadow Copy Service) Protocol, or FSRVP for short.
FSRVP is new with Windows Server 2012, and allows authenticated clients
to remotely request the creation, exposure and deletion of share
snapshots.
The fss_agent RPC server processes requests on the FssAgentRpc named
pipe, and dispatches relevant snapshot creation and deletion requests
through to the VFS.
The registry smb.conf back-end is used to expose snapshot shares, with
configuration parameters and share ACLs cloned from the base share.
There are three FSRVP client implementations that I'm aware of:
- Samba rpcclient includes fss_X commands.
- Windows Server 2012 includes diskshadow.exe.
- System Center 2012.
FSRVP operations are only processed for users with:
- Built-in Administrators group membership, or
- Built-in Backup Operators group membership, or
- Backup Operator privileges, or
- Security token matches the initial process UID
MS-FSRVP specifies that server state should be stored persistently
during operation and retrieved on startup. Use the existing fss_srv.tdb
FSRVP state storage back-end to satisfy this requirement.
Signed-off-by: David Disseldorp <ddiss@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
What?
This patch gets rid of the central shared memory segment referenced by
"profile_p". Instead, every smbd gets a static profile_area where it collects
profiling data. Once a second, every smbd writes this profiling data into a
record of its own in a "smbprofile.tdb". smbstatus -P does a tdb_traverse on this
database and sums up what it finds.
Why?
At least in my perception sysv IPC has not the best reputation on earth. The
code before this patch uses shmat(). Samba ages ago has developed a good
abstraction of shared memory: It's called tdb.
The main reason why I started this is that I have a request to become
more flexible with profiling data. Samba should be able to collect data
per share or per user, something which is almost impossible to do with
a fixed structure. My idea is to for example install a profile area per
share and every second marshall this into one tdb record indexed by share
name. smbstatus -P would then also collect the data and either aggregate
them or put them into individual per-share statistics. This flexibility
in the data model is not really possible with one fixed structure.
But isn't it slow?
Well, I don't think so. I can't really prove it, but I do believe that on large
boxes atomically incrementing a shared memory value for every SMB does show up
due to NUMA effects. With this patch the hot code path is completely
process-local. Once a second every smbd writes into a central tdb, this of
course does atomic operations. But it's once a second, not on every SMB2 read.
There's two places where I would like to improve things: With the current code
all smbds wake up once a second. With 10,000 potentially idle smbds this will
become noticable. That's why the current only starts the timer when something has
changed.
The second place is the tdb traverse: Right now traverse is blocking in the
sense that when it has to switch hash chains it will block. With mutexes, this
means a syscall. I have a traverse light in mind that works as follows: It
assumes a locked hash chain and then walks the complete chain in one run
without unlocking in between. This way the caller can do nonblocking locks in
the first round and only do blocking locks in a second round. Also, a lot of
syscall overhead will vanish. This way smbstatus -P will have almost zero
impact on normal operations.
Pair-Programmed-With: Stefan Metzmacher <metze@samba.org>
Signed-off-by: Volker Lendecke <vl@samba.org>
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Ralph Boehme <slow@samba.org>
Will enable us to solve the dynamic share path problem
with leases on [homes].
We're also able to give the correct error codes when a
lease key is re-used with a different file name.
Pair-Programmed-With: Jeremy Allison <jra@samba.org>
Signed-off-by: Volker Lendecke <vl@samba.org>
Signed-off-by: Jeremy Allison <jra@samba.org>
Reviewed-by: Stefan Metzmacher <metze@samba.org>
The DO_PROFILE_INC thingies already #define to nothing without
WITH_PROFILE, and any sane compiler will just not compile the if-condition
if there is no body to be executed.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Pair-Programmed-With: Stefan Metzmacher <metze@samba.org>
Signed-off-by: Michael Adam <obnox@samba.org>
Signed-off-by: Stefan Metzmacher <metze@samba.org>
