Le mardi 27 mars 2012 à 21:33 +0200, Lars Müller a écrit :
On Tue, Mar 27, 2012 at 07:16:23PM +0200, Matthias G. Eckermann wrote:
On 2012-03-27 T 18:46 +0200 Frederic Crozat wrote:
Le mardi 27 mars 2012 à 12:35 -0400, Robert Schweikert a écrit:
We probably have to consider any potential ill side effects for users that have /tmp already setup as a tmpfs mount.
This will need to be tested but I think systemd will just "override" the default from /etc/fstab in that case (but I'm not 100% sure)
That would be rather inconvenient: think about people who might have special mount options to /tmp on tmpfs, such as size, ...
We should cover at least these two cases:
a) Is /tmp covered by special settings in /etc/fstab?
If that's the case we inform the user via a short comment in the syslog and systemd does nothing further regading /tmp
If systemd is such a relaxed and flexible dude and allows it. I have my expectations and count on the systemd dictatorship. ;)
to allow that, we would need to either: - drop the dependency (local-fs.target/tmp.mount) and the tmp.mount file from /lib/systemd/system : not really good since they are "on disk" and would be packaged - create a generator checking for /etc/fstab which would create a tmp.mount file in /run/systemd/generator, which would override anything in /lib/systemd/system (stuff in /etc/systemd/system will always have priority: admins have the last word about it).
b) If we're sure this is a system which used the old default method to handle /tmp (by doing nothing special) we move anything from inside /tmp to a speaking new location we created before with the help of
mktemp -d /tmp-backup-$( date +%F)-XXXX
Else a less experience user might be surprised. On the other had such users also might miss the new location.
We also have to ensure such move is only performed one time.
That is a possibility, indeed.
--
Frederic Crozat