similar to: [Announce] CTDB 2.5.1 available for download

Hello, First and foremost, thanks *very* much for ctdb. It's a joy to use after banging around with other HA solutions. We're planning to use it to export Samba and NFS shares throughout campus. I'm having one problem with the NFS part though. When ctdbd first starts statd (we're using CTDB_MANAGES_NFS=yes), it does so without appending the stuff in the STATD_HOSTNAME variable

Hi Ulrich, On Tue, 15 Oct 2024 15:22:51 +0000, Ulrich Sibiller via samba <samba at lists.samba.org> wrote: > In current (6140c3177a0330f42411618c3fca28930ea02a21) samba's > ctdb/tools/statd_callout_helper I find this comment: > > notify) > ... > # we need these settings to make sure that no tcp connections > survive # across a very fast failover/failback

Hi All, I've got a CTDB cluster, managing NFSv3 and Samba, sitting in front of a GPFS storage cluster. The NFSv3 piece is carrying some pretty heavy traffic at peak load. About once every three to four days, CTDB has been exhibiting behaviors that result in IP-failover between two nodes for reasons that are currently unknown. The exact chain of events has been a little different each time

This is the latest stable release of CTDB. CTDB 2.5.5 can be used with Samba releases prior to Samba 4.2.x (i.e. Samba releases 3.6.x, 4.0.x and 4.1.x). Changes in CTDB 2.5.5 ===================== User-visible changes -------------------- * Dump stack traces for hung RPC processes (mountd, rquotad, statd) * Add vaccuming latency to database statistics * Add -X option to ctdb tool that uses

Hi, In current (6140c3177a0330f42411618c3fca28930ea02a21) samba's ctdb/tools/statd_callout_helper I find this comment: notify) ... # we need these settings to make sure that no tcp connections survive # across a very fast failover/failback #echo 10 > /proc/sys/net/ipv4/tcp_fin_timeout #echo 0 > /proc/sys/net/ipv4/tcp_max_tw_buckets #echo 0 >

Changes in CTDB 2.2 =================== User-visible changes -------------------- * The "stopped" event has been removed. The "ipreallocated" event is now run when a node is stopped. Use this instead of "stopped". * New --pidfile option for ctdbd, used by initscript * The 60.nfs eventscript now uses configuration files in /etc/ctdb/nfs-rpc-checks.d/ for

===================================================================== "Our visions begin with our desires." Audre Lorde ===================================================================== Release Announcements --------------------- This is the latest stable release of Samba 4.2. Changes since 4.2.1: -------------------- o Michael Adam <obnox at samba.org> *

===================================================================== "Our visions begin with our desires." Audre Lorde ===================================================================== Release Announcements --------------------- This is the latest stable release of Samba 4.2. Changes since 4.2.1: -------------------- o Michael Adam <obnox at samba.org> *

Hi All, We're using CTDB to cluster protocols over a large SAN and have had some pain related to a bit of a design flaw: we store CTDB and protocol-specific accounting files (recovery locks, state files, etc) on the same filesystem that we're offering through CTDB itself. This makes our front-end services pretty intolerant of flapping in the back-end filesystem, which is obviously not

Can anyone help with some pointers to debug a problem with Samba and CTDB with smbstatus traversing the connections tdb? I've got a new two node cluster with Samba and CTDB on AIX. If I run smbstatus when the server has much user activity it hangs and the node it was run on gets banned. I see the following in the ctdb log: 2014/10/29 11:12:45.374580 [3932342]:

Hi, This morning our CTDB managed cluster took a nosedive. We had member machines with hung smbd tasks which causes them to reboot, and the cluster did not come back up consistently. We eventually got it more or less stable with two nodes out of the 3, but we're still seeing worrying messages, eg we've just noticed: 2017/04/19 12:10:31.168891 [ 5417]: Vacuuming child process timed

Hi Bob, On Thu, 26 Oct 2017 22:44:30 -0700, Computerisms Corporation via samba <samba at lists.samba.org> wrote: > I set up a ctdb cluster a couple months back. Things seemed pretty > solid for the first 2-3 weeks, but then I started getting reports of > people not being able to access files, or some times directories. It > has taken me a while to figure some stuff out,

Hi, This occurred again this morning, when the user reported the problem, I found in the ctdb logs that vacuuming has been going on since last night. The need to fix it was urgent (when isn't it?) so I didn't have time to poke around for clues, but immediately restarted the lxc container. But this time it wouldn't restart, which I had time to trace to a hung smbd process, and

On Wed, 19 Apr 2017 18:06:35 +0200, David Disseldorp via samba wrote: > > 2017/04/19 10:40:31.294250 [ 7423]: /etc/ctdb/debug_locks.sh: line 73: > > gstack: command not found > > This script attempts to dump the stack trace of the blocked process, > but can't as gstack isn't installed - it should be available in the > gdb package. > > @Martin: would the

Hi List, I set up a ctdb cluster a couple months back. Things seemed pretty solid for the first 2-3 weeks, but then I started getting reports of people not being able to access files, or some times directories. It has taken me a while to figure some stuff out, but it seems the common denominator to this happening is vacuuming timeouts for locking.tdb in the ctdb log, which might go on

Changes in CTDB 2.3 =================== User-visible changes -------------------- * 2 new configuration variables for 60.nfs eventscript: - CTDB_MONITOR_NFS_THREAD_COUNT - CTDB_NFS_DUMP_STUCK_THREADS See ctdb.sysconfig for details. * Removed DeadlockTimeout tunable. To enable debug of locking issues set CTDB_DEBUG_LOCKS=/etc/ctdb/debug_locks.sh * In overall statistics and database

This will be the last stable release of CTDB 2.5.x. CTDB 2.5.6 should only be used with Samba releases prior to Samba 4.2.x (i.e. Samba releases 3.6.x, 4.0.x and 4.1.x). Please note that Samba releases 3.6.x, 4.0.x and 4.1.x are out of support. If you are still using any of these releases for clustered samba with CTDB 2.5.x, please switch to latest Samba 4.3.x or 4.4.0 (Since Samba 4.2.0 release

hm, I stand correct on the problem solved statement below. Ip addresses are simply not cooperating on the 2nd node. root at vault1:~# ctdb ip Public IPs on node 0 192.168.120.90 0 192.168.120.91 0 192.168.120.92 0 192.168.120.93 0 root at vault2:/service/ctdb/log/main# ctdb ip Public IPs on node 1 192.168.120.90 0 192.168.120.91 0 192.168.120.92 0 192.168.120.93 0 root at

Hi Marin - again thank you for the help. I can't believe I coundn't find any info about this big configuration change. Even the Samba WIKI doesn't really spell this out at all in instructs you to use ctdbd.conf. Do I need to enable the 20.nfs_ganesha.check script file at all, or will the config itself take care of that? Also, are there any recommendations on which nfs-checks.d

====================================================== "Those who believe in telekinetics, raise my hand." Kurt Vonnegut ====================================================== Release Announcements --------------------- This is the latest stable release of the Samba 4.5 release series. Changes since 4.5.5: -------------------- o Jeremy Allison <jra at samba.org>