Description of problem: When there is a syntax error in radvd.conf and the "/etc/init.d/radvd reload" command is executed, radvd silently dies, and the initscript reports "OK". I think either the initscript or radvd should report the problem (for example, Apache or Nagios both report the problem when reloading configuration, and the old version of configuration remains active). Version-Release number of selected component (if applicable): radvd-1.6-2.fc14.x86_64 How reproducible: 100 % Steps to Reproduce: 1. Install F14, activate radvd with the default config 2. make a syntax error in /etc/radvd.conf (e.g. delete a semicolon after the }) 3. run /etc/init.d/radvd reload 4. run ps ax|grep radvd Actual results: radvd is not running, even though the init script reports "OK". Expected results: The config file error should be reported, and radvd should keep the old configuration.
Actually, the problem is even worse: radvd dies on reload even if the config file is OK. Moreover, it is probably not daemonized correctly. After starting it, I can see two instances, one of them still connected to a tty. One or both of these instances die when /etc/init.d/radvd reload is executed: ------------------------------------------------------------------------ # ps ax|grep -v grep | grep radvd # /etc/init.d/radvd start Starting radvd: [ OK ] # ps ax|grep -v grep | grep radvd 2533 pts/53 S 0:00 radvd -u radvd 2534 ? Ss 0:00 radvd -u radvd # /etc/init.d/radvd reload Reloading radvd: [ OK ] # ps ax|grep -v grep | grep radvd # ------------------------------------------------------------------------ # /etc/init.d/radvd start Starting radvd: [ OK ] # ps ax|grep -v grep | grep radvd 2568 pts/53 S 0:00 radvd -u radvd 2569 ? Ss 0:00 radvd -u radvd # /etc/init.d/radvd reload Reloading radvd: [ OK ] # ps ax|grep -v grep | grep radvd 2569 ? Ss 0:00 radvd -u radvd # /etc/init.d/radvd reload Reloading radvd: [ OK ] # ps ax|grep -v grep | grep radvd # ------------------------------------------------------------------------
Hi, thanks for reporting. There really are two issues. 1. radvd reloading is invoked by SIGHUP. There are two processes when radvd is daemonized. SIGHUP is not sent to right process. Fix is easy & prepared. 2. Status [OK] is printed based on return code of sending SIGHUP. This occurres outside of radvd package. I'm thinking about clear fix.
Package radvd-1.7-1.fc14: * should fix your issue, * was pushed to the Fedora 14 updates-testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing radvd-1.7-1.fc14' as soon as you are able to, then reboot. Please go to the following url: https://admin.fedoraproject.org/updates/radvd-1.7-1.fc14 then log in and leave karma (feedback).
radvd-1.7-1.fc14 has been pushed to the Fedora 14 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update radvd'. You can provide feedback for this update here: https://admin.fedoraproject.org/updates/radvd-1.7-1.fc14
Works for me, thanks! A minor problem with one of the two processes still being attached to the tty after startup still persists: # /etc/init.d/radvd restart Stopping radvd: [ OK ] Starting radvd: [ OK ] # ps ax|grep radvd 8542 pts/80 S 0:00 radvd -u radvd ^^^^^^ 8543 ? Ss 0:00 radvd -u radvd Should I open a new bz entry for it, or do you consider it to be really minor problem which you will ignore for now?
(In reply to comment #5) > A minor problem with one of the two processes still being attached to the tty > after startup still persists: > # ps ax|grep radvd > 8542 pts/80 S 0:00 radvd -u radvd > ^^^^^^ > 8543 ? Ss 0:00 radvd -u radvd > > Should I open a new bz entry for it, or do you consider it to be really minor > problem which you will ignore for now? I'm not able to reproduce this issue.
I have tried to reproduce it on a different machine (a clean F14 install), and I the problem was not present there. Comparing the two systems I have discovered that the problem is somewhere in SELinux: I can reproduce it only when SELinux is in Permissive mode: # setenforce 1 # /etc/init.d/radvd restart Stopping radvd: [ OK ] Starting radvd: [ OK ] # ps ax|grep radvd 12134 ? S 0:00 radvd -u radvd 12135 ? Ss 0:00 radvd -u radvd 12140 pts/82 S+ 0:00 grep --color=auto radvd # setenforce 0 # /etc/init.d/radvd restart Stopping radvd: [ OK ] Starting radvd: [ OK ] # ps ax|grep radvd 12177 pts/82 S 0:00 radvd -u radvd 12178 ? Ss 0:00 radvd -u radvd 12184 pts/82 S+ 0:00 grep --color=auto radvd
Jan, could you try to execute radvd init script using a service script # service radvd restart
I've tested it during my investigation. There is no difference in described behaviour between using service and direct execution of init script.
Yes, I can confirm it - the behaviour is the same for /sbin/service radvd restart and /etc/init.d/radvd restart
Ok, and I guess you are not seeing any avc msgs? Right? Try to run # semodule -DB # /sbin/service radvd restart # ausearch -m avc -ts recent |grep radvd
The above gives the following in permissive mode: type=SYSCALL msg=audit(1299225289.507:21872): arch=c000003e syscall=59 success=yes exit=0 a0=1db8d90 a1=1db9120 a2=1db9410 a3=1 items=0 ppid=2884 pid=2885 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts89 ses=3535 comm="radvd" exe="/usr/sbin/radvd" subj=unconfined_u:system_r:radvd_t:s0 key=(null) type=AVC msg=audit(1299225289.507:21872): avc: denied { read write } for pid=2885 comm="radvd" name="89" dev=devpts ino=92 scontext=unconfined_u:system_r:radvd_t:s0 tcontext=unconfined_u:object_r:user_devpts_t:s0 tclass=chr_file and the following in the enforcing mode: type=SYSCALL msg=audit(1299225618.232:21884): arch=c000003e syscall=59 success=yes exit=0 a0=c0f880 a1=c0e200 a2=c0dbf0 a3=1 items=0 ppid=3085 pid=3086 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts89 ses=3535 comm="radvd" exe="/usr/sbin/radvd" subj=unconfined_u:system_r:radvd_t:s0 key=(null) type=AVC msg=audit(1299225618.232:21884): avc: denied { read write } for pid=3086 comm="radvd" name="89" dev=devpts ino=92 scontext=unconfined_u:system_r:radvd_t:s0 tcontext=unconfined_u:object_r:user_devpts_t:s0 tclass=chr_file type=SYSCALL msg=audit(1299226042.891:21902): arch=c000003e syscall=59 success=yes exit=0 a0=d73d90 a1=d74120 a2=d74410 a3=1 items=0 ppid=3308 pid=3309 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=3535 comm="radvd" exe="/usr/sbin/radvd" subj=unconfined_u:system_r:radvd_t:s0 key=(null) type=AVC msg=audit(1299226042.891:21902): avc: denied { read write } for pid=3309 comm="radvd" path="/dev/pts/89" dev=devpts ino=92 scontext=unconfined_u:system_r:radvd_t:s0 tcontext=unconfined_u:object_r:user_devpts_t:s0 tclass=chr_file type=AVC msg=audit(1299226042.891:21902): avc: denied { read write } for pid=3309 comm="radvd" path="/dev/pts/89" dev=devpts ino=92 scontext=unconfined_u:system_r:radvd_t:s0 tcontext=unconfined_u:object_r:user_devpts_t:s0 tclass=chr_file type=AVC msg=audit(1299226042.891:21902): avc: denied { read write } for pid=3309 comm="radvd" path="/dev/pts/89" dev=devpts ino=92 scontext=unconfined_u:system_r:radvd_t:s0 tcontext=unconfined_u:object_r:user_devpts_t:s0 tclass=chr_file type=AVC msg=audit(1299226042.891:21902): avc: denied { read write } for pid=3309 comm="radvd" name="89" dev=devpts ino=92 scontext=unconfined_u:system_r:radvd_t:s0 tcontext=unconfined_u:object_r:user_devpts_t:s0 tclass=chr_file
Mirek, if it's a bug in selinux I'll propose to create new one to preserve content of this bug clear of other issues.
radvd-1.7-1.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report.