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

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)

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

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?

@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)

1 Like

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.