Error with NTP daemon chroot [SOLVED]

ThatOneGenie · 2024-06-13 23:57:54

I am getting a recurrent boot-load error after having set up ntp to run in a jailed chroot as described in NTPD# running in a chroot
After following all of the described steps, including verifying that the output of the drift file links to /var/lib/ntp, I am experiencing a weird boot that I believe I may have solved but need to confirm before I destroy anything.

For reference, this is how my /etc/fstab is configured:

#ntpd chroot mounts
/etc/resolv.conf  /var/lib/ntp/etc/resolv.conf none defaults,bind 0 0
/etc/services     /var/lib/ntp/etc/services none defaults,bind 0 0
/lib              /var/lib/ntp/lib none defaults,bind 0 0
/usr/lib          /var/lib/ntp/usr/lib none defaults,bind 0 0
/proc             /var/lib/ntp/proc none defaults,bind 0 0

Boot fails with the following journalctl log

Jun 13 18:06:29 DESKTOP002 mount[454]: mount: /var/lib/ntp/etc/resolv.conf: special device /etc/resolv.conf does not exist.
Jun 13 18:06:29 DESKTOP002 mount[454]:        dmesg(1) may have more information after failed mount system call.
Jun 13 18:06:29 DESKTOP002 systemd[1]: Finished Create Static Device Nodes in /dev gracefully.

un 13 18:06:29 DESKTOP002 systemd[1]: var-lib-ntp-etc-resolv.conf.mount: Mount process exited, code=exited, status=32/n/a
░░ Subject: Unit process exited
░░ Defined-By: systemd
░░ Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
░░ 
░░ An n/a= process belonging to unit var-lib-ntp-etc-resolv.conf.mount has exited.
░░ 
░░ The process' exit code is 'exited' and its exit status is 32.
Jun 13 18:06:29 DESKTOP002 systemd[1]: var-lib-ntp-etc-resolv.conf.mount: Failed with result 'exit-code'.
░░ Subject: Unit failed
░░ Defined-By: systemd
░░ Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
░░ 
░░ The unit var-lib-ntp-etc-resolv.conf.mount has entered the 'failed' state with result 'exit-code'.
Jun 13 18:06:29 DESKTOP002 systemd[1]: Failed to mount /var/lib/ntp/etc/resolv.conf.
░░ Subject: A start job for unit var-lib-ntp-etc-resolv.conf.mount has failed
░░ Defined-By: systemd
░░ Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
░░ 
░░ A start job for unit var-lib-ntp-etc-resolv.conf.mount has finished with a failure.
░░ 
░░ The job identifier is 41 and the job result is failed.
Jun 13 18:06:29 DESKTOP002 systemd[1]: Dependency failed for Local File Systems.
░░ Subject: A start job for unit local-fs.target has failed
░░ Defined-By: systemd
░░ Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
░░ 
░░ A start job for unit local-fs.target has finished with a failure.
░░ 
░░ The job identifier is 34 and the job result is dependency.
Jun 13 18:06:29 DESKTOP002 systemd[1]: local-fs.target: Job local-fs.target/start failed with result 'dependency'.
Jun 13 18:06:29 DESKTOP002 systemd[1]: local-fs.target: Triggering OnFailure= dependencies.

I was unable to figure out how exactly to utilize dmesg to find proper logs for the failed mount. The best I could find were dmesg logs for systemd-journald which I was not able to understand.

/etc/resolv.conf does exist as a file, with the following permissions

lrwxrwxrwx 1 root root 37 Jun  7 04:58 /etc/resolv.conf -> /run/systemd/resolve/stub-resolv.conf

However, I believe I have found the issue, which is that /var/lib/ntp/etc/resolv.conf does NOT have root permissions.

ls -l resolv.conf
-rw-r--r-- 0 systemd-resolve systemd-resolve 920 Jun 13 18:06 resolv.conf

Is this a correct assumption, and if so, does that not defeat the purpose of running the ntp daemon in a chroot environment if the binded directories have root access themselves? Or am I mistaken and the issue is something completely different.

Thanks in advance for any help.

Last edited by ThatOneGenie (2024-06-14 23:38:15)

seth · 2024-06-14 06:44:10

Have you tried binding the target of the symlink?

ThatOneGenie · 2024-06-14 07:43:50

No, however I don't think that is possible/a good idea.

# This is /run/systemd/resolve/stub-resolv.conf managed by man:systemd-resolved(8).
# Do not edit.
#
# This file might be symlinked as /etc/resolv.conf. If you're looking at
# /etc/resolv.conf and seeing this text, you have followed the symlink.
# Third party programs should typically not access this file directly, but only
# through the symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a
# different way, replace this symlink by a static file or a different symlink.

Moreover, the documentation for systemd-resolved says not to target that file directly and only use the symlink.
This leaves me further confused because it seems as though the permissions of the symlinked file are correct then. So now I am truly unsure of what the issue is.

Lone_Wolf · 2024-06-14 09:25:49

ntpd is part of ntp & openntp .

Both target many OSes and are unlikely to work with the linux-specific systemd services.

The errrors have to do with resolv.conf which makes it very likely systemd-resolved is the culprit.

Can you switch to another dns resolver ?

seth · 2024-06-14 15:54:38

Jun 13 18:06:29 DESKTOP002 mount[454]: mount: /var/lib/ntp/etc/resolv.conf: special device /etc/resolv.conf does not exist.
Jun 13 18:06:29 DESKTOP002 mount[454]:        dmesg(1) may have more information after failed mount system call.
Jun 13 18:06:29 DESKTOP002 systemd[1]: Finished Create Static Device Nodes in /dev gracefully.

You're trying to bind /etc/resolv.conf at a point where that file doesn't exist.
It'll become a symlink to /run/systemd/resolve/stub-resolv.conf - later.

1. /run/systemd/resolve/stub-resolv.conf exists but /etc/resolv.conf doesn't yet link there
1a. bind /run/systemd/resolve/stub-resolv.conf instead*
1b. create the symlink yourself
1c. wait until the symlink becomes available
1d. don't use systemd-resolved

2. /run/systemd/resolve/stub-resolv.conf itself doesn't yet exist
2a. wait until the symlink becomes available
2b. don't use systemd-resolved

ThatOneGenie · 2024-06-14 21:20:40

seth wrote:

You're trying to bind /etc/resolv.conf at a point where that file doesn't exist.
It'll become a symlink to /run/systemd/resolve/stub-resolv.conf - later.

I see, that makes total sense. The symlink between the systemd-resolv file and /etc/resolv.conf isn't created until later in the boot loading sequence, so therefore the instruction in /etc/fstab is pointing to nowhere. I think another DNS resolver/figuring out a way to have the bind-mount occur on internet connection might be the best route to take. I know for a fact that the symlink is created once a network connection is established, so if I can manage to pause the ntp daemon from running until a connection is established, and then also configuring the chroot to be bound after system boot, then I could maybe get it to work. However, I feel like that is so involved and defeats the entire purpose of using a chroot as it is just introducing lots of potential vulnerabilities, and seems like it would be far beyond my capabilities to actually implement.

LoneWolf wrote:

Can you switch to another dns resolver ?

I think that is what I will investigate, but that does seem above my pay grade.

Either way, I feel like the original wiki post should be updated as it seems to be non-functional. Unless there is some other issue going on, which is entirely possible.

Lone_Wolf · 2024-06-14 21:39:49

Most people that use systemd-resolved also use systemd-networkd and systemd-timesyncd .

Those that use ntp or openntp often don't use systemd-networkd / systemd-resolved but alternatives like dhcpcd / dhvclient / bind etc .
the systemd-* stuff tends to be coupled so closely it's very hard to get them to work with non-systemd alternatives.

seth · 2024-06-14 21:43:32

Either way, I feel like the original wiki post should be updated as it seems to be non-functional. Unless there is some other issue going on, which is entirely possible.

The etc/resolv.conf symlink is a systemd-resolved pecularity.

The stuff you posted in #3 is irrelevant to your situation - if /run/systemd/resolve/stub-resolv.conf already exists, you can bind it.
Otherwise you could tag it "noauto" and only establish the bind-mount once your network is up, the network managing daeamons typically have some hook system to trigger scripts when "something has happened" for this purpose. In that case you probably also don't want to automatically start the ntp daemon but wait for the network.

ThatOneGenie · 2024-06-14 23:37:45

I think I understand now. /etc/resolv.conf is actually just /run/systemd/resolve/stub-resolv.conf but in a different place. I think I was mis-understanding how symlinks function.

# realpath /etc/resolv.conf
/run/systemd/resolve/stub-resolv.conf

The only way for me to actually properly mount the necessary file would be to bind to the target systemd file, which is advised against. I've decided to just get rid of ntp and use the built-in ntp from timedatectl as I think that will be much easier to use. After looking further, it seems like NetworkManager might also be messing with this as it updates the /etc/resolv.conf file itself which changes the way the file interacts with systemd. Plus, the AUR script to load the ntp daemon on NetworkManager connection hasn't been updated since 2022, and the upstream URL doesn't link to the correct site anymore.

LoneWolf wrote:

Most people that use systemd-resolved also use systemd-networkd and systemd-timesyncd .

That's where I'm at. I'm just going to go ahead and get rid of ntp and use systemd-timesyncd.
The only thing is I feel like some of the wiki articles regarding NTP could be a bit more clear on that distinction, and at the very least it seems like the provided instructions for jailing the NTP daemon in a chroot no longer function properly.

seth · 2024-06-15 06:40:30

which is advised against

Not for this purpose, you're misinterpreting the comment there.

messing with this as it updates the /etc/resolv.conf file itself which changes the way the file interacts with systemd

No, resolved's DNS/resolv handling is completely whacko - https://wiki.archlinux.org/title/Systemd-resolved#DNS
And for more implicit whackishness, NM also uses the filetype to determine the resolver implementation, https://wiki.archlinux.org/title/Networ … management

AUR script to load the ntp daemon on NetworkManager connection hasn't been updated since 2022

You don't need an AUR for this and I've scripts that have not been updated in over a decade.

get rid of ntp and use systemd-timesyncd

nb. that ntpd and timesyncd have different scopes and running ntpd in a chroot is mostly interesting when providing your own NTP server (in a hostile context) which timesyncd doesn't provide. If you just wanted to use ntpd to sync your time you don't have to do/worry about any of this itfp.

Arch Linux

#1 2024-06-13 23:57:54

Error with NTP daemon chroot [SOLVED]

#2 2024-06-14 06:44:10

Re: Error with NTP daemon chroot [SOLVED]

#3 2024-06-14 07:43:50

Re: Error with NTP daemon chroot [SOLVED]

#4 2024-06-14 09:25:49

Re: Error with NTP daemon chroot [SOLVED]

#5 2024-06-14 15:54:38

Re: Error with NTP daemon chroot [SOLVED]

#6 2024-06-14 21:20:40

Re: Error with NTP daemon chroot [SOLVED]

#7 2024-06-14 21:39:49

Re: Error with NTP daemon chroot [SOLVED]

#8 2024-06-14 21:43:32

Re: Error with NTP daemon chroot [SOLVED]

#9 2024-06-14 23:37:45

Re: Error with NTP daemon chroot [SOLVED]

#10 2024-06-15 06:40:30

Re: Error with NTP daemon chroot [SOLVED]

Board footer