Re: systemd and 'Stale file handle' errors?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



Jonathan Billings wrote:
> So, the chronyd systemd unit looks like this:
>
>     # /usr/lib/systemd/system/chronyd.service
>     [Unit]
>     Description=NTP client/server
>     Documentation=man:chronyd(8) man:chrony.conf(5)
>     After=ntpdate.service sntp.service ntpd.service
>     Conflicts=ntpd.service systemd-timesyncd.service
>     ConditionCapability=CAP_SYS_TIME
>
>     [Service]
>     Type=forking
>     PIDFile=/var/run/chrony/chronyd.pid
>     EnvironmentFile=-/etc/sysconfig/chronyd
>     ExecStart=/usr/sbin/chronyd $OPTIONS
>     ExecStartPost=/usr/libexec/chrony-helper update-daemon
>     PrivateTmp=yes
>     ProtectHome=yes
>     ProtectSystem=full
>
>     [Install]
>     WantedBy=multi-user.target
>
> So, you'll notice there are "ProtectHome=yes" and "ProtectSystem=yes"
> settings in the Service section.  This sets up a private namespace for
> the systemd unit so /home, /root and /run/user are made inaccessible
> and empty (ProtectHome), and /usr, /boot and /etc are read-only
> (ProtectSystem).  It does this to reduce the ability of a malicious
> NTP server attacking the system through bogus NTP traffic (which is a
> real thing that can happen).  Many systemd services limit their
> processes this way.
>
> I suspect that is why you're seeing stale file handle errors, the
> kernel can't set up the namespace for directories that are now stale
> on the system.
>
> You can probably just do a lazy unmount (umount -l) to make them go
> away until you reboot.  You can also disable the namespaced
> directories by doing a 'systemctl edit chronyd.service' and setting
> the options to 'off', but you'll be reducing the security of your
> system.

Thanks - that all makes sense - unfortunately 'umount -l' didn't work :-(

I've actually now rebooted the box - but if something like this happens again, maybe I could use a drop-in snippet in /run/systemd/system/ to turn the options off - which would then only last until the next reboot ?

Thanks

James Pearson
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
https://lists.centos.org/mailman/listinfo/centos



[Index of Archives]     [CentOS]     [CentOS Announce]     [CentOS Development]     [CentOS ARM Devel]     [CentOS Docs]     [CentOS Virtualization]     [Carrier Grade Linux]     [Linux Media]     [Asterisk]     [DCCP]     [Netdev]     [Xorg]     [Linux USB]


  Powered by Linux