On 9/28/2021 6:29 PM, Peter Stuge wrote:
Hildegard Meier wrote:
But the problem is that the last started syslog-ng aquires the lock
for the NFS shared /var/data/chroot/<username>/dev/log so the other
server cannot read it anymore
Is it known what kind of lock this is? Was it investigated? Maybe on
the NFS server?
I suspect it is not a lock, but the "struct sockaddr_un" used with bind and connect or
some index into the server's kernal unix-stream like process and fd used in the bind is stored in the chrooted /dev/log when
the syslog-ng creates it. The would match the statement:
> So, if a user logs in on the first server, where syslog-ng was started least(last?), the user's sftp activity is logged on the first server.
> But if the user logs in on the second server, it's sftp activity is not logged, neither on the second nor on the first server.
>
> If the syslog-ng is then restarted on the second server, the sftp user's activity is exclusively logged only on the second server and only for logins on the second server.
http://manpages.ubuntu.com/manpages/focal/man7/unix.7.html
Says: "The AF_UNIX (also known as AF_LOCAL) socket family is used to communicate between
processes on the same machine efficiently.
The "same machine" is the key.
netstat should show what sockets are in use.
Douglas E Engert wrote:
You already have 800 NFs volumes and they are all mounted on each server.
AIUI there's only one NFS export with all homedirs mounted on each server,
and avoiding per-user runtime setup such as mounts is a requirement.
Jochen Bern wrote:
I *still* suspect that if only you could configure the syslogd's to use
a file locking method that just does *not* work across NFS shares -
there's about half a dozen different methods available, see, e.g.,
https://dovecot.org/pipermail/dovecot/2011-July/060149.html
-, you could circumvent that effect from the get-go ...
Looking through the afsocket module in syslog-ng it does no file locking.
I'm curious what kind of locking it is. Maybe the contention is
all within the NFS layer and could be overcome by setting a nolock
or local_lock mount option on the SFTP servers, if either option is
acceptable for the use case.
Kind regards
//Peter
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@xxxxxxxxxxx
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
--
Douglas E. Engert <DEEngert@xxxxxxxxx>
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@xxxxxxxxxxx
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
