Writable-paths: why `/etc/systemd{,/system}` is `synced` in core (16), but `persistent writable` in core18+?

ratchanan.sr · July 14, 2022, 8:38pm

So, here at UBports we’re still using system-image with read-only rootfs - much like Ubuntu Core. As we’re transitioning our base to Ubuntu 20.04, we’re also (finally) transitioning to systemd, and that means adding more paths to writable-paths, including /etc/systemd.

Upon studying, I’ve found that the core snap (16.04 one) defines the directory as synced (i.e. new files will be copied on every boot)

github.com

snapcore/core/blob/master/extra-files/etc/system-image/writable-paths#L61-L63


/etc/systemd/system                     auto                    synced      none        none
/etc/systemd/user                       auto                    synced      none        none
/etc/systemd/journald.conf.d            auto                    synced      none        none

However, since core18, this path is instead re-defined as persistent transition (i.e. files are copied only on the first boot).

github.com

snapcore/core18/blob/master/static/etc/system-image/writable-paths#L42


/etc/iproute2                           auto                    persistent  transition  none
/etc/modprobe.d                         auto                    persistent  transition  none
/etc/modules-load.d                     auto                    persistent  transition  none
/etc/netplan                            auto                    persistent  transition  none
/etc/network/if-up.d                    auto                    persistent  transition  none
/etc/ssh                                auto                    persistent  transition  none
/etc/sudoers.d                          auto                    persistent  transition  none
# for wireless regulatory things
/etc/default/crda                       auto                    persistent  transition  none
# systemd
/etc/systemd                            auto                    persistent  transition  none
/var/lib/systemd                        auto                    persistent  transition  none
/var/lib/private/systemd                auto                    persistent  transition  none
# udev
/etc/udev/rules.d                       auto                    persistent  transition  none
/var/lib/extrausers                     auto                    persistent  transition  none
/var/lib/misc                           auto                    persistent  transition  none
/var/lib/sudo                           auto                    temporary   none        defaults,mode=0700
/var/log                                auto                    persistent  transition  none
/var/lib/console-conf                   auto                    persistent  transition  none

What I don’t understand is, when e.g. upgrade from core to core18, won’t the newly-shipped units become not-enabled by default? I think that it was a problem before in core which prompts the change from persistent transition to synced.

Isn’t it also a problem in core18+?

And, BTW: since Ubuntu Touch is special-purpose, personally I don’t really want the /etc/systemd to be completely writable, but we need it so that a few selected units can be disabled (e.g. systemd-timesyncd.service and ssh.service). Maybe there’s a better way to achieve this?

ratchanan.sr · July 18, 2022, 7:44pm

@zyga, since you seem to be the person that wrote the initial version of core18’s writable-paths, could you please give some insight here? (And please pardon me if this is inappropriate)

zyga · July 18, 2022, 10:15pm

Responding from phone so please forgive thr brevity.

I was not working on writable paths. I wanted to replace that with special mode of snap-confine back when it was still separate from snapd.

The change, however, I do remember. It was caused by the desire to control ssh from snapd. The synced mode was unable to express this and @mvo made the switch, if I recall correctly.

My advise is to abandon writable paths and switch to a different system. The original had countless issues and is far too inflexible.

ratchanan.sr · November 29, 2022, 5:48pm

@zyga Thank you for your response and sorry for late reply.

The limitation you mentioned seems to be the same that I discovered too. For our case though, I think we can live with it - for any unit that we want to be disable-able, we make sure that it’s disabled on the read-only layer (and then enable it on first boot if we want it to be enabled by default). And not being able to disable arbitrary units is sort of what I want anyway…

As for migrating away from writable-paths, at the moment I’m not sure what could replace it. Maybe a system which boots with empty /var/ and /etc/ would be nice, but we don’t have the resource to investigate into that at the moment.