Bug 983665

I forgot to provide version details:

running Fedora 19 with latest updates (fence-virtd-0.3.0-13.fc19.x86_64)

Even when it does start, its unusable.

Running 'fence_virtd -w' from the command line works as expected, but the daemon appears unreachable when using "systemctl start fence_virtd.service'.

The client (on the same host) just sits there printing:
# fence_xvm -ddddddd -o list 
....
Opening /dev/urandom
Sending to 225.0.0.12 via 172.16.1.4
Setting up ipv4 multicast send (225.0.0.12:1229)
Joining IP Multicast group (pass 1)
Joining IP Multicast group (pass 2)
Setting TTL to 2 for fd4
ipv4_send_sk: success, fd = 4
Opening /dev/urandom
....

(In reply to Andrew Beekhof from comment #2)
> Even when it does start, its unusable.
> 
> Running 'fence_virtd -w' from the command line works as expected, but the
> daemon appears unreachable when using "systemctl start fence_virtd.service'.
> 
> The client (on the same host) just sits there printing:
> # fence_xvm -ddddddd -o list 
> ....
> Opening /dev/urandom
> Sending to 225.0.0.12 via 172.16.1.4
> Setting up ipv4 multicast send (225.0.0.12:1229)
> Joining IP Multicast group (pass 1)
> Joining IP Multicast group (pass 2)
> Setting TTL to 2 for fd4
> ipv4_send_sk: success, fd = 4
> Opening /dev/urandom
> ....

And before anyone asks, selinux and firewalld are both disabled.
Also, just to repeat, it works fine when the daemon is started manually.

So I suspect something is screwy in either systemd or the unit file.

Urgh, why do things always occur to me _after_ pressing submit.

One last datapoint, if I kill -9 the fence_virtd process after having started it manually, the dameon fails to start using systemctl.


[10:23 AM] root@f19 ~ ☺ # systemctl status fence_virtd.service
fence_virtd.service - Fence-Virt system host daemon
   Loaded: loaded (/usr/lib/systemd/system/fence_virtd.service; enabled)
   Active: inactive (dead) since Thu 2013-08-01 10:23:16 EST; 6s ago
  Process: 9210 ExecStart=/usr/sbin/fence_virtd $FENCE_VIRTD_ARGS (code=exited, status=0/SUCCESS)
 Main PID: 9121 (code=exited, status=1/FAILURE)
   CGroup: name=systemd:/system/fence_virtd.service

Aug 01 10:23:16 f19.beekhof.net systemd[1]: Starting Fence-Virt system host daemon...
Aug 01 10:23:16 f19.beekhof.net systemd[1]: Started Fence-Virt system host daemon.

Repeated stop/start cycles do nothing, startup continues to fail.
Only a reboot allows fence_virtd to at least start via systemctl again.

Ok there are a couple of issues here:
1) On F19 fence-virtd-0.3.0-13.fc19.x86_64 as mentioned in c#1 the .service file
is broken as it should not require syslog.target. I see that this has been 
fixed on F20

2) On both F19 and F20 selinux prevents fence_virtd to connect to udp sockets:
Source Context                system_u:system_r:fenced_t:s0
Target Context                system_u:object_r:zented_port_t:s0
Target Objects                 [ udp_socket ]
Source                        fence_virtd
Source Path                   /usr/sbin/fence_virtd
Port                          1229
Host                          nas.int.rhx
Source RPM Packages           fence-virtd-0.3.0-13.fc19.x86_64
Target RPM Packages           
Policy RPM                    selinux-policy-3.12.1-74.11.fc19.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Permissive
Host Name                     nas.int.rhx
Platform                      Linux nas.int.rhx 3.11.7-200.fc19.x86_64 #1 SMP
                              Mon Nov 4 14:09:03 UTC 2013 x86_64 x86_64
Alert Count                   1
First Seen                    2013-11-21 18:19:59 CET
Last Seen                     2013-11-21 18:19:59 CET
Local ID                      053c0824-a843-4b0c-a134-cac96145313a

Raw Audit Messages
type=AVC msg=audit(1385054399.7:868): avc:  denied  { name_bind } for  pid=16207 comm="fence_virtd" src=1229 scontext=system_u:system_r:fenced_t:s0 tcontext=system_u:object_r:zented_port_t:s0 tclass=udp_socket


type=SYSCALL msg=audit(1385054399.7:868): arch=x86_64 syscall=bind success=yes exit=0 a0=8 a1=7fff165b8270 a2=10 a3=1 items=0 ppid=1 pid=16207 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 ses=4294967295 tty=(none) comm=fence_virtd exe=/usr/sbin/fence_virtd subj=system_u:system_r:fenced_t:s0 key=(null)

Hash: fence_virtd,fenced_t,zented_port_t,udp_socket,name_bind

Once we add that there is another selinux issue (which will make the server crash: fence_virtd[24122]: segfault at 10a2000 ip 0000003bd760f052 sp 00007fffd1a088e0 error 4 in libfreebl3.so[3bd7600000+76000]):
# grep fence_virtd /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp


Additional Information:
Source Context                system_u:system_r:fenced_t:s0
Target Context                system_u:object_r:zented_port_t:s0
Target Objects                 [ tcp_socket ]
Source                        fence_virtd
Source Path                   /usr/sbin/fence_virtd
Port                          1229
Host                          nas.int.rhx
Source RPM Packages           fence-virtd-0.3.0-13.fc19.x86_64
Target RPM Packages           
Policy RPM                    selinux-policy-3.12.1-74.11.fc19.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Permissive
Host Name                     nas.int.rhx
Platform                      Linux nas.int.rhx 3.11.7-200.fc19.x86_64 #1 SMP
                              Mon Nov 4 14:09:03 UTC 2013 x86_64 x86_64
Alert Count                   1
First Seen                    2013-11-21 18:35:13 CET
Last Seen                     2013-11-21 18:35:13 CET
Local ID                      a96d0c36-d9d3-4fc9-989d-31599945e209

Raw Audit Messages
type=AVC msg=audit(1385055313.386:873): avc:  denied  { name_connect } for  pid=24122 comm="fence_virtd" dest=1229 scontext=system_u:system_r:fenced_t:s0 tcontext=system_u:object_r:zented_port_t:s0 tclass=tcp_socket


type=SYSCALL msg=audit(1385055313.386:873): arch=x86_64 syscall=connect success=no exit=EINPROGRESS a0=9 a1=7fffd1a08a00 a2=10 a3=7fffd1a088b4 items=0 ppid=1 pid=24122 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 ses=4294967295 tty=(none) comm=fence_virtd exe=/usr/sbin/fence_virtd subj=system_u:system_r:fenced_t:s0 key=(null)

Hash: fence_virtd,fenced_t,zented_port_t,tcp_socket,name_connect

After that things work. Now I will file a selinux policy bug, but it'd be nice to get the start script fixed as well.

The syslog.target bug is still present in Fedora 20:

[pilcher@ian ~]$ sudo systemctl start fence_virtd.service
Failed to issue method call: Unit syslog.target failed to load: No such file or directory.

I am also getting this denial (after commenting out the Requires line in the unit file):

type=AVC msg=audit(1401919978.610:171): avc:  denied  { search } for  pid=4580 comm="fence_virtd" name=".config" dev="dm-0" ino=1441806 scontext=system_u:system_r:fenced_t:s0 tcontext=system_u:object_r:config_home_t:s0 tclass=dir


type=SYSCALL msg=audit(1401919978.610:171): arch=x86_64 syscall=openat success=no exit=EACCES a0=ffffffffffffff9c a1=ac9980 a2=90800 a3=0 items=0 ppid=1 pid=4580 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm=fence_virtd exe=/usr/sbin/fence_virtd subj=system_u:system_r:fenced_t:s0 key=(null)

I can't think of any good reason for fence_virtd to be reading /root/.config.

The daemon does start, and netstat shows that it is listening on 0.0.0.0:1229/udp.  I haven't tested actual functionality yet.

This message is a reminder that Fedora 20 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 20. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '20'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 20 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Fedora 20 changed to end-of-life (EOL) status on 2015-06-23. Fedora 20 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.