Michael Tokarev
2023-Sep-12 08:07 UTC
[Samba] WG: Update to samba 4.19 Aduc no longer working No login
12.09.2023 10:14, Andrew Bartlett via samba wrote:>> 12.09.2023 09:56, Daniel M?ller via samba:>>> /dev/shmtmpfs 5,0M 4,7M 324K 94% >>> /run/lock <--- samba is filling> That is a really strange configuration, with TB of disk available > elsewhere!It actually is not. All these are tmpfs filesystems, ie, something which is entirely in RAM. Which fits exactly for this usage. It is also quite common to have /run/lock separate from /run, and to have 5M of space in /run/lock. This is because /run/lock is really for locking purposes only, to have things like zero-length lock files (which are fcntl- locked by some process) to prevent concurrent access to some subsystem, or maybe pid files, or somesuch. This stuff is really small and 5M is more than adequate for this. However, samba lock directory not only have this sort of lock files, but it also contains database of files open by remote clients. This one is significantly larger, and really should not be put to /run/lock, even if both are about "locking". The difference here is, basically, /run/lock is meant for "subsystem" or "service" locking, and there's just a small amount of services on the system. But samba locking is a client thing which can be huge depending on server usage. Also, besides the locking, samba keeps some other data in this directory, like f.e. gencache.tdb. Still, locking.tdb is the largest file in there, it seems like. This is exactly why I configure samba on debian to use /run/samba for all this stuff instead of /run/lock. Using /var/run for this isn't a good idea, since this all is a run-time stuff which should be removed at exit/reboot, and things like that are best to be kept in ram, - fast access, significantly less hdd wear etc. Generally, samba does place its files a bit arbitrary and unthinkfully. For example, in debian I have a patch which move socket directory (which is definitely a runtime thing, with sockets to communicate with running processes) to lock directory instead of having them in /var/lib/samba/ (!!) where they don't fit at all. /mjt
On Tue, 2023-09-12 at 11:07 +0300, Michael Tokarev wrote:> Generally, samba does place its files a bit arbitrary and > unthinkfully.For example, in debian I have a patch which move socket > directory (whichis definitely a runtime thing, with sockets to > communicate with runningprocesses) to lock directory instead of > having them in /var/lib/samba/ (!!)where they don't fit at all.The main reason that at least some of the sockets are under /var/lib/samba is that the socket permisisons are long-term state, even if the listeners are ephemeral. I agree it feels a bit random, partly due to trying not to break old installations, but we did read the FHS docs and put in some effort to sort things into the right categories. Andrew Bartlett -- Andrew Bartlett (he/him) https://samba.org/~abartlet/Samba Team Member (since 2001) https://samba.orgSamba Team Lead https://catalyst.net.nz/services/sambaCatalyst.Net Ltd Proudly developing Samba for Catalyst.Net Ltd - a Catalyst IT group company Samba Development and Support: https://catalyst.net.nz/services/samba Catalyst IT - Expert Open Source Solutions