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
Improve this question
3
  • 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
    Commented Apr 24, 2013 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
    Commented Apr 25, 2013 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
    Commented Apr 26, 2013 at 13:24

1 Answer 1

Reset to default
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.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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