Description of problem:
Issuing the command "service rbldnsd start" results in systemctl being called, which in turn calls systemd-tty-ask-password-agent. That process hangs for a few minutes before exiting and reporting that the service would not start. The service does start, though.
Version-Release number of selected component (if applicable):
Fedora 16 (32-bit or 64-bit; tried both)
systemd component (specifically systemd-37-17)
Installed 64-bit Fedora 16, install rbldnsd and bind, type "service rbldnsd start". Sit and wait ;-)
Steps to Reproduce:
1. Install Fedora 16 (x86_64 or i386)
2. Yum install rbldnsd bind
3. Yum update
4. Add this to the /etc/sysconfig/rbldnsd:
RBLDNSD="- -u named:named -r/var/lib/rbldnsd -q -b127.0.0.1/5300 -4 bl.example.net:ip4set:list"
5. Create /var/lib/rbldnsd/list with this content
$SOA 86400 ns1.example.net hostmaster.example.net 1332843007 10800 3600 60
$NS 86400 ns1.example.net
# Addresses may be IP addresses or may be in the form 127.0.0.0/24 (CIDR)
:127.0.0.2:Blocked - $
6. Type "service rbldnsd start"
The "service" command hangs (actually on "systemd-tty-ask-password-agent --watch"), failing after a few minutes. The daemon does actually start.
It should start immediately and without any errors.
These systemd packages are installed:
(32-bit | 64-bit)
A workaround to the problem is to insert this line into /etc/init.d/rbldnsd right before it sources "functions":
That bypasses systemctl entirely.
If these packages are installed, I do not see this problem:
I reproduced the hang, but I don't see what systemd-tty-ask-password-agent has to do with it. The real problem seems to be that the initscript confuses systemd with its pidfile header:
# pidfile: /var/run/rbldnsd*.pid
systemd is waiting for the pidfile to appear before considering the service started. Wildcards are not supported. There cannot be more than one pidfile per service. See if it works better with this line removed from the initscript.
rbldnsd is designed to run with multiple instances, hence the references to multiple pidfiles in the initscript comment. I've thought about converting the initscript to multi-instance systemd units similar to openvpn but it's non-trivial, at least if I try to maintain compatibility with the existing configuration scheme. I think I may have to break that compatibility to get a clean approach with systemd, but I've not been able to spend enough time on it to be sure just yet.
Given that the pidfile: line is ignored by the sysv service infrastructure, you could just remove it and it should help.
Created attachment 573452 [details]
Native systemd unit for rbldnsd
This systemd unit can be used as a bases for a standalone and template with minor adjustments..
Quick and dirty test setup and direction should be something like this...
copy the attached unit into /etc/systemd/system directory and run
# systemctl daemon-reload
# cat <<EOF > /var/lib/rbldnsd/list
127.0.0.0/8 It works!.
# systemctl start rbldnsd.service
# host -t TXT 18.104.22.168.localhost 127.0.0.2
If it's working you will see "It Works!" ...
Created attachment 573461 [details]
Native systemd template unit for rbldnsd
Sample template unit which bases itself on domain.
for example for localhost copy the unit to /etc/systemd/system directory then copy the /var/lib/rbldnsd/list file to /var/lib/rbldnsd/localhost-list then run systemctl daemon reload && systemctl start rbldnsd...
To enable template units users will have to do as always until well [Install] gets supported for templates, run
# ln -s /lib/systemd/system/rbldnsd@.service /etc/systemd/system/multi-user.target.wants/rbldnsd
rbldnsd-0.996b-6.fc17 has been submitted as an update for Fedora 17.
rbldnsd-0.996b-6.fc16 has been submitted as an update for Fedora 16.
rbldnsd-0.996b-6.fc15 has been submitted as an update for Fedora 15.
rbldnsd-0.996b-6.el6 has been submitted as an update for Fedora EPEL 6.
rbldnsd-0.996b-6.el5 has been submitted as an update for Fedora EPEL 5.
OK, I've done native systemd configuration for rbldnsd in F-17 and Rawhide now. I've decided against the template approach because the infinite variation in parameters than can be used doesn't lend itself to that approach. Instead, I've created a wrapper script that parses /etc/sysconfig/rbldnsd in exactly the same way that the sysv initscript did and can create and manage multiple instances at the same time whilst still leaving it possible to control individual instances using systemctl as usual. The README.systemd that I've included describes how to use it:
Using rbldnsd with systemd
The traditional SysV initscript shipped with rbldnsd supports using
multiple instances with arbitrary command lines. This is difficult
to achieve with systemd so a wrapper script, systemctl-rbldnsd, has
been provided to assist with the creation and use of native systemd
unit files for each required instance, using exactly the same
configuration in /etc/sysconfig/rbldnsd as the SysV initscript used.
Having edited /etc/sysconfig/rbldnsd to specify the rbldnsd
instance(s) required, individual unit files for each instance can be
This creates unit files /etc/systemd/system/rbldnsd-<instancename>.service
for each required instance. These units can then be manipulated
individually using /bin/systemctl as usual, or all at once by using
other systemctl-rbldnsd commands:
This enables all configured rbldnsd instances to start at boot time
(equivalent of chkconfig rbldnsd on).
This disables all configured rbldnsd instances from starting at boot time
(equivalent of chkconfig rbldnsd off).
This starts all configured rbldnsd instances immediately
(equivalent of service rbldnsd start).
This stops all configured rbldnsd instances
(equivalent of service rbldnsd stop).
This reloads all configured rbldnsd instances
(equivalent of service rbldnsd reload).
This restarts all configured rbldnsd instances
(equivalent of service rbldnsd restart).
These restart all configured rbldnsd instances immediately, if they are
already running (equivalent of service rbldnsd condrestart).
This shows status of all configured rbldnsd instances
(equivalent of service rbldnsd status).
When editing /etc/sysconfig/rbldnsd to specify rbldnsd instance options,
bear in mind:
* systemd prefers the daemons it controls not to fork, so the unit files
created by systemctl-rbldnsd start rbldnsd with the "-n" option to prevent
it from forking; this also means that systemd knows the PIDs of all
instances itself, so there is no need to specify any forking/pidfile related
options in /etc/sysconfig/rbldnsd
* if you want just a single instance of rbldnsd and use the traditional "-"
identifier for it, systemctl-rbldnsd will create a unit file
/etc/systemd/system/rbldnsd-single.service, i.e. the instance name will be
set to "single"
Not sure if I read that right, but please do not create _any_ tool in the
Things should not start with systemctl-* or systemd-*. Please name it
rbldnsctl-* or whatever else fits your need.
(In reply to comment #12)
> Not sure if I read that right, but please do not create _any_ tool in the
> systemd namespace.
> Things should not start with systemctl-* or systemd-*. Please name it
> rbldnsctl-* or whatever else fits your need.
OK, I've renamed the systemctl-rbldnsd script to rbldnsctl.
* should fix your issue,
* was pushed to the Fedora EPEL 6 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=epel-testing rbldnsd-0.996b-6.el6'
as soon as you are able to.
Please go to the following url:
then log in and leave karma (feedback).
rbldnsd-0.996b-8.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report.
rbldnsd-0.996b-6.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report.
rbldnsd-0.996b-6.fc15 has been pushed to the Fedora 15 stable repository. If problems still persist, please make note of it in this bug report.
rbldnsd-0.996b-6.el5 has been pushed to the Fedora EPEL 5 stable repository. If problems still persist, please make note of it in this bug report.
rbldnsd-0.996b-6.el6 has been pushed to the Fedora EPEL 6 stable repository. If problems still persist, please make note of it in this bug report.