http://bugzilla.suse.com/show_bug.cgi?id=1071224 http://bugzilla.suse.com/show_bug.cgi?id=1071224#c1 --- Comment #1 from Ludwig Nussel <lnussel@suse.com> --- Affects 42 and 14 too -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1071224 http://bugzilla.suse.com/show_bug.cgi?id=1071224#c3 Franck Bui <fbui@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |fbui@suse.com --- Comment #3 from Franck Bui <fbui@suse.com> --- The problem with "stop shipping it" is that it would break any users who choose to use this unit file. And masking the unit wouldn't help either since we don't want to mask tmp.mount if it's been generated from /etc/fstab or the user created his own version of the file. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1071224 http://bugzilla.suse.com/show_bug.cgi?id=1071224#c4 --- Comment #4 from Ludwig Nussel <lnussel@suse.com> --- in any case you cannot just rm it, it's part of the package -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1071224 http://bugzilla.suse.com/show_bug.cgi?id=1071224#c6 --- Comment #6 from Ludwig Nussel <lnussel@suse.com> --- Just don't do it. 15 will be a new major release, we document the change in behavior and be done with it. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1071224 http://bugzilla.suse.com/show_bug.cgi?id=1071224#c8 --- Comment #8 from Franck Bui <fbui@suse.com> --- Just to make sure: you meant to stop shipping it and break any users that would rely on it ? -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1071224 http://bugzilla.suse.com/show_bug.cgi?id=1071224#c10 --- Comment #10 from Ludwig Nussel <lnussel@suse.com> --- (In reply to Franck Bui from comment #8)

Just to make sure: you meant to stop shipping it and break any users that would rely on it ?

For this case you could still copy a backup of it to /etc in %pre of the new package. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1071224 http://bugzilla.suse.com/show_bug.cgi?id=1071224#c12 --- Comment #12 from Franck Bui <fbui@suse.com> --- How about this: 1. check that tmp.mount is active: if so we can assume that either tmp.mount from fstab is used or customer has its own version in /etc/systemd/... In these cases we can safely ship the default tmp.mount in /usr/lib/systemd/system since the active version will take precedence. 2. if tmp.mount is not active: we still ship tmp.mount but we mask it WDYT ? -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1071224 http://bugzilla.suse.com/show_bug.cgi?id=1071224#c14 --- Comment #14 from Ludwig Nussel <lnussel@suse.com> --- The installer might work but then how about just removing the requirement on tmp.mount from basic.target? That should also prevent it from starting automatically, right? -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1071224 http://bugzilla.suse.com/show_bug.cgi?id=1071224#c16 --- Comment #16 from Ludwig Nussel <lnussel@suse.com> --- another variant: tmp.mount could be removed from basic.target but an install section could be added: [Install] WantedBy=basic.target That means one would have to explicitly run systemctl enable to get tmp.mount -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1071224 http://bugzilla.suse.com/show_bug.cgi?id=1071224#c18 --- Comment #18 from Franck Bui <fbui@suse.com> --- Sorry for the delay... Letting tmp.mount still accessible is pretty dangerous (even if basic.target won't pull it in) because there are several other ways to activate it implicitly: for example when a unit is using private /tmp. So the only safe way I can see would be to mask the unit by default during the installation if no entry for /tmp is created in fstab by the installer. Regarding the upgrade path, we could mask tmp.mount if no tmp.mount is currently active and restore /usr/lib/systemd/system/tmp.mount if not present. Otherwise if a tmp.mount unit is active, simply restoring the one shipped by udev should be enough. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1071224 http://bugzilla.suse.com/show_bug.cgi?id=1071224#c20 --- Comment #20 from Franck Bui <fbui@suse.com> --- (In reply to Thorsten Kukuk from comment #19)

(In reply to Franck Bui from comment #18)

...

So the only safe way I can see would be to mask the unit by default during the installation if no entry for /tmp is created in fstab by the installer.

We have many installation ways and methods, and also upgrade has to work.

Updates of systemd package would take care of this.

In my opinion, we should not ship tmp.mount in the default path, but as 'example' or documentation in /usr/share/doc/packages/systemd or so.

That's what we're doing except that we care about users that already set up tmpfs on /tmp.

Yes, there is the risk to break very few installations, but I really doubt that people outside there use it, since we remove it if not activated. So how should an user ever activate it, if it is already removed at that point in time?

I don't agree with this and I'm wondering how you did figure out that few users are using tmpfs. Actually I'm using tmpfs on /tmp. And even if that would be true, breaking (voluntarily) user systems is a bad choice. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1071224 http://bugzilla.suse.com/show_bug.cgi?id=1071224#c22 --- Comment #22 from Franck Bui <fbui@suse.com> --- Ok so how about doing this: --- %< --- $ cat /etc/systemd/system/systemd-disable-tmpfs-for-tmp.service # By default, /tmp doesn't use tmpfs on SUSE distros. # # This script is either run automatically during the firstboot (i.e. # only once) of the system. # # Or the service can also be (manually) started during systemd update # (%post) only and only if tmp.mount wasn't installed in /usr/lib # during %pre. In this case tmp.mount should also masked. [Unit] Description=Mask tmp.mount by default on SUSE systems DefaultDependencies=no Conflicts=shutdown.target After=systemd-remount-fs.service Before=tmp.mount ConditionPathIsReadWrite=/etc ConditionPathExists=!/usr/lib/systemd/scripts/.disable-tmp-mount-by-default.sh~done [Service] Type=oneshot RemainAfterExit=yes ExecStart=/bin/sh -c ' \ case "$(systemctl show -pFragmentPath tmp.mount)" in \ FragmentPath=/usr/lib/systemd/system/tmp.mount) \ systemctl mask --now tmp.mount ;; \ esac' ExecStartPost=/usr/bin/touch /usr/lib/systemd/scripts/.disable-tmp-mount-by-default.sh~done --- %< --- this service should be statically pulled in by sysinit.target. And in systemd.spec: %pre if test -e /usr/lib/systemd/system/tmp.mount; then # If tmp.mount is there it means that admin restored it and # wants to use tmpfs. In that case do nothing and prevent # the service to be executed during %post. touch /usr/lib/systemd/scripts/.disable-tmp-mount-by-default.sh~done fi %post # Let's the service figure out what needs to be done, note # that it's going to be executed only once. systemctl start systemd-disable-tmpfs-for-tmp.service That way we should support the various ways a SUSE system can be created (heck!) and it should be fairly simple to switch back to tmpfs for /tmp the day SUSE will decide to do it. Ludwig, would that fill the gap ? -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1071224 http://bugzilla.suse.com/show_bug.cgi?id=1071224#c24 --- Comment #24 from Franck Bui <fbui@suse.com> --- (In reply to Ludwig Nussel from comment #23)

I am still not convinced about any complex solution.

Fair enough. But the previous solution is supposed to handle gracefully all the corner cases that we can encounter out there though. Also it would ease the switch to "tmpfs for /tmp" the day SUSE will decide to make it the default since we would simply have to stop shipping the new service that figures out if tmp.mount needs to be masked during the first boot. But if we're fine to forget those corner cases then shipping tmp.mount as a template (like we did already) only and recommending to symlink it from /etc if one wants to use tmpfs seems the simplest indeed. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1071224 http://bugzilla.suse.com/show_bug.cgi?id=1071224#c26 --- Comment #26 from Franck Bui <fbui@suse.com> --- Ludwig, I guess this also needs to be fixed in SLE12-SP2+, right ? -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1071224 http://bugzilla.suse.com/show_bug.cgi?id=1071224#c27 Richard Brown <rbrown@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |rbrown@suse.com Flags|needinfo?(lnussel@suse.com) | --- Comment #27 from Richard Brown <rbrown@suse.com> --- (In reply to Franck Bui from comment #26)

Ludwig, I guess this also needs to be fixed in SLE12-SP2+, right ?

The solution in Comment #22 has been submitted to factory https://build.opensuse.org/package/rdiff/openSUSE:Factory/systemd?linkrev=base&rev=269 It is now broken in Kubic https://openqa.opensuse.org/tests/603973#step/journal_check/14 You can not write to /usr/lib/systemd/scripts/ on a read only filesystem We support read-only root file systems on Kubic (based on tumbleweed) and CaaSP 3 (12 SP3) and 4 (15) I think this change needs to be reverted and reworked It should not be submitted in it's current form to SLE12-SP2+ because it will break on SUSE CaaSP. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1071224 http://bugzilla.suse.com/show_bug.cgi?id=1071224#c29 --- Comment #29 from Richard Brown <rbrown@suse.com> --- (In reply to Franck Bui from comment #28)

(In reply to Richard Brown from comment #27)

...

You can not write to /usr/lib/systemd/scripts/ on a read only filesystem

The problem happens when the system boots right, it doesn't happen when systemd package is upgraded ?

And how are we supposed to implement "run this script once" on these platforms ?

Thanks.

The only time you can write to the rootfs on Kubic and CaaSP is during a package installation/upgrade - the rootfs is immutable, but the package changes are written to a new snapshot which will take effect on next boot So the only place you COULD implement this logic is in the %post I think you should not, I think this is an overly complex solution for little or no benefit. I think this is a perfect example in the flesh of why Ludwig and Thorsten were both right earlier in this thread. Please reconsider their advised solutions of a subpackage or packaged examples -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1071224 http://bugzilla.suse.com/show_bug.cgi?id=1071224#c31 --- Comment #31 from Thorsten Kukuk <kukuk@suse.com> --- (In reply to Franck Bui from comment #30)

BTW what is used for /tmp on Kubic and CaaSP ?

Whatever the customers configured. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1071224 http://bugzilla.suse.com/show_bug.cgi?id=1071224#c33 --- Comment #33 from Franck Bui <fbui@suse.com> --- (In reply to Thorsten Kukuk from comment #32)

So whatever the solution will be, it has to work on a read-only root filesystem.

I'm fine to use the other solution but the main issue will remain and will need to be fixed the same way the day when SUSE will decide to make tmpfs the default for /tmp: everyone who don't use tmpfs will need to keep this setting once the default will be changed and the only solution I can see currently is to mask tmp.mount only *once*. And to implement that we need write access to /usr... OTOH if we're fine with the fact that some users will switch to tmpfs during an update then the problem is solved. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1071224 http://bugzilla.suse.com/show_bug.cgi?id=1071224#c35 --- Comment #35 from Franck Bui <fbui@suse.com> --- In order to fix distros using a RO rootfs I implemented the other solution. Richard, Thorsten, could you double check ? -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1071224 http://bugzilla.suse.com/show_bug.cgi?id=1071224#c37 Richard Brown <rbrown@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo?(kukuk@suse.com) --- Comment #37 from Richard Brown <rbrown@suse.com> --- (In reply to Franck Bui from comment #34)

Created attachment 759425 [details] disable tmpfs on /tmp by removing /usr/lib/systemd/system/tmp.mount

I'm reasonably confident the change proposed should work on SLE 15, TW, Leap and _FRESH INSTALLATIONS_ of CaaSP and Kubic But I expect the following line will fail on any upgrade of CaaSP or Kubic ln -sf %{_datadir}/systemd/tmp.mount /etc/systemd/system/ IIRC /etc is not mounted during a transactional upgrade, as it's an overlayfs It might fail silently (which is still not good) but if the script fails vocally, this will mean systemd will be un-upgradable on CaaSP and Kubic if systemctl show -pFragmentPath tmp.mount is true Thorsten, am I missing something? -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1071224 http://bugzilla.suse.com/show_bug.cgi?id=1071224#c39 Thorsten Kukuk <kukuk@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(kukuk@suse.com) | --- Comment #39 from Thorsten Kukuk <kukuk@suse.com> --- (In reply to Richard Brown from comment #37)

But I expect the following line will fail on any upgrade of CaaSP or Kubic

ln -sf %{_datadir}/systemd/tmp.mount /etc/systemd/system/

IIRC /etc is not mounted during a transactional upgrade, as it's an overlayfs

It will work fine. The real /etc is available during upgrade, only the user modifications (which are stored in the overlayfs) are not. Which doesn't matter, in worst case we create a symlink, which is shadowed by the user modifications. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1071224 Swamp Workflow Management <swamp@suse.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Whiteboard| |ibs:running:6694:moderate -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1071224 Swamp Workflow Management <swamp@suse.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Whiteboard|ibs:running:6694:moderate | -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1071224 Swamp Workflow Management <swamp@suse.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Whiteboard|obs:running:7843:moderate | -- You are receiving this mail because: You are on the CC list for the bug.

https://bugzilla.suse.com/show_bug.cgi?id=1071224 https://bugzilla.suse.com/show_bug.cgi?id=1071224#c48 Martin Loviska <mloviska@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |VERIFIED CC| |mloviska@suse.com --- Comment #48 from Martin Loviska <mloviska@suse.com> --- Closing as it does not occur in openQA tests -- You are receiving this mail because: You are on the CC list for the bug.