[systemd-devel] systemd-timesyncd with read-only root filesystem

[André Hartmann]

Hi Martin,

Am 01.12.2016 um 10:20 schrieb Martin Pitt:
> Hello André,
>
> André Hartmann [2016-12-01  9:50 +0100]:
>> So I naively created the following link structure (which works):
>>
>> /etc/systemd/system/sysinit.target.wants/systemd-timesyncd.service ->
>> /mnt/writeable/systemd-timesyncd ->
>> /lib/systemd/system/systemd-timesyncd.service
>>
>> But if I remove /mnt/writeable/systemd-timesyncd and reboot,
>> the command 'timedatectl status' still reports enabled, which is unexpected.
>
> This is because systemd only really looks at the foo.wants/bar.service
> symlink itself -- it's actually okay for that to point into
> nothingness. I think this is mostly due to the fact that the actual
> units can be in /etc, /usr, or /run, and even move between those.

The funny thing is, that foo.wants/bar.service can also point to 
../baz.service, i.e. the name of the symlink does not matter. Somehow 
systemd seems to recognize when such a link is created and "cache" this 
result somewhere.

In other words: once this symlink is valid, you cannot invalidate it by
make it a dangling symlink, you have to remove it. Can somebody confirm 
this observation?

And ... any other ideas how to enable/disable timesyncd?

I'd like to keep as much as possible read-only, including the 
configurations.

Thanks, Andre

>
> For example, you might have
>
>   /usr/lib/systemd/system/foo.service
>   /usr/lib/systemd/system/multi-user.target.wants/foo.service → ../foo.service
>
> and then override this with
>
>   /etc/systemd/system/foo.service
>
> Then multi-user.target will still use the unit from /etc, *not* the
> one from  /usr, even though that's where the symlink points to. In
> this case this is pretty obviously the correct behaviour; in your case
> it's admittedly confusing.
>
> I'm not entirely sure if dangling symlinks should be counted as
> "enabled", but this should least explain your observation.
>
> Martin
>