0

Another problem I found out in Arch Linux is if you're rebooting the Raspberry Pi with reboot and having named in the systemctl startup it will throw a long list of errors resulting in not working properly.

The last lines of /var/log/messages.log:

Jan  1 01:00:30 raspberrypi named[294]: error (network unreachable) resolving 'raspberrypi/A/IN': 192.5.5.241#53
Jan  1 01:00:30 raspberrypi named[294]: error (network unreachable) resolving 'raspberrypi/A/IN': 193.0.14.129#53
Jan  1 01:00:30 raspberrypi named[294]: error (network unreachable) resolving 'raspberrypi/A/IN': 199.7.83.42#53
Jan  1 01:00:30 raspberrypi named[294]: error (network unreachable) resolving 'raspberrypi/A/IN': 2001:500:2d::d#53
Jan  1 01:00:30 raspberrypi named[294]: error (network unreachable) resolving 'raspberrypi/A/IN': 2001:7fe::53#53
Jan  1 01:00:30 raspberrypi named[294]: error (network unreachable) resolving 'raspberrypi/A/IN': 2001:503:c27::2:30#53
Jan  1 01:00:30 raspberrypi named[294]: error (network unreachable) resolving 'raspberrypi/A/IN': 2001:503:ba3e::2:30#53
Jan  1 01:00:30 raspberrypi named[294]: error (network unreachable) resolving 'raspberrypi/A/IN': 2001:500:1::803f:235#53
Jan  1 01:00:30 raspberrypi named[294]: error (network unreachable) resolving 'raspberrypi/A/IN': 202.12.27.33#53
Jan  1 01:00:29 raspberrypi systemd[1]: Started Samba SMB/CIFS server.
Jan  1 01:00:30 raspberrypi dbus-daemon[122]: dbus[122]: [system] Activating via systemd: service name='org.freedesktop.Avahi' unit='dbus-org.freedesktop.Avahi.service'
Jan  1 01:00:30 raspberrypi dbus-daemon[122]: dbus[122]: [system] Activation via systemd failed for unit 'dbus-org.freedesktop.Avahi.service': Unit dbus-org.freedesktop.Avahi.service failed to load: No such file or directory. See system logs and 'systemctl status dbus-org.freedesktop.Avahi.service' for details.
Jan  1 01:00:31 raspberrypi dhcpcd[287]: eth0: leased 192.168.178.* for 3600 seconds
Jan  1 01:00:35 raspberrypi named[294]: checkhints: unable to get root NS rrset from cache: not found
Jan  1 01:00:41 raspberrypi systemd[1]: Started OpenNTP Daemon.
Jan  1 01:00:41 raspberrypi systemd[1]: Starting Multi-User System.
Jan  1 01:00:41 raspberrypi systemd[1]: Reached target Multi-User System.
Jan  1 01:00:41 raspberrypi systemd[1]: Starting Graphical Interface.
Jan  1 01:00:41 raspberrypi systemd[1]: Reached target Graphical Interface.
Jan  1 01:00:41 raspberrypi systemd[1]: Startup finished in 2.839s (kernel) + 38.816s (userspace) = 41.656s.

I can see that the named server is starting before network is initialized so how can I get the named server be started after network has been initialized?

Starting it later over ssh with systemctl restart named is not an option. This may cause problems in systems where the Raspberry Pi is used as default nameserver like an intranet.

/usr/lib/systemd/system/named.service:

[Unit]
Description=Internet domain name server
After=network.target

[Service]
ExecStart=/usr/sbin/named -f -u named
ExecReload=/usr/sbin/rndc reload
ExecStop=/usr/sbin/rndc stop

[Install]
WantedBy=multi-user.target
  • My pi has problems with the network on arch as well. Netcfg always fails on startup, but if I run it manually later, it works. I only say this because I sympathize with your plight. Perhaps you could write a startup script that has a delay built into it and later brings up the server? – krs013 Apr 24 '13 at 13:55
  • do you know how I could delay the start up in the .service-file without using a separate start up script? I don't really find any information about how to start a service delayed. @krs013 – AliveDevil Apr 25 '13 at 19:56
  • I'm afraid I don't. I'm just beginning to learn arch myself. But maybe if your could edit the script that starts the daemon (if it is a script and not just a binary file, but you could make a script for it in its place, I guess) you could add something like a sleep statement there for a minute or however long it takes. However, if it's a universal problem someone should really figure out how to fix it in an update. – krs013 Apr 26 '13 at 13:24
0

Okay, it's not really an answer but a workaround. I knew of another name server dnsmasq which works fine now.

What I did: pacman -S dnsmasq and pacman -R bind. Replace bind with dnsmasq. Edited the /etc/dnsmasq.conf to fit my requirements and enabled it via systemctl enable dnsmasq. Rebooted and everything works fine. For everyone who does not want to want to edit the bind-files this is a good and fast alternative.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.