On 3/28/2012 6:49 AM, Ruediger Meier wrote:
On Wednesday 28 March 2012, Richard Guenther wrote:
On Wed, 28 Mar 2012, Frederic Crozat wrote:
Le mardi 27 mars 2012 à 19:16 +0200, Matthias G. Eckermann a écrit :
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, ...
I've done some tests about this particular changes (forward porting the patch to see its effects) : * systemd ships its own tmp.mount file which is overriding any information which might be relevant in /etc/fstab regarding /tmp * however, this file is overridable in /etc/systemd/system (as it was explained in the url I gave regarding this feature on Fedora) : - if we want to disable mounting /tmp as tmpfs, ln -s /dev/null /etc/systemd/system/tmp.mount will be enough (the defaults won't be applied) - if other settings are needed than the one from /lib/systemd/system/tmp.mount, adding options in /etc/systemd/system/tmp.mount will work (and even something like mounting /tmp to a separate partition) - a radical solution could also be to remove file in /lib/systemd/system/tmp.mount and symlink in /lib/systemd/system/local-fs.target/tmp.mount to make sure systemd doesn't take care of /tmp.
This ignorance of systemd of standard configuration files gets annoying ...
Just try to _believe_ like Poettering that all this is good :) https://fedoraproject.org/wiki/Features/tmp-on-tmpfs "Why is this mount established via a systemd unit file, instead of an entry in /etc/fstab?"
How come when _I_ want to do something new and different like, say, store temp stuff on a tempfs, _I_ would _naturally_ do it by adding a NEW directory, /mtmp or /rtmp, etc, and I'd any programs that I knew could get along in a fixed amount of utterly transient space. NOT change the behavior of something as universal and ancient as /tmp itself, break a few common and current and popular apps to use some other location, and let the entire rest of the world of unix-like software break or not break without knowing or caring. Yet when these wacks have the same idea, the only possible way to do it is "everything that this would break, is already broken" Why isn't "improve without destroying" a consideration? /tmp already has an established usage and expected behavior. Something completely new that does not work the way /tmp always did, should go in some new place that can't possibly break anything else. It's conflict-free progress for free in this case. All the special cases like embedded systems where /tmp might be tmpfs, are special cases. those systems by definition do not have to worry about one byte of code other than what the system comes with. All the general purpose systems out there already where the user or admin has gone out of their way to set up /tmp in ram (hey I have some myself) are likewise irrelevant to this discussion. Just because I did that to some server where I either wanted to experiment, or I knew that particular hardware and software combo was ok for it, and it worked out ok, in no way implies it's a sane _default_. Not for a general-purpose OS. Fedora should have no bearing either. If I wanted to run Fedora, I'd run Fedora. The closer Suse gets to Fedora the less reason I have to use Suse. -- bkw -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org