named does't start when using systemctl

Question

I am having trouble getting named to start using systemd on the Fedora 18 Raspberry Pi spin. It starts, then a few moments later there is a timeout and it fails. If I run the commands in named.service by hand, named starts just fine. I don't know what the timeout is that systemctl is looking for or where it is being invoked. I have read the man pages for systemctl, systemd and others and I will continue to research this, but if anyone has any pointers, that would be great.

systemctl status named.service output:

named.service - Berkeley Internet Name Domain (DNS)
          Loaded: loaded (/usr/lib/systemd/system/named.service; disabled)
          Active: failed (Result: timeout) since Tue 2013-01-29 14:36:41 EST; 35min ago
         Process: 4189 ExecStart=/usr/sbin/named -u named $OPTIONS (code=exited, status=0/SUCCESS)
         Process: 4186 ExecStartPre=/usr/sbin/named-checkconf -z /etc/named.conf (code=exited, status=0/SUCCESS)
         Process: 4183 ExecStartPre=/usr/libexec/generate-rndc-key.sh (code=exited, status=0/SUCCESS)

Jan 29 14:35:12 raspi.example.com named[4191]: all zones loaded
Jan 29 14:35:12 raspi.example.com systemd[1]: PID file /run/named/named.pid not readable (yet?) after start.
Jan 29 14:35:12 raspi.example.com named[4191]: running
Jan 29 14:36:41 raspi.example.com systemd[1]: named.service operation timed out. Terminating.
Jan 29 14:36:41 raspi.example.com named[4191]: shutting down
Jan 29 14:36:41 raspi.example.com named[4191]: stopping command channel on 127.0.0.1#953
Jan 29 14:36:41 raspi.example.com named[4191]: no longer listening on 127.0.0.1#53
Jan 29 14:36:41 raspi.example.com named[4191]: exiting
Jan 29 14:36:41 raspi.example.com systemd[1]: Failed to start Berkeley Internet Name Domain (DNS).
Jan 29 14:36:41 raspi.example.com systemd[1]: Unit named.service entered failed state  

The named.service file

[Unit]
Description=Berkeley Internet Name Domain (DNS)
Wants=nss-lookup.target
Before=nss-lookup.target
After=network.target

[Service]
Type=forking
EnvironmentFile=-/etc/sysconfig/named
Environment=KRB5_KTNAME=/etc/named.keytab
PIDFile=/run/named/named.pid
ExecStartPre=/usr/libexec/generate-rndc-key.sh
ExecStartPre=/usr/sbin/named-checkconf -z /etc/named.conf
ExecStart=/usr/sbin/named -u named $OPTIONS
ExecReload=/bin/sh -c '/usr/sbin/rndc reload > /dev/null 2>&1 || /bin/kill -HUP $MAINPID'
ExecStop=/bin/sh -c '/usr/sbin/rndc stop > /dev/null 2>&1 || /bin/kill -TERM $MAINPID'
PrivateTmp=true
[Install]
WantedBy=multi-user.target

Solution 1

Answered.

This was the line:

PID file /run/named/named.pid not readable (yet?) after start.

The (yet?) threw me. I thought the message was being thrown because it was trying to read the PID file before it was written out by named and since I didn't see an error after that, I figured it eventually read it successfully. Silly me for reading English. In fact, named writes the pid to /var/run/named/named.pid, which was not being read by systemctl (or systemd), ever.

Changed the PIDFile in named.service and it starts. Joy.

Solution 2

systemctl enable named 

is required before

systemctl start named

Comments

[vonbrand]

Great, thanks for the answer. Had me stumped.

[CameronNemo]

/var/run should be a symlink to /run...

[mike fratto]

Oh, Linux vagaries and one of the many annoying things about Linux distro and package development I loathe. /run is redundant when you have /var/run, which is where should be where variable things like pid files should go.