The following was preventing ctdb from starting with selinux in enforcing mode: Also, fwiw -- it might be nice to fix the instructions that sealert prints to work around the problem to create "mypol" files /tmp or something. It's not clear from those instructions that they create files in the cwd. People who run them end up with "mypol.*" littering random places in the filesystem. ------------------[snip]--------------- # sealert -l 6cdd7130-de59-4be1-b686-68cd3aece37a SELinux is preventing /usr/sbin/ctdbd from unlink access on the sock_file ctdb.socket. ***** Plugin catchall (100. confidence) suggests *************************** If you believe that ctdbd should be allowed unlink access on the ctdb.socket sock_file by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # grep ctdbd /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp Additional Information: Source Context system_u:system_r:ctdbd_t:s0 Target Context unconfined_u:object_r:user_tmp_t:s0 Target Objects ctdb.socket [ sock_file ] Source ctdbd Source Path /usr/sbin/ctdbd Port <Unknown> Host gnode1.example.com Source RPM Packages ctdb-1.2.39-2.fc17.x86_64 Target RPM Packages Policy RPM selinux-policy-3.10.0-145.fc17.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name gnode1.example.com Platform Linux gnode1.example.com 3.5.1-1.fc17.x86_64 #1 SMP Thu Aug 9 17:50:43 UTC 2012 x86_64 x86_64 Alert Count 3 First Seen 2012-08-22 08:08:47 EDT Last Seen 2012-08-22 08:14:19 EDT Local ID 6cdd7130-de59-4be1-b686-68cd3aece37a Raw Audit Messages type=AVC msg=audit(1345637659.14:71): avc: denied { unlink } for pid=991 comm="ctdbd" name="ctdb.socket" dev="dm-1" ino=914593 scontext=system_u:system_r:ctdbd_t:s0 tcontext=unconfined_u:object_r:user_tmp_t:s0 tclass=sock_file type=SYSCALL msg=audit(1345637659.14:71): arch=x86_64 syscall=unlink success=no exit=EACCES a0=c092f0 a1=1 a2=0 a3=ffffffffffffffeb items=0 ppid=1 pid=991 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm=ctdbd exe=/usr/sbin/ctdbd subj=system_u:system_r:ctdbd_t:s0 key=(null) Hash: ctdbd,ctdbd_t,user_tmp_t,sock_file,unlink audit2allow #============= ctdbd_t ============== allow ctdbd_t user_tmp_t:sock_file unlink; audit2allow -R #============= ctdbd_t ============== allow ctdbd_t user_tmp_t:sock_file unlink;
This looks strange, you have a ctdb.socket that was created by a user and then ctdbd tries to delete it, did you run this by hand and then run it as a service? IE If you delete to sock_file, does everythin work correctly and continue to.
That must have been what it was. I had some problems getting it to start up, so I started the daemon by hand a few times before running it under systemd. If there's no socket to begin with, it works fine. I'll close this as NOTABUG...sorry for the noise!