[opensuse-factory] Proposal: /tmp as tmpfs
Hello community, We recently moved MicroOS and Kubic to use tmpfs for /tmp instead of writing files there to disk. This means files written to /tmp as never written to disk and so dissapear on reboot. This was for a number of reasons, including - Reducing wear on SSDs/SD card storage - Using less disk space and being more tidy generally - Being more like many other Distro's and Unixes including Debian, Arch, Fedora, Solaris, etc - Being more consistant with the FHS recommendations that /tmp is flushed on reboot https://www.pathname.com/fhs/pub/fhs-2.3.html#TMPTEMPORARYFILES All of these reasons also apply for regular openSUSE, so I would like to propose that Tumbleweed moves to tmpfs for /tmp soon also. The impact should be minimal, as all POSIX compliant applications should already assume that /tmp is not persistant between invocations of the program. As we're walking paths that other distros long have, my own research suggests that vast majority of problematic /tmp use has already been resolved, such as by using /var/tmp instead. We will likely impliment this as systemd mount unit, meaning if people disable it then they will be able to return to the old behaviour. Does anyone have any objections, concerns, thoughts? Regards, -- Richard Brown Linux Distribution Engineer - Future Technology Team Phone +4991174053-361 SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, D-90409 Nuernberg (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
That gets a big +1 by me. Getting a clean /tmp after reboot is a good thing. On 7/10/20 11:49 AM, Richard Brown wrote:
Hello community,
We recently moved MicroOS and Kubic to use tmpfs for /tmp instead of writing files there to disk.
This means files written to /tmp as never written to disk and so dissapear on reboot.
This was for a number of reasons, including
- Reducing wear on SSDs/SD card storage - Using less disk space and being more tidy generally - Being more like many other Distro's and Unixes including Debian, Arch, Fedora, Solaris, etc - Being more consistant with the FHS recommendations that /tmp is flushed on reboot https://www.pathname.com/fhs/pub/fhs-2.3.html#TMPTEMPORARYFILES
All of these reasons also apply for regular openSUSE, so I would like to propose that Tumbleweed moves to tmpfs for /tmp soon also.
The impact should be minimal, as all POSIX compliant applications should already assume that /tmp is not persistant between invocations of the program.
As we're walking paths that other distros long have, my own research suggests that vast majority of problematic /tmp use has already been resolved, such as by using /var/tmp instead.
We will likely impliment this as systemd mount unit, meaning if people disable it then they will be able to return to the old behaviour.
Does anyone have any objections, concerns, thoughts?
Regards,
-- Benjamin Zeller <bzeller@suse.de> Systems Programmer SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuremberg, Germany Tel: +49-911-74053-0; Fax: +49-911-7417755; https://www.suse.com/ (HRB 36809, AG Nürnberg) Managing Director: Felix Imendörffer -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Richard Brown <rbrown@suse.de> writes:
Hello community,
* snip *
Does anyone have any objections, concerns, thoughts?
On the contrary! I have been using tmpfs as /tmp on Tumbleweed since the end of 2018 and cannot remember having run into any issues that would be attributed to that. So +1 from my side. Cheers, Dan -- Dan Čermák <dcermak@suse.com> Software Engineer Development tools SUSE Software Solutions Germany GmbH Maxfeldstr. 5 90409 Nuremberg Germany (HRB 36809, AG Nürnberg) Managing Director: Felix Imendörffer
On 10/07/2020 11.49, Richard Brown wrote:
Hello community,
We recently moved MicroOS and Kubic to use tmpfs for /tmp instead of writing files there to disk.
This means files written to /tmp as never written to disk and so dissapear on reboot.
This was for a number of reasons, including
- Reducing wear on SSDs/SD card storage - Using less disk space and being more tidy generally - Being more like many other Distro's and Unixes including Debian, Arch, Fedora, Solaris, etc - Being more consistant with the FHS recommendations that /tmp is flushed on reboot https://www.pathname.com/fhs/pub/fhs-2.3.html#TMPTEMPORARYFILES
All of these reasons also apply for regular openSUSE, so I would like to propose that Tumbleweed moves to tmpfs for /tmp soon also.
The impact should be minimal, as all POSIX compliant applications should already assume that /tmp is not persistant between invocations of the program.
As we're walking paths that other distros long have, my own research suggests that vast majority of problematic /tmp use has already been resolved, such as by using /var/tmp instead.
We will likely impliment this as systemd mount unit, meaning if people disable it then they will be able to return to the old behaviour.
Does anyone have any objections, concerns, thoughts?
Big - from me. We already discussed this in the past. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
On Fri, 2020-07-10 at 11:57 +0200, Carlos E. R. wrote:
Big - from me.
We already discussed this in the past.
A heck of a lot has changed in 8 years and most, if not all, of the concerns discussed back then are less relevant, if not wholly irrelevant. Please provide any objections based on the realities present in this year, 2020. Regards, -- Richard Brown Linux Distribution Engineer - Future Technology Team Phone +4991174053-361 SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, D-90409 Nuernberg (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 10/07/2020 12.07, Richard Brown wrote:
On Fri, 2020-07-10 at 11:57 +0200, Carlos E. R. wrote:
Big - from me.
We already discussed this in the past.
A heck of a lot has changed in 8 years and most, if not all, of the concerns discussed back then are less relevant, if not wholly irrelevant.
Please provide any objections based on the realities present in this year, 2020.
They have not changed. Specially, the humans using it. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
On Fri, 2020-07-10 at 13:11 +0200, Carlos E.R. wrote:
On 10/07/2020 12.07, Richard Brown wrote:
On Fri, 2020-07-10 at 11:57 +0200, Carlos E. R. wrote:
Big - from me.
We already discussed this in the past.
A heck of a lot has changed in 8 years and most, if not all, of the concerns discussed back then are less relevant, if not wholly irrelevant.
Please provide any objections based on the realities present in this year, 2020.
They have not changed. Specially, the humans using it.
I think the implication that we have to wait for people to die before we make improvements to the distribution is a little extreme. Regards, -- Richard Brown Linux Distribution Engineer - Future Technology Team Phone +4991174053-361 SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, D-90409 Nuernberg (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 10/07/2020 13.44, Richard Brown wrote:
On Fri, 2020-07-10 at 13:11 +0200, Carlos E.R. wrote:
On 10/07/2020 12.07, Richard Brown wrote:
On Fri, 2020-07-10 at 11:57 +0200, Carlos E. R. wrote:
Big - from me.
We already discussed this in the past.
A heck of a lot has changed in 8 years and most, if not all, of the concerns discussed back then are less relevant, if not wholly irrelevant.
Please provide any objections based on the realities present in this year, 2020.
They have not changed. Specially, the humans using it.
I think the implication that we have to wait for people to die before we make improvements to the distribution is a little extreme.
You are not getting it. People are using /tmp, not software, to store things, and some of them can be gigabytes. We really do not want that to go into ram. And then software use /tmp for things like downloads. Like firefox. Then, there are people that do not reboot their machines in days, or months. It doesn't help to have all that in ram, nor to not have old files deleted before a reboot. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
On Friday 2020-07-10 14:13, Carlos E. R. wrote:
You are not getting it.
People are using /tmp, not software, to store things, and some of them can be gigabytes. We really do not want that to go into ram.
And yet, you have /dev/shm, which is a tmpfs-like /tmp - same wide-open permissions, same persistence non-guarantee ("gone after reboot"), same "can fill up RAM" problem. I hear nobody complaining about _that_. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2020-07-10 14:42, Jan Engelhardt wrote:
And yet, you have /dev/shm, which is a tmpfs-like /tmp - same wide-open permissions, same persistence non-guarantee ("gone after reboot"), same "can fill up RAM" problem.
I hear nobody complaining about _that_.
I've never seen much usage of /dev/shm on a Desktop system, while many applications use /tmp. Have a nice day, Berny -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Fri, Jul 10, 2020 at 3:46 PM Bernhard Voelker <mail@bernhard-voelker.de> wrote:
On 2020-07-10 14:42, Jan Engelhardt wrote:
And yet, you have /dev/shm, which is a tmpfs-like /tmp - same wide-open permissions, same persistence non-guarantee ("gone after reboot"), same "can fill up RAM" problem.
I hear nobody complaining about _that_.
I've never seen much usage of /dev/shm on a Desktop system, while many applications use /tmp.
..And if you see *anything* other than software calling libc shm_* api effectively using it beyond a fallback doom scenario please file a bug report.. ;) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 10.07.20 um 14:13 schrieb Carlos E. R.:
People are using /tmp, not software, to store things, and some of them can be gigabytes. We really do not want that to go into ram.
You can still put /tmp on disk if you want, the question is if tmpfs is a reasonable default. Since many other Linux distributions also use tmpfs for /tmp, I don't think there are lots of people running into this issue.
And then software use /tmp for things like downloads. Like firefox.
Only if you click on "Open" instead of "Save", which is something you're likely not doing for very large files.
Then, there are people that do not reboot their machines in days, or months. It doesn't help to have all that in ram, nor to not have old files deleted before a reboot.
That's where systemd-tmpfiles comes to the rescue. Unfortunately we disable the default setting of removing files from /tmp after a reasonable time, but that discussion could also be warmed up again. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Saturday 2020-07-11 00:08, Aaron Puchert wrote:
And then software use /tmp for things like downloads. Like firefox.
Only if you click on "Open" instead of "Save", which is something you're likely not doing for very large files.
Unless you do not know in advance that it is a large file— The web is full of more-or-less evil sites left and right. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Carlos E. R. wrote:
People are using /tmp, not software, to store things, and some of them can be gigabytes. We really do not want that to go into ram.
And then software use /tmp for things like downloads. Like firefox.
Then, there are people that do not reboot their machines in days, or months. It doesn't help to have all that in ram, nor to not have old files deleted before a reboot. You are right.
Currently my /tmp directory has 5.5 Gbytes, 207 Mbytes are from today. One of the biggest /tmp subfolders is the temporary download folder from Firefox (/tmp/mozilla_user0). The tmpfiles Systemd cleanup job does not really cleanup much files, because some desktop programs update the "atime" of all files in the current directory in their "Save as ..." and "Open ..." dialogs. I already discussed this issue with Lennart Poettering and he does not see what Systemd can do with this issue. I am not sure, if I will go for a tmpfs /tmp directory. If I run the PC for multiple days (with suspend-to-disk), the /tmp directory may grow to 1 Gbyte and I do not want to waste my available RAM. Of course, these arguments only count for the desktop. Greetings, Björn -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Fri, Jul 10, 2020 at 13:44, Richard Brown <rbrown@suse.de> wrote:
I think the implication that we have to wait for people to die before we make improvements to the distribution is a little extreme.
"Waiting" is pointless considering there are professionals that can do that quicker and better LCP [Stasiek] https://lcp.world -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hi Richard, this is an overall good thing. As one could now rely on tmp being cleared on reboot. And option to make this configurable (tmpfs vs real filesystem) would be extremly nice. I for one use /tmp as data dump for stuff I mostly dont care, but would be happy to have the data still available a for a couple of days to test out stuff, mostly while developing. All the best, Bernd Am 10.07.20 um 11:49 schrieb Richard Brown:
Hello community,
We recently moved MicroOS and Kubic to use tmpfs for /tmp instead of writing files there to disk.
This means files written to /tmp as never written to disk and so dissapear on reboot.
This was for a number of reasons, including
- Reducing wear on SSDs/SD card storage - Using less disk space and being more tidy generally - Being more like many other Distro's and Unixes including Debian, Arch, Fedora, Solaris, etc - Being more consistant with the FHS recommendations that /tmp is flushed on reboot https://www.pathname.com/fhs/pub/fhs-2.3.html#TMPTEMPORARYFILES
All of these reasons also apply for regular openSUSE, so I would like to propose that Tumbleweed moves to tmpfs for /tmp soon also.
The impact should be minimal, as all POSIX compliant applications should already assume that /tmp is not persistant between invocations of the program.
As we're walking paths that other distros long have, my own research suggests that vast majority of problematic /tmp use has already been resolved, such as by using /var/tmp instead.
We will likely impliment this as systemd mount unit, meaning if people disable it then they will be able to return to the old behaviour.
Does anyone have any objections, concerns, thoughts?
Regards,
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Fri, Jul 10, 2020 at 11:49:45AM +0200, Richard Brown wrote:
We will likely impliment this as systemd mount unit, meaning if people disable it then they will be able to return to the old behaviour.
In general fstab is still the preferred method for that, see systemd.mount(8). Why deviate from that? I know there is a mount unit file somewhere in the system. ciao Arvin -- Arvin Schnell, <aschnell@suse.com> Senior Software Engineer, Research & Development SUSE Software Solutions Germany GmbH Maxfeldstraße 5 90409 Nürnberg Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Fri, 2020-07-10 at 10:05 +0000, Arvin Schnell wrote:
On Fri, Jul 10, 2020 at 11:49:45AM +0200, Richard Brown wrote:
We will likely impliment this as systemd mount unit, meaning if people disable it then they will be able to return to the old behaviour.
In general fstab is still the preferred method for that, see systemd.mount(8). Why deviate from that? I know there is a mount unit file somewhere in the system.
ciao Arvin
To copy-paste the answer from when the Fedora community discussed this back in 2012: "We believe that /etc/fstab is the place to configure real file systems, for actual user data, backed by real devices. The API file system /tmp does not qualify for that in our eyes. /tmp is very much something that should just exist as part of the OS and needs no user configuration. It is our goal to allow systems to boot up fully functional with an (almost) empty /etc/fstab. Also it is much easier to enable this logic for existing installs without the need to patch /etc/fstab. This is especially the case since making code that patches /etc/fstab like this idempotent is very hard since the user could just remove the entry we patched in and we couldn't distuingish this case from the not-yet-patched case. Note that /etc/fstab takes precedence over the systemd unit file. Systems which mount a specific file system to /tmp hence will continue to work as always." In our case, as /tmp is by default a btrfs subvolume (and so mentioned in the fstab), this actually means my proposed change will not impact existing default systems, unless the consensus that we impliment this change in a way that edits peoples existing fstabs. I'd be nervous about that, but I'm open to the possibility. What do people think? -- Richard Brown Linux Distribution Engineer - Future Technology Team Phone +4991174053-361 SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, D-90409 Nuernberg (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Fri, Jul 10, 2020 at 12:16:09PM +0200, Richard Brown wrote:
In general fstab is still the preferred method for that, see systemd.mount(8). Why deviate from that? I know there is a mount unit file somewhere in the system.
To copy-paste the answer from when the Fedora community discussed this back in 2012:
"We believe that /etc/fstab is the place to configure real file systems, for actual user data, backed by real devices. The API file system /tmp does not qualify for that in our eyes. /tmp is very much something that should just exist as part of the OS and needs no user configuration. It is our goal to allow systems to boot up fully functional with an (almost) empty /etc/fstab. Also it is much easier to enable this logic for existing installs without the need to patch /etc/fstab. This is especially the case since making code that patches /etc/fstab like this idempotent is very hard since the user could just remove the entry we patched in and we couldn't distuingish this case from the not-yet-patched case.
Note that /etc/fstab takes precedence over the systemd unit file. Systems which mount a specific file system to /tmp hence will continue to work as always."
In our case, as /tmp is by default a btrfs subvolume (and so mentioned in the fstab), this actually means my proposed change will not impact existing default systems, unless the consensus that we impliment this change in a way that edits peoples existing fstabs.
That is exactly the problem: YaST does generate an entry for /tmp. So without changing that tmpfs for /tmp will not be used (unless the user disables snapshots or selects a different filesystem for root). With the simple solution of YaST not adding an entry the user has no simply way of disabling tmpfs for /tmp anymore - at least not without the consequence of making snapshots of /tmp which looks very bad to me. The user would have to disable the mount unit, create a snapshot in the right way, and add it to fstab. ciao Arvin -- Arvin Schnell, <aschnell@suse.com> Senior Software Engineer, Research & Development SUSE Software Solutions Germany GmbH Maxfeldstraße 5 90409 Nürnberg Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Fri, 2020-07-10 at 10:34 +0000, Arvin Schnell wrote:
With the simple solution of YaST not adding an entry the user has no simply way of disabling tmpfs for /tmp anymore - at least not without the consequence of making snapshots of /tmp which looks very bad to me. The user would have to disable the mount unit, create a snapshot in the right way, and add it to fstab.
Why would they need to create a snapshot? They should be able to just disable the mount unit, and add it to the fstab. Plus, it's worth noting that with VM/Cloud images being an increasingly common way of getting openSUSE these days, what "YaST does" is not the only thing we need to keep in mind. But in this case delivering images with tmpfs by default is nice and simple also. -- Richard Brown Linux Distribution Engineer - Future Technology Team Phone +4991174053-361 SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, D-90409 Nuernberg (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Fri, Jul 10, 2020 at 12:41:48PM +0200, Richard Brown wrote:
On Fri, 2020-07-10 at 10:34 +0000, Arvin Schnell wrote:
With the simple solution of YaST not adding an entry the user has no simply way of disabling tmpfs for /tmp anymore - at least not without the consequence of making snapshots of /tmp which looks very bad to me. The user would have to disable the mount unit, create a snapshot in the right way, and add it to fstab.
Why would they need to create a snapshot?
Because YaST does would not create one anymore. Unless YaST gets extended to create snapshots and not add them to fstab.
Plus, it's worth noting that with VM/Cloud images being an increasingly common way of getting openSUSE these days, what "YaST does" is not the only thing we need to keep in mind.
But is a thing to keep in mind. ciao Arvin -- Arvin Schnell, <aschnell@suse.com> Senior Software Engineer, Research & Development SUSE Software Solutions Germany GmbH Maxfeldstraße 5 90409 Nürnberg Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Fri, 2020-07-10 at 10:52 +0000, Arvin Schnell wrote:
On Fri, Jul 10, 2020 at 12:41:48PM +0200, Richard Brown wrote:
On Fri, 2020-07-10 at 10:34 +0000, Arvin Schnell wrote:
With the simple solution of YaST not adding an entry the user has no simply way of disabling tmpfs for /tmp anymore - at least not without the consequence of making snapshots of /tmp which looks very bad to me. The user would have to disable the mount unit, create a snapshot in the right way, and add it to fstab.
Why would they need to create a snapshot?
Because YaST does would not create one anymore. Unless YaST gets extended to create snapshots and not add them to fstab.
Do you mean subvolumes, not snapshots? YaST doesn't create snapshots..snapper does..but you know that.. -- Richard Brown Linux Distribution Engineer - Future Technology Team Phone +4991174053-361 SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, D-90409 Nuernberg (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Fri, Jul 10, 2020 at 12:57:11PM +0200, Richard Brown wrote:
On Fri, 2020-07-10 at 10:52 +0000, Arvin Schnell wrote:
On Fri, Jul 10, 2020 at 12:41:48PM +0200, Richard Brown wrote:
On Fri, 2020-07-10 at 10:34 +0000, Arvin Schnell wrote:
With the simple solution of YaST not adding an entry the user has no simply way of disabling tmpfs for /tmp anymore - at least not without the consequence of making snapshots of /tmp which looks very bad to me. The user would have to disable the mount unit, create a snapshot in the right way, and add it to fstab.
Why would they need to create a snapshot?
Because YaST does would not create one anymore. Unless YaST gets extended to create snapshots and not add them to fstab.
Do you mean subvolumes, not snapshots?
YaST doesn't create snapshots..snapper does..but you know that..
Sure, subvolume is of course right. Mea culpa. ciao Arvin -- Arvin Schnell, <aschnell@suse.com> Senior Software Engineer, Research & Development SUSE Software Solutions Germany GmbH Maxfeldstraße 5 90409 Nürnberg Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Fri, Jul 10, Arvin Schnell wrote:
On Fri, Jul 10, 2020 at 12:41:48PM +0200, Richard Brown wrote:
On Fri, 2020-07-10 at 10:34 +0000, Arvin Schnell wrote:
With the simple solution of YaST not adding an entry the user has no simply way of disabling tmpfs for /tmp anymore - at least not without the consequence of making snapshots of /tmp which looks very bad to me. The user would have to disable the mount unit, create a snapshot in the right way, and add it to fstab.
Why would they need to create a snapshot?
Because YaST does would not create one anymore. Unless YaST gets extended to create snapshots and not add them to fstab.
For which did you wrote mksubvolume? mksubvolume /tmp ? Afterwards you have a /tmp subvolume and an /etc/fstab entry. What else is missing? Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany Managing Director: Felix Imendoerffer (HRB 36809, AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Fri, Jul 10, 2020 at 05:54:29PM +0200, Thorsten Kukuk wrote:
On Fri, Jul 10, Arvin Schnell wrote:
On Fri, Jul 10, 2020 at 12:41:48PM +0200, Richard Brown wrote:
On Fri, 2020-07-10 at 10:34 +0000, Arvin Schnell wrote:
With the simple solution of YaST not adding an entry the user has no simply way of disabling tmpfs for /tmp anymore - at least not without the consequence of making snapshots of /tmp which looks very bad to me. The user would have to disable the mount unit, create a snapshot in the right way, and add it to fstab.
Why would they need to create a snapshot?
Because YaST does would not create one anymore. Unless YaST gets extended to create snapshots and not add them to fstab.
For which did you wrote mksubvolume?
mksubvolume /tmp ?
Afterwards you have a /tmp subvolume and an /etc/fstab entry. What else is missing?
Everybody must know that. I doubt that is the case. And still rollbacks across that step do not work. ciao Arvin -- Arvin Schnell, <aschnell@suse.com> Senior Software Engineer, Research & Development SUSE Software Solutions Germany GmbH Maxfeldstraße 5 90409 Nürnberg Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 7/10/2020 04:16, Richard Brown wrote: ...
In our case, as /tmp is by default a btrfs subvolume (and so mentioned in the fstab), this actually means my proposed change will not impact existing default systems, unless the consensus that we impliment this change in a way that edits peoples existing fstabs.
I'd be nervous about that, but I'm open to the possibility.
What do people think?
FWIW I'd say leave existing fstab alone and existing users can go on with status quo. People can opt in if they'd like (so long as they know about it). Newly installed systems can have the new behavior as users should generally understand that new things might happen with a new install. -- Jason Craig -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Fri, Jul 10, Arvin Schnell wrote:
On Fri, Jul 10, 2020 at 11:49:45AM +0200, Richard Brown wrote:
We will likely impliment this as systemd mount unit, meaning if people disable it then they will be able to return to the old behaviour.
In general fstab is still the preferred method for that, see systemd.mount(8). Why deviate from that? I know there is a mount unit file somewhere in the system.
Because fstab is a big, static file hardly changeable by a distribution later. Many things (all the /proc, /sys, /dev, ...) stuff is meanwhile moved out of fstab to allow distributions to react on changed requirements. And even systemd it self is perfering tmp.mount for this and not /etc/fstab. In general: system specific things belongs to /etc/fstab, distribution specific management things belong into something which is easy update- and adjustable, like a systemd unit. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany Managing Director: Felix Imendoerffer (HRB 36809, AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Yes please - I always get kind of nostalgic when I find my years old files in /tmp Am 10.07.20 um 11:49 schrieb Richard Brown:
Hello community,
We recently moved MicroOS and Kubic to use tmpfs for /tmp instead of writing files there to disk.
This means files written to /tmp as never written to disk and so dissapear on reboot.
This was for a number of reasons, including
- Reducing wear on SSDs/SD card storage - Using less disk space and being more tidy generally - Being more like many other Distro's and Unixes including Debian, Arch, Fedora, Solaris, etc - Being more consistant with the FHS recommendations that /tmp is flushed on reboot https://www.pathname.com/fhs/pub/fhs-2.3.html#TMPTEMPORARYFILES
All of these reasons also apply for regular openSUSE, so I would like to propose that Tumbleweed moves to tmpfs for /tmp soon also.
The impact should be minimal, as all POSIX compliant applications should already assume that /tmp is not persistant between invocations of the program.
As we're walking paths that other distros long have, my own research suggests that vast majority of problematic /tmp use has already been resolved, such as by using /var/tmp instead.
We will likely impliment this as systemd mount unit, meaning if people disable it then they will be able to return to the old behaviour.
Does anyone have any objections, concerns, thoughts?
Regards,
-- Dominik Heidler Maxfeldstr. 5, D-90409 Nuernberg, Germany Phone +49-911-74053-141 SUSE Software Solutions Germany GmbH GF: Felix Imendörffer (HRB 36809, AG Nürnberg) _________________________________________ ドミニク -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2020-07-10 06:07 AM, Dominik Heidler wrote:
Yes please - I always get kind of nostalgic when I find my years old files in /tmp
Didn't there used to be a setting for clearing out /tmp. I can't seem to find it now. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 10.07.20 um 14:49 schrieb James Knott:
On 2020-07-10 06:07 AM, Dominik Heidler wrote:
Yes please - I always get kind of nostalgic when I find my years old files in /tmp
Didn't there used to be a setting for clearing out /tmp. I can't seem to find it now.
You can create a file in /etc/tmpfiles.d/ with content q /tmp 1777 root root <time> with a <time> interval that you find suitable, like 10d or 4w. You should probably name that file tmp.conf, although the file that it's supposed to overwrite was removed from Tumbleweed recently. Best regards, Aaron -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 10/07/2020 14.49, James Knott wrote:
On 2020-07-10 06:07 AM, Dominik Heidler wrote:
Yes please - I always get kind of nostalgic when I find my years old files in /tmp
Didn't there used to be a setting for clearing out /tmp. I can't seem to find it now.
Yes, there was a cron job years ago, but was removed when systemd came this way. And systemd has its own way, but on Leap it is disabled. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
Richard Brown <rbrown@suse.de> wrote:
This was for a number of reasons, including
- Reducing wear on SSDs/SD card storage - Using less disk space and being more tidy generally - Being more like many other Distro's and Unixes including Debian, Arch, Fedora, Solaris, etc
BTW: Solaris made tmpfs for /tmp the default since 1993. It is really time t have the same on every Linux.... Jörg -- EMail:joerg@schily.net (home) Jörg Schilling D-13353 Berlin joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.org/private/ http://sf.net/projects/schilytools/files/' -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Olaf Hering <olaf@aepfle.de> wrote:
Am Fri, 10 Jul 2020 12:08:19 +0200 schrieb Joerg Schilling <Joerg.Schilling@fokus.fraunhofer.de>:
It is really time t have the same on every Linux....
Jrg,
A reminder: we make changes because they may improve things. Not because someone else does something the same way...
Do you like t say that tmpfs (as introduced in 1987 for SunOS) was not an improvement? Do you like to say that using tmpfs by default since 1993 was not an improvement? Jörg -- EMail:joerg@schily.net (home) Jörg Schilling D-13353 Berlin joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.org/private/ http://sf.net/projects/schilytools/files/' -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
hi, Am 10.07.20 um 11:49 schrieb Richard Brown:
All of these reasons also apply for regular openSUSE, so I would like to propose that Tumbleweed moves to tmpfs for /tmp soon also.
Does anyone have any objections, concerns, thoughts?
i am using this since years now on tumbleweed, by linking /usr/share/systemd/tmp.mount to /etc/systemd/system but, of course, yes, it is not the default... -- Best Regards | Freundliche Grüße | Cordialement | Cordiali Saluti | Atenciosamente | Saludos Cordiales *DI Rainer Klier* -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Fri, 2020-07-10 at 12:13 +0200, Rainer Klier wrote:
hi,
Am 10.07.20 um 11:49 schrieb Richard Brown:
All of these reasons also apply for regular openSUSE, so I would like to propose that Tumbleweed moves to tmpfs for /tmp soon also.
Does anyone have any objections, concerns, thoughts?
i am using this since years now on tumbleweed, by linking /usr/share/systemd/tmp.mount to /etc/systemd/system
but, of course, yes, it is not the default...
Hi Rainer, Thanks for your email Because this change stops putting that mount unit in that obscure location and relocates it to the expected upstream location, I've updated the /tmp on tmpfs wikipage for the steps you'll need to take when this change goes live so you can have exactly the same as a fresh default going forward https://en.opensuse.org/openSUSE:Tmp_on_tmpfs Hope this helps -- Richard Brown Linux Distribution Engineer - Future Technology Team Phone +4991174053-361 SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, D-90409 Nuernberg (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
hi Richard, Am 04.08.20 um 14:38 schrieb Richard Brown:
On Fri, 2020-07-10 at 12:13 +0200, Rainer Klier wrote:
hi,
i am using this since years now on tumbleweed, by linking /usr/share/systemd/tmp.mount to /etc/systemd/system
but, of course, yes, it is not the default...
Because this change stops putting that mount unit in that obscure location and relocates it to the expected upstream location, I've updated the /tmp on tmpfs wikipage for the steps you'll need to take when this change goes live so you can have exactly the same as a fresh default going forward
thank you very much, for taking care of users like me, who need to prepare for the upcoming changes.
https://en.opensuse.org/openSUSE:Tmp_on_tmpfs
Hope this helps
yes, thanks, i totally understand, what i have to do, when this change happens. how do i know, when this happens? will it be part of the next systemd update in tumbleweed? and thanks for making tmpfs the default for /tmp -- Best Regards | Freundliche Grüße | Cordialement | Cordiali Saluti | Atenciosamente | Saludos Cordiales *DI Rainer Klier* DevOps, Research & Development -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, 2020-08-04 at 15:37 +0200, Rainer Klier wrote:
thank you very much, for taking care of users like me, who need to prepare for the upcoming changes.
https://en.opensuse.org/openSUSE:Tmp_on_tmpfs
Hope this helps
yes, thanks, i totally understand, what i have to do, when this change happens.
how do i know, when this happens?
will it be part of the next systemd update in tumbleweed?
and thanks for making tmpfs the default for /tmp
Hi Rainer, Unless something dramatically changes, it should be in the next systemd update in Tumbleweed. It's currently in staging and being tested, with any last minute issues being taken care of. I'll update both the wiki and make an announcement here when I know the exact snapshot number that the release will make -- Richard Brown Linux Distribution Engineer - Future Technology Team Phone +4991174053-361 SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, D-90409 Nuernberg (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
hi Richard, Am 04.08.20 um 15:41 schrieb Richard Brown:
On Tue, 2020-08-04 at 15:37 +0200, Rainer Klier wrote:
how do i know, when this happens?
will it be part of the next systemd update in tumbleweed?
and thanks for making tmpfs the default for /tmp
Unless something dramatically changes, it should be in the next systemd update in Tumbleweed.
I'll update both the wiki and make an announcement here when I know the exact snapshot number that the release will make
great! thank you very much. -- Best Regards | Freundliche Grüße | Cordialement | Cordiali Saluti | Atenciosamente | Saludos Cordiales *DI Rainer Klier* DevOps, Research & Development -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2020-08-04 15:50, Rainer Klier wrote:
I'll update both the wiki and make an announcement here when I know the exact snapshot number that the release will make
great!
thank you very much.
As promised, this is the announcement that Snapshot 20200806 has been released and is the release that contains /tmp as tmpfs by default. Most existing users don't need to do anything, but can now follow the instructions on https://en.opensuse.org/openSUSE:Tmp_on_tmpfs to change their system to use this new approach. Users who already had various workarounds to put /tmp on tmpfs should follow the instructions on https://en.opensuse.org/openSUSE:Tmp_on_tmpfs to align their systems with this new default. Users who want to restore the old behaviour on new systems should follow the instructions also at https://en.opensuse.org/openSUSE:Tmp_on_tmpfs Have a lot of fun! -- Richard Brown Linux Distribution Engineer - Future Technology Team SUSE Software Solutions Germany GmbH Maxfeldstr. 5 90409 Nuremberg Germany (HRB 36809, AG Nürnberg) Managing Director: Felix Imendörffer -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
hi, Am 07.08.20 um 16:19 schrieb Richard Brown:
As promised, this is the announcement that Snapshot 20200806 has been released and is the release that contains /tmp as tmpfs by default.
Users who already had various workarounds to put /tmp on tmpfs should follow the instructions on https://en.opensuse.org/openSUSE:Tmp_on_tmpfs to align their systems with this new default.
i can confirm that it works. thank you very much. -- Best Regards | Freundliche Grüße | Cordialement | Cordiali Saluti | Atenciosamente | Saludos Cordiales *DI Rainer Klier* DevOps, Research & Development namirialLogo _________________________________________________________ Namirial GmbH Phone: +43 7229 88 0 60 - 758 | Mobile: +43 664 610 17 06 Haiderstraße 23 | 4052 Ansfelden | Austria Website: https://www.xyzmo.com/ Support: https://www.xyzmo.com/contact/support The sender of this email disclaims any intent to be bound hereby, except where the sender clearly and explicitly provides otherwise. namirialAd -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Does this work with openSUSE Leap 15.2 too? Sent with ProtonMail Secure Email. ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ пятница, 7 августа 2020 г., 19:19, Richard Brown <rbrown@suse.de> написано:
On 2020-08-04 15:50, Rainer Klier wrote:
I'll update both the wiki and make an announcement here when I know the exact snapshot number that the release will make
great! thank you very much.
As promised, this is the announcement that Snapshot 20200806 has been released and is the release that contains /tmp as tmpfs by default.
Most existing users don't need to do anything, but can now follow the instructions on https://en.opensuse.org/openSUSE:Tmp_on_tmpfs to change their system to use this new approach.
Users who already had various workarounds to put /tmp on tmpfs should follow the instructions on https://en.opensuse.org/openSUSE:Tmp_on_tmpfs to align their systems with this new default.
Users who want to restore the old behaviour on new systems should follow the instructions also at https://en.opensuse.org/openSUSE:Tmp_on_tmpfs
Have a lot of fun!
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Richard Brown Linux Distribution Engineer - Future Technology Team
SUSE Software Solutions Germany GmbH Maxfeldstr. 5 90409 Nuremberg Germany
(HRB 36809, AG Nürnberg) Managing Director: Felix Imendörffer
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wed, 2020-08-12 at 00:16 +0000, Alexander Bokov wrote:
Does this work with openSUSE Leap 15.2 too?
Absolutely not - it would be highly inappropriate to insert such a significant behavoural change in a minor release of such a conservative distribution. Regards,
Sent with ProtonMail Secure Email.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ пятница, 7 августа 2020 г., 19:19, Richard Brown <rbrown@suse.de> написано:
On 2020-08-04 15:50, Rainer Klier wrote:
I'll update both the wiki and make an announcement here when I know the exact snapshot number that the release will make
great! thank you very much.
As promised, this is the announcement that Snapshot 20200806 has been released and is the release that contains /tmp as tmpfs by default.
Most existing users don't need to do anything, but can now follow the instructions on https://en.opensuse.org/openSUSE:Tmp_on_tmpfs to change their system to use this new approach.
Users who already had various workarounds to put /tmp on tmpfs should follow the instructions on https://en.opensuse.org/openSUSE:Tmp_on_tmpfs to align their systems with this new default.
Users who want to restore the old behaviour on new systems should follow the instructions also at https://en.opensuse.org/openSUSE:Tmp_on_tmpfs
Have a lot of fun!
----------------------------------------------------------------- ----------------------------------------------------------------- ----------------------------------------------------------------- ----------------------------------------------------------------- ----------------------------------------------------------------- ----------------------------------------------------------------- ----------------------------------------------------------------- ----------------------------------------------------------------- ----------------------------------------------------------------- ----------------------------------------------------------------- ---------------------------
Richard Brown Linux Distribution Engineer - Future Technology Team
SUSE Software Solutions Germany GmbH Maxfeldstr. 5 90409 Nuremberg Germany
(HRB 36809, AG Nürnberg) Managing Director: Felix Imendörffer
----------------------------------------------------------------- ----------------------------------------------------------------- ----------------------------------------------------------------- -----------
To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-- Richard Brown Linux Distribution Engineer - Future Technology Team Phone +4991174053-361 SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, D-90409 Nuernberg (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hi Richard, Am 12.08.20 um 10:03 schrieb Richard Brown:
On Wed, 2020-08-12 at 00:16 +0000, Alexander Bokov wrote:
Does this work with openSUSE Leap 15.2 too?
Absolutely not - it would be highly inappropriate to insert such a significant behavoural change in a minor release of such a conservative distribution.
I think you misread the question. I'd *guess* (i have not tried it) that this *works* with 15.2 also. At least /tmp/ on tmpfs is surely possible with 15.2, I'm just not sure if the instructions to achieve it are the same. Of course it will not be implemented automatically during a maintenance update ;-) -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Fri, 2020-08-14 at 10:05 +0200, Stefan Seyfried wrote:
Hi Richard,
Am 12.08.20 um 10:03 schrieb Richard Brown:
On Wed, 2020-08-12 at 00:16 +0000, Alexander Bokov wrote:
Does this work with openSUSE Leap 15.2 too?
Absolutely not - it would be highly inappropriate to insert such a significant behavoural change in a minor release of such a conservative distribution.
I think you misread the question.
I think the topic of this thread was making /tmp as tmpfs the default, at least that was the intent when I started the thread. I am sure the topic of the email he replied was explicitly written as "/tmp on tmpfs now default". I am also sure the instructions on https://en.opensuse.org/openSUSE:Tmp_on_tmpfs are all related to /tmp on tmpfs now being the default in Tumbleweed. You may *guess* that someone can make /tmp on tmpfs work on Leap. I guess that's possible too. But I am *sure* that none of the information I've written in this thread, nor any of the documentation on the wiki, is helpful for that. Leap does not have any of the changes to systemd, skelcd-control- openSUSE, and various other packages in order to make things possible in the way they now are on Tumbleweed. And I think it would be inappropriate to do all that work in a minor release for Leap. And so, "Absolutely not" - this will not work with Leap 15.2 too. -- Richard Brown Linux Distribution Engineer - Future Technology Team Phone +4991174053-361 SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, D-90409 Nuernberg (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 8/7/20 4:19 PM, Richard Brown wrote:
Users who want to restore the old behaviour on new systems should follow the instructions also at https://en.opensuse.org/openSUSE:Tmp_on_tmpfs
Hello. Can you please extend documentation about how to restore old behavior? I don't use btrfs (which you mentioned in an example). Can you please show an example fstab line that should be added? Thanks, Martin -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am Donnerstag, 13. August 2020, 08:41:38 CEST schrieb Martin Liška:
On 8/7/20 4:19 PM, Richard Brown wrote:
Users who want to restore the old behaviour on new systems should follow the instructions also at https://en.opensuse.org/openSUSE:Tmp_on_tmpfs Hello.
Can you please extend documentation about how to restore old behavior? I don't use btrfs (which you mentioned in an example). Can you please show an example fstab line that should be added?
Adapt the UUID and you should be fine (assuming you have created a subvolume already): UUID=yxz /tmp btrfs subvol=/@/tmp 0 0 HTH Axel -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 8/13/20 8:45 AM, Axel Braun wrote:
Am Donnerstag, 13. August 2020, 08:41:38 CEST schrieb Martin Liška:
On 8/7/20 4:19 PM, Richard Brown wrote:
Users who want to restore the old behaviour on new systems should follow the instructions also at https://en.opensuse.org/openSUSE:Tmp_on_tmpfs Hello.
Can you please extend documentation about how to restore old behavior? I don't use btrfs (which you mentioned in an example). Can you please show an example fstab line that should be added?
Adapt the UUID and you should be fine (assuming you have created a subvolume already):
Sorry, but I __don't__ have btrfs. There's my fdisk layout: Device Start End Sectors Size Type /dev/vda1 2048 18431 16384 8M BIOS boot /dev/vda2 18432 251658206 251639775 120G Linux filesystem and my current /etc/fstab: UUID=39c71e0f-a2b4-48e6-8925-b7ffa5d8127a / ext4 acl,user_xattr 0 1 Thanks, Martin
UUID=yxz /tmp btrfs subvol=/@/tmp 0 0
HTH Axel
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thu, 2020-08-13 at 08:46 +0200, Martin Liška wrote:
On 8/13/20 8:45 AM, Axel Braun wrote:
Am Donnerstag, 13. August 2020, 08:41:38 CEST schrieb Martin Liška:
On 8/7/20 4:19 PM, Richard Brown wrote:
Users who want to restore the old behaviour on new systems should follow the instructions also at https://en.opensuse.org/openSUSE:Tmp_on_tmpfs Hello.
Can you please extend documentation about how to restore old behavior? I don't use btrfs (which you mentioned in an example). Can you please show an example fstab line that should be added?
Adapt the UUID and you should be fine (assuming you have created a subvolume already):
Sorry, but I __don't__ have btrfs. There's my fdisk layout:
Device Start End Sectors Size Type /dev/vda1 2048 18431 16384 8M BIOS boot /dev/vda2 18432 251658206 251639775 120G Linux filesystem
and my current /etc/fstab:
UUID=39c71e0f-a2b4-48e6-8925-b7ffa5d8127a / ext4 acl,user_xattr 0 1
In your case, all that should be needed then is to mask tmp.mount systemctl mask tmp.mount -> and the systemd provided tmp.mount file will be ignored. If this works for you, it would be great if you could extend the wiki accordingly. Thank you! cheers, Dominique
On 8/13/20 8:50 AM, Dominique Leuenberger / DimStar wrote:
On Thu, 2020-08-13 at 08:46 +0200, Martin Liška wrote:
On 8/13/20 8:45 AM, Axel Braun wrote:
Am Donnerstag, 13. August 2020, 08:41:38 CEST schrieb Martin Liška:
On 8/7/20 4:19 PM, Richard Brown wrote:
Users who want to restore the old behaviour on new systems should follow the instructions also at https://en.opensuse.org/openSUSE:Tmp_on_tmpfs Hello.
Can you please extend documentation about how to restore old behavior? I don't use btrfs (which you mentioned in an example). Can you please show an example fstab line that should be added?
Adapt the UUID and you should be fine (assuming you have created a subvolume already):
Sorry, but I __don't__ have btrfs. There's my fdisk layout:
Device Start End Sectors Size Type /dev/vda1 2048 18431 16384 8M BIOS boot /dev/vda2 18432 251658206 251639775 120G Linux filesystem
and my current /etc/fstab:
UUID=39c71e0f-a2b4-48e6-8925-b7ffa5d8127a / ext4 acl,user_xattr 0 1
In your case, all that should be needed then is to mask tmp.mount
systemctl mask tmp.mount -> and the systemd provided tmp.mount file will be ignored.
Works for me, thanks!
If this works for you, it would be great if you could extend the wiki accordingly. Thank you!
Done: https://en.opensuse.org/openSUSE:Tmp_on_tmpfs#Using_disk_space_for_.2Ftmp Martin
cheers, Dominique
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thu, 2020-08-13 at 08:58 +0200, Martin Liška wrote:
If this works for you, it would be great if you could extend the wiki accordingly. Thank you!
Done: https://en.opensuse.org/openSUSE:Tmp_on_tmpfs#Using_disk_space_for_.2Ftmp
Added a warning about how dangerous it would be if you did this on a btrfs system -- Richard Brown Linux Distribution Engineer - Future Technology Team Phone +4991174053-361 SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, D-90409 Nuernberg (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thu, 2020-08-13 at 09:53 +0200, Richard Brown wrote:
On Thu, 2020-08-13 at 08:58 +0200, Martin Liška wrote:
If this works for you, it would be great if you could extend the wiki accordingly. Thank you!
Done: https://en.opensuse.org/openSUSE:Tmp_on_tmpfs#Using_disk_space_for_.2Ftmp
Added a warning about how dangerous it would be if you did this on a btrfs system
Absolutely, yes - that should only be done on non-btrfs systems (as Martin mentioned he's using). Maybe we should change the paragraph to not use 'alternatively', but rather explicitly refer to 'if not using btrfs' ? something likw: """ This is easiest with btrfs and creating a subvolume, using the "mksubvolume /tmp" command. When you're not using btrfs for /, you can mask the /tmp mount point with "systemctl mask tmp.mount". NOTE: If you mask tmp.mount while using btrfs you will be filling up your root filesystem AND creating snapshots containing the contents of tmp (in other words, don't do this, and define a subvolume) """ Cheers, Dominique
On Friday 2020-07-10 11:49, Richard Brown wrote:
Hello community,
We recently moved MicroOS and Kubic to use tmpfs for /tmp instead of writing files there to disk.
Does anyone have any objections, concerns, thoughts?
I am not saying it's bad, but I can't be warmed for it either... read on. /tmp is one of the weirder places in a system. It is nice that FHS says it is not persistent across reboots, but if you have a workstation or server which is "never" (or at least, seldomly) rebooted, the directory can still fill up - and take away RAM from both oneself and other users. Firefox for example has the very bad habit of dumping all its .xpi file downloads into /tmp, and not cleaning them. Users have bad habit :^) in abusing /tmp as the shortest way to store a file in a known location for some time - because any other location would be persistent (but /tmp might be too heh) and the path much longer. SUSE systems used to have/have a cron job that would sweep /tmp every day and look for files 7 days or older and purge them, which I believe is still a good compromise considering the above longevity of /tmp _even if_ it were tmpfs-backed. Another thought that crossed my mind is making systemd set up a PrivateTmp for login sessions, i.e. make /tmp a bind mount to the users home dir, so it does actually account towards their disk quota. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Jan Engelhardt <jengelh@inai.de> wrote:
/tmp is one of the weirder places in a system.
It is nice that FHS says it is not persistent across reboots, but if you have a workstation or server which is "never" (or at least, seldomly) rebooted, the directory can still fill up - and take away RAM from both oneself and other users.
tmpfs is not a RAM file system but a filesystem based on anonymous memory. This is how it has been implemented on SunOS un 1987 and I am _very_ sure it works the same on Linux. In other words: if you have files that lay around in /tmp. this just eats up swap. Jörg -- EMail:joerg@schily.net (home) Jörg Schilling D-13353 Berlin joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.org/private/ http://sf.net/projects/schilytools/files/' -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Friday 2020-07-10 12:34, Joerg Schilling wrote:
Jan Engelhardt <jengelh@inai.de> wrote:
/tmp is one of the weirder places in a system.
It is nice that FHS says it is not persistent across reboots, but if you have a workstation or server which is "never" (or at least, seldomly) rebooted, the directory can still fill up - and take away RAM from both oneself and other users.
tmpfs is not a RAM file system but a filesystem based on anonymous memory. This is how it has been implemented on SunOS un 1987 and I am _very_ sure it works the same on Linux.
In other words: if you have files that lay around in /tmp. this just eats up swap.
Yes you are right, it is anonmem. But for those without swap configured, it is equal to RAM. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Jan Engelhardt <jengelh@inai.de> wrote:
In other words: if you have files that lay around in /tmp. this just eats up swap.
Yes you are right, it is anonmem. But for those without swap configured, it is equal to RAM.
It is recommended to have a swap that is 2x the size of the RAM. If you did have /tmp in a filesystem, this eats up disk space as well and if you configured swap to be on ZFS, this is even shared space with the other filesystems, so it does not have any disadvantage at all. Jörg -- EMail:joerg@schily.net (home) Jörg Schilling D-13353 Berlin joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.org/private/ http://sf.net/projects/schilytools/files/' -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Fri, 2020-07-10 at 12:42 +0200, Joerg Schilling wrote:
Jan Engelhardt <jengelh@inai.de> wrote:
In other words: if you have files that lay around in /tmp. this just eats up swap.
Yes you are right, it is anonmem. But for those without swap configured, it is equal to RAM.
It is recommended to have a swap that is 2x the size of the RAM.
that is no longer good practice. Current best practice is swap between 1-2GB, unless hibernation support is desired, in which case swap should be the size of the RAM. That is why YaST now has a tickbox to that effect https://openqa.opensuse.org/tests/1328299#step/partitioning_filesystem/6 The old fashioned advice of 2x RAM would really make no sense on most modern computers. This laptop has 32GB of RAM, my last desktop had 256GB. 64 or 512GB of swap would result in a situation where any memory leak/excessive memory usage would take hours, or even days, before the kernel oom killer would start killing processes. Meanwhile my system would be unusable while it's swapping away at orders of magnitude slower even writing to SSD compared to what it expects from RAM. yeah..no..swap is still important for optimising kernel performance, but anything above 2GB is wasteful unless you want to hibernate. (and hibernation isn't all that desirable if it takes a bloody long time writing lots of GB to disk) Regards, -- Richard Brown Linux Distribution Engineer - Future Technology Team Phone +4991174053-361 SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, D-90409 Nuernberg (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Friday, 10 July 2020 20:12:10 ACST Joerg Schilling wrote:
Jan Engelhardt <jengelh@inai.de> wrote:
In other words: if you have files that lay around in /tmp. this just eats up swap.
Yes you are right, it is anonmem. But for those without swap configured, it is equal to RAM.
It is recommended to have a swap that is 2x the size of the RAM.
I have 32GB RAM on my desktop machine. I've not run swap for over 4 years. I do use tmpfs for /tmp (have done for >5 years), and I've never had an out-of- memory situation, even with 2 or 3 Windows VM's (with 8GB RAM each) running simultaneously. [I haven't had to do that for a while, mind you, but there was a time when I was working remotely and needed 2 VPN sessions to 2 different networks, hence the 2 VM's.]
If you did have /tmp in a filesystem, this eats up disk space as well and if you configured swap to be on ZFS, this is even shared space with the other filesystems, so it does not have any disadvantage at all.
Jörg
-- ============================================================== Rodney Baker VK5ZTV rodney.baker@iinet.net.au CCNA #CSCO12880208 ============================================================== -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Friday 2020-07-10 12:42, Joerg Schilling wrote:
Jan Engelhardt <jengelh@inai.de> wrote:
In other words: if you have files that lay around in /tmp. this just eats up swap.
Yes you are right, it is anonmem. But for those without swap configured, it is equal to RAM.
It is recommended to have a swap that is 2x the size of the RAM.
I just do not see the value in allocating 128G of disk when I can't even fill 64G of RAM in daily workloads beyond a quarter. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 10/07/2020 12.42, Joerg Schilling wrote:
Jan Engelhardt <jengelh@inai.de> wrote:
In other words: if you have files that lay around in /tmp. this just eats up swap.
Yes you are right, it is anonmem. But for those without swap configured, it is equal to RAM.
It is recommended to have a swap that is 2x the size of the RAM.
No, it is not. Not in Linux. That reccomendation came from Windows. Where is that recommendation documented? -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
Carlos E. R. schrieb am 10.07.20 um 14:16:
On 10/07/2020 12.42, Joerg Schilling wrote:
Jan Engelhardt <jengelh@inai.de> wrote:
In other words: if you have files that lay around in /tmp. this just eats up swap.
Yes you are right, it is anonmem. But for those without swap configured, it is equal to RAM.
It is recommended to have a swap that is 2x the size of the RAM.
No, it is not. Not in Linux. That reccomendation came from Windows.
Where is that recommendation documented?
I'm quite sure I read that in the manuals of SLES 9. SAP referred to the "2 times RAM" rule, saying that you should follow it generally, but do not make swap bigger that 20 GB. So all my old SAP hosts (that have been virtualised > 10 years ago) still have a 20 GB swap partition, while the newer SAP HANA hosts have 1 or 2 GB swap. If a HANA host starts to swap to disk, you should get out a shovel and dig your tomb :) --
Moin, On Aug 13, 20 09:10:21 +0200, Werner Flamme wrote:
Carlos E. R. schrieb am 10.07.20 um 14:16:
On 10/07/2020 12.42, Joerg Schilling wrote:
Jan Engelhardt <jengelh@inai.de> wrote:
In other words: if you have files that lay around in /tmp. this just eats up swap.
Yes you are right, it is anonmem. But for those without swap configured, it is equal to RAM.
It is recommended to have a swap that is 2x the size of the RAM.
No, it is not. Not in Linux. That reccomendation came from Windows.
Where is that recommendation documented?
I'm quite sure I read that in the manuals of SLES 9.
Most likely from that time, yes. It was a good rule of thumb when suspend to disk was in it's early shoes, and Desktop systems needed more space for that on disk than with nowadays implementation. Keep in mind, memory was much less per system in those times, too.
swap partition, while the newer SAP HANA hosts have 1 or 2 GB swap. If a HANA host starts to swap to disk, you should get out a shovel and dig your tomb :)
I'm not sure you wil have time to finish digging ;) Stefan
--
-- Stefan Behlert, SUSE Software Solutions Product Manager SUSE Linux Enterprise Maxfeldstr. 5, D-90409 Nuernberg, Germany Phone +49-911-74053-173 SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer (HRB 36809, AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Fri, Jul 10, 2020 at 12:34:01PM +0200, Joerg Schilling wrote:
Jan Engelhardt <jengelh@inai.de> wrote:
/tmp is one of the weirder places in a system.
It is nice that FHS says it is not persistent across reboots, but if you have a workstation or server which is "never" (or at least, seldomly) rebooted, the directory can still fill up - and take away RAM from both oneself and other users.
tmpfs is not a RAM file system but a filesystem based on anonymous memory. This is how it has been implemented on SunOS un 1987 and I am _very_ sure it works the same on Linux.
In other words: if you have files that lay around in /tmp. this just eats up swap.
It can still fill up. Well, so far it was not mentioned how big the tmpfs will be. ciao Arvin -- Arvin Schnell, <aschnell@suse.com> Senior Software Engineer, Research & Development SUSE Software Solutions Germany GmbH Maxfeldstraße 5 90409 Nürnberg Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Fri, Jul 10, Arvin Schnell wrote:
On Fri, Jul 10, 2020 at 12:34:01PM +0200, Joerg Schilling wrote:
Jan Engelhardt <jengelh@inai.de> wrote:
/tmp is one of the weirder places in a system.
It is nice that FHS says it is not persistent across reboots, but if you have a workstation or server which is "never" (or at least, seldomly) rebooted, the directory can still fill up - and take away RAM from both oneself and other users.
tmpfs is not a RAM file system but a filesystem based on anonymous memory. This is how it has been implemented on SunOS un 1987 and I am _very_ sure it works the same on Linux.
In other words: if you have files that lay around in /tmp. this just eats up swap.
It can still fill up.
Correct. And today it can fill up your root partition preventing you from login or update to your system. So what? Thorsten
Well, so far it was not mentioned how big the tmpfs will be.
ciao Arvin
-- Arvin Schnell, <aschnell@suse.com> Senior Software Engineer, Research & Development
SUSE Software Solutions Germany GmbH Maxfeldstraße 5 90409 Nürnberg Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany Managing Director: Felix Imendoerffer (HRB 36809, AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Fri, 2020-07-10 at 12:26 +0200, Jan Engelhardt wrote:
/tmp is one of the weirder places in a system.
It is nice that FHS says it is not persistent across reboots, but if you have a workstation or server which is "never" (or at least, seldomly) rebooted, the directory can still fill up - and take away RAM from both oneself and other users.
Firefox for example has the very bad habit of dumping all its .xpi file downloads into /tmp, and not cleaning them.
Users have bad habit :^) in abusing /tmp as the shortest way to store a file in a known location for some time - because any other location would be persistent (but /tmp might be too heh) and the path much longer.
The POSIX standard (aka IEEE P1003.2) makes it a hard requirement that any application should not assume that /tmp is persistant between *application executations* never mind between reboots. I do not think we should be catering for use cases that totally breach the oldest core tenants of how things should be done. /tmp shouldn't be persistant, keeping the contents around in memory until the next reboot is still generous. At some point we should reserve the right to just say 'no' to horrifically bad practice. I feel this is one of those cases, especially as even conserative platforms like Debian made this jump years ago.
Another thought that crossed my mind is making systemd set up a PrivateTmp for login sessions, i.e. make /tmp a bind mount to the users home dir, so it does actually account towards their disk quota.
Applications that want to use the users home directory can use $XDG_CACHE_HOME, like firefox does when delivered by flatpak for example. That would be more sensible than potentially relocating tmp files intended for the system scope to a users home directory. -- Richard Brown Linux Distribution Engineer - Future Technology Team Phone +4991174053-361 SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, D-90409 Nuernberg (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Richard Brown wrote:
On Fri, 2020-07-10 at 12:26 +0200, Jan Engelhardt wrote: [...]
Another thought that crossed my mind is making systemd set up a PrivateTmp for login sessions, i.e. make /tmp a bind mount to the users home dir, so it does actually account towards their disk quota.
Applications that want to use the users home directory can use $XDG_CACHE_HOME, like firefox does when delivered by flatpak for example.
That would be more sensible than potentially relocating tmp files intended for the system scope to a users home directory.
Filling ~ with lots of unimportant data also sucks when it's is on NFS (oh yeah, that still exists :-)), esp when there's a quota. At some point I got annoyed by that so played with this: https://github.com/lnussel/pam_usertmp cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Software Solutions Germany GmbH, HRB 36809 (AG Nürnberg), GF: Felix Imendörffer -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Friday 2020-07-10 13:27, Ludwig Nussel wrote:
Richard Brown wrote:
On Fri, 2020-07-10 at 12:26 +0200, Jan Engelhardt wrote: [...]
Another thought that crossed my mind is making systemd set up a PrivateTmp for login sessions, i.e. make /tmp a bind mount to the users home dir, so it does actually account towards their disk quota.
Applications that want to use the users home directory can use $XDG_CACHE_HOME
Filling ~ with lots of unimportant data also sucks when it's is on NFS (oh yeah, that still exists :-))
But that is why you have XDG_CACHE_HOME - so you can set it to /tmp/user25121 or something if and when your $HOME is on NFS.
I played with this: https://github.com/lnussel/pam_usertmp
If it helps to get rid of bad user habits, I am very open to have clone(2) enhanced with adding a tmpfs mount, so that the temp files are gone as soon as exit(2) is invoked. Let all the crapware break :D -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Sat, Jul 11, 2020 at 11:51 AM Jan Engelhardt <jengelh@inai.de> wrote:
have clone(2) enhanced with adding a tmpfs mount, so that the temp files are gone as soon as exit(2) is invoked. Let all the crapware break :D
CLONE_BREAK_CRAPWARE will be very nice indeed.. but aren't there yet :-| -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Fri, Jul 10, 2020 at 12:37:02PM +0200, Richard Brown wrote:
On Fri, 2020-07-10 at 12:26 +0200, Jan Engelhardt wrote:
/tmp is one of the weirder places in a system.
It is nice that FHS says it is not persistent across reboots, but if you have a workstation or server which is "never" (or at least, seldomly) rebooted, the directory can still fill up - and take away RAM from both oneself and other users.
Firefox for example has the very bad habit of dumping all its .xpi file downloads into /tmp, and not cleaning them.
Users have bad habit :^) in abusing /tmp as the shortest way to store a file in a known location for some time - because any other location would be persistent (but /tmp might be too heh) and the path much longer.
The POSIX standard (aka IEEE P1003.2) makes it a hard requirement that any application should not assume that /tmp is persistant between *application executations* never mind between reboots.
I do not think we should be catering for use cases that totally breach the oldest core tenants of how things should be done.
/tmp shouldn't be persistant, keeping the contents around in memory until the next reboot is still generous.
At some point we should reserve the right to just say 'no' to horrifically bad practice. I feel this is one of those cases, especially as even conserative platforms like Debian made this jump years ago.
I believe Jan's point was something different: that even if an application does not expect its files in /tmp to persist between runs, it can still leave files behind when it finishes - either out of negligence or because it was terminated unexpectedly without proper cleanup. On systems with long times between reboots (tens of days or even more), one can accumulate quite a lot of stuff in /tmp. Michal Kubecek -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hi there, that is what I meant earlier. Please make it configurable. openSUSE was always about control over the system, with good defaults for good habits. But please let me configure to have bad habits for whatever reason there may be. The change should be easy by using a systemd.mount or a fstab-entry. I would very welcome this configurability. Cheers, Bernd Am 10.07.20 um 14:11 schrieb Michal Kubecek:
On Fri, Jul 10, 2020 at 12:37:02PM +0200, Richard Brown wrote: I believe Jan's point was something different: that even if an application does not expect its files in /tmp to persist between runs, it can still leave files behind when it finishes - either out of negligence or because it was terminated unexpectedly without proper cleanup. On systems with long times between reboots (tens of days or even more), one can accumulate quite a lot of stuff in /tmp.
Michal Kubecek -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 10.07.20 um 12:26 schrieb Jan Engelhardt:
SUSE systems used to have/have a cron job that would sweep /tmp every day and look for files 7 days or older and purge them, which I believe is still a good compromise considering the above longevity of /tmp _even if_ it were tmpfs-backed.
We don't seem to have that cron anymore either, do we? I have files from 2018 in my /tmp -- Dominik Heidler Maxfeldstr. 5, D-90409 Nuernberg, Germany Phone +49-911-74053-141 SUSE Software Solutions Germany GmbH GF: Felix Imendörffer (HRB 36809, AG Nürnberg) _________________________________________ ドミニク -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Dominik Heidler wrote:
Am 10.07.20 um 12:26 schrieb Jan Engelhardt:
SUSE systems used to have/have a cron job that would sweep /tmp every day and look for files 7 days or older and purge them, which I believe is still a good compromise considering the above longevity of /tmp _even if_ it were tmpfs-backed.
We don't seem to have that cron anymore either, do we? I have files from 2018 in my /tmp
https://github.com/openSUSE/systemd/commit/671e2bfc7fd41fe0fde3d508a1f84c9b1... cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Software Solutions Germany GmbH, HRB 36809 (AG Nürnberg), GF: Felix Imendörffer -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 10.07.20 um 13:19 schrieb Ludwig Nussel:
Dominik Heidler wrote:
Am 10.07.20 um 12:26 schrieb Jan Engelhardt:
SUSE systems used to have/have a cron job that would sweep /tmp every day and look for files 7 days or older and purge them, which I believe is still a good compromise considering the above longevity of /tmp _even if_ it were tmpfs-backed.
We don't seem to have that cron anymore either, do we? I have files from 2018 in my /tmp
https://github.com/openSUSE/systemd/commit/671e2bfc7fd41fe0fde3d508a1f84c9b1...
"SUSE policy"? I wonder what the reason was behind that decision. -- Dominik Heidler Maxfeldstr. 5, D-90409 Nuernberg, Germany Phone +49-911-74053-141 SUSE Software Solutions Germany GmbH GF: Felix Imendörffer (HRB 36809, AG Nürnberg) _________________________________________ ドミニク -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 10.07.2020 um 13:21 schrieb Dominik Heidler:
https://github.com/openSUSE/systemd/commit/671e2bfc7fd41fe0fde3d508a1f84c9b1...
"SUSE policy"? I wonder what the reason was behind that decision.
A very heated discussion after several people relying on SUSE's previous defaults lost data when switching to systemd's default. It's hard to kill old habits. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 10/07/2020 13.25, Stephan Kulow wrote:
Am 10.07.2020 um 13:21 schrieb Dominik Heidler:
https://github.com/openSUSE/systemd/commit/671e2bfc7fd41fe0fde3d508a1f84c9b1...
"SUSE policy"? I wonder what the reason was behind that decision.
A very heated discussion after several people relying on SUSE's previous defaults lost data when switching to systemd's default.
It's hard to kill old habits.
Exactly, and we are having that discussion again :-( -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
Hello, On 2020-07-10 14:19, Carlos E. R. wrote:
On 10/07/2020 13.25, Stephan Kulow wrote:
Am 10.07.2020 um 13:21 schrieb Dominik Heidler:
https://github.com/openSUSE/systemd/commit/671e2bfc7fd41fe0fde3d508a1f84c9b1...
"SUSE policy"? I wonder what the reason was behind that decision.
A very heated discussion after several people relying on SUSE's previous defaults lost data when switching to systemd's default.
It's hard to kill old habits.
Exactly, and we are having that discussion again :-(
RFC 1925 item (11) https://tools.ietf.org/html/rfc1925 ;-) The problem is when an old idea is proposed again without providing a solution of its old issues. Kind Regards Johannes Meixner -- SUSE Software Solutions Germany GmbH Maxfeldstr. 5 - 90409 Nuernberg - Germany (HRB 36809, AG Nuernberg) GF: Felix Imendoerffer -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 10/07/2020 14.43, Johannes Meixner wrote:
Hello,
On 2020-07-10 14:19, Carlos E. R. wrote:
On 10/07/2020 13.25, Stephan Kulow wrote:
Am 10.07.2020 um 13:21 schrieb Dominik Heidler:
https://github.com/openSUSE/systemd/commit/671e2bfc7fd41fe0fde3d508a1f84c9b1...
"SUSE policy"? I wonder what the reason was behind that decision.
A very heated discussion after several people relying on SUSE's previous defaults lost data when switching to systemd's default.
It's hard to kill old habits.
Exactly, and we are having that discussion again :-(
RFC 1925 item (11) https://tools.ietf.org/html/rfc1925 ;-)
:-D
The problem is when an old idea is proposed again without providing a solution of its old issues.
Methinks it would be nice to have a daemon that would assign a dedicated memory cache to a directory, fixed size. Kind of mmap. A mount option, perhaps. The files would be accessed in ram if small, but remain on disk. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
Hello, On 2020-07-17 13:12, Carlos E. R. wrote:
Methinks it would be nice to have a daemon that would assign a dedicated memory cache to a directory, fixed size. Kind of mmap. A mount option, perhaps. The files would be accessed in ram if small, but remain on disk.
I think such kind of "daemon" already exists and is already active all the time: It is the kernel's buffer cache. Kind Regards Johannes Meixner -- SUSE Software Solutions Germany GmbH Maxfeldstr. 5 - 90409 Nuernberg - Germany (HRB 36809, AG Nuernberg) GF: Felix Imendoerffer -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 17/07/2020 13.50, Johannes Meixner wrote:
Hello,
On 2020-07-17 13:12, Carlos E. R. wrote:
Methinks it would be nice to have a daemon that would assign a dedicated memory cache to a directory, fixed size. Kind of mmap. A mount option, perhaps. The files would be accessed in ram if small, but remain on disk.
I think such kind of "daemon" already exists and is already active all the time: It is the kernel's buffer cache.
Not exactly. The kernel's buffer cache does it, but system wide, dynamically assigning the buffers to the recent activity. If you copy dvd image to another place, for instance, the buffers effectively disappear. For example, on some machines, copying the install image to an slow usb stick makes the entire machine slow, because the file copy fills 4 gigs of ram, destroying the existing buffers and making the entire filesystem slow as molasses. My idea is different, buffers dedicated to a sole directory, or perhaps to a mount, that can not be repurposed by the kernel to serve some other disk activity. Thus the /tmp directory would act as if it was hosted on ram entirely, except when/if big files were written. Call it an hybrid tmpfs perhaps, with persistence. With a configurable limit on ram used. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
On Friday 2020-07-17 14:17, Carlos E. R. wrote:
My idea is different, buffers dedicated to a sole directory, or perhaps to a mount, that can not be repurposed by the kernel to serve some other disk activity. Thus the /tmp directory would act as if it was hosted on ram entirely, except when/if big files were written.
Call it an hybrid tmpfs perhaps, with persistence. With a configurable limit on ram used.
If you want /tmp in non-swappable memory, nothing is stopping you from using "ramfs" instead of "tmpfs". -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 17/07/2020 15.33, Jan Engelhardt wrote:
On Friday 2020-07-17 14:17, Carlos E. R. wrote:
My idea is different, buffers dedicated to a sole directory, or perhaps to a mount, that can not be repurposed by the kernel to serve some other disk activity. Thus the /tmp directory would act as if it was hosted on ram entirely, except when/if big files were written.
Call it an hybrid tmpfs perhaps, with persistence. With a configurable limit on ram used.
If you want /tmp in non-swappable memory, nothing is stopping you from using "ramfs" instead of "tmpfs".
No, that is not what I said. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
Am 10.07.20 um 13:19 schrieb Ludwig Nussel:
https://github.com/openSUSE/systemd/commit/671e2bfc7fd41fe0fde3d508a1f84c9b1...
Interestingly that file was removed due to <https://bugzilla.opensuse.org/show_bug.cgi?id=1078466>, so there is currently no entry for /tmp at all, unless I'm missing something. Was that intended? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Fri, Jul 10, Jan Engelhardt wrote:
/tmp is one of the weirder places in a system.
It is nice that FHS says it is not persistent across reboots, but if you have a workstation or server which is "never" (or at least, seldomly) rebooted, the directory can still fill up - and take away RAM from both oneself and other users.
We analyzed many systems for that. On standard servers (if the admin does not do stupid things like storing many installations DVD in /tmp or so or use it as Desktop), /tmp is nearly empty.
Firefox for example has the very bad habit of dumping all its .xpi file downloads into /tmp, and not cleaning them.
Firefox is the only left over application writing things in /tmp and don't clean up for a long time on standard installations. The second one is "go", if you abort the build process. But that's the exception.
Users have bad habit :^) in abusing /tmp as the shortest way to store a file in a known location for some time - because any other location would be persistent (but /tmp might be too heh) and the path much longer.
Now they have to learn that they have a home directory for storing files and /tmp was always a bad idea. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany Managing Director: Felix Imendoerffer (HRB 36809, AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hi Thorsten, I totally agree that it is a bad idea. Still I am using it that way. I put data there, which i might need the next day, but often not longer. And I want it to be gone after a while. And a self cleaning tmp (after some days) was perfect for that :-) Cheers, Bernd Am 10.07.20 um 18:00 schrieb Thorsten Kukuk:
Users have bad habit :^) in abusing /tmp as the shortest way to store a file in a known location for some time - because any other location would be persistent (but /tmp might be too heh) and the path much longer. Now they have to learn that they have a home directory for storing files and /tmp was always a bad idea.
Thorsten -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Fri, Jul 10, Bernd Ritter wrote:
Hi Thorsten,
I totally agree that it is a bad idea. Still I am using it that way. I put data there, which i might need the next day, but often not longer. And I want it to be gone after a while. And a self cleaning tmp (after some days) was perfect for that :-)
enabling systemd automatic cleaning for /tmp should work even with tmpfs, and don't reboot. Thorsten
Cheers,
Bernd
Am 10.07.20 um 18:00 schrieb Thorsten Kukuk:
Users have bad habit :^) in abusing /tmp as the shortest way to store a file in a known location for some time - because any other location would be persistent (but /tmp might be too heh) and the path much longer. Now they have to learn that they have a home directory for storing files and /tmp was always a bad idea.
Thorsten -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany Managing Director: Felix Imendoerffer (HRB 36809, AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 10. 07. 20, 18:00, Thorsten Kukuk wrote:
On Fri, Jul 10, Jan Engelhardt wrote:
/tmp is one of the weirder places in a system.
It is nice that FHS says it is not persistent across reboots, but if you have a workstation or server which is "never" (or at least, seldomly) rebooted, the directory can still fill up - and take away RAM from both oneself and other users.
We analyzed many systems for that. On standard servers (if the admin does not do stupid things like storing many installations DVD in /tmp or so or use it as Desktop), /tmp is nearly empty.
Not sure what servers you are talking about, but one of our development servers: # uptime 09:53:46 up 156 days 9:43, 5 users, load average: 0.13, 0.31, 0.25 # du -sh /tmp/ 30G /tmp/
Firefox for example has the very bad habit of dumping all its .xpi file downloads into /tmp, and not cleaning them.
Firefox is the only left over application writing things in /tmp and don't clean up for a long time on standard installations. The second one is "go", if you abort the build process. But that's the exception.
Sure. If you use only firefox and go. So after all those 8 years, firefox is not fixed yet, right? I really don't like the idea that after a quick reboot or kexec I can no longer open documents from download history. Yes, let's fix firefox first (at last).
Users have bad habit :^) in abusing /tmp as the shortest way to store a file in a known location for some time - because any other location would be persistent (but /tmp might be too heh) and the path much longer.
Now they have to learn that they have a home directory for storing files and /tmp was always a bad idea.
Why would I store an iso file to ~? I usually need it exactly 3 seconds: to do a loop mount. 3 seconds is temporary enough, isn't it? Or firefox downloads for me kernel-debuginfo (over 1G) and I *open* it in Ark (not save it). So it ends up in /tmp/ too (see above). So no, /tmp still should not be a tmpfs by default for everybody: 1) there are still brand new machines with only 1G of RAM installed. 2) /tmp is used for storing large files by users or firefox. In sum, there are scenarios where /tmp on tmpfs makes sense. Like machines with big enough RAM. So make it default on those and opt-in during installation too. thanks, -- js suse labs -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Le jeudi 16 juillet 2020 à 10:16 +0200, Jiri Slaby a écrit :
On 10. 07. 20, 18:00, Thorsten Kukuk wrote:
On Fri, Jul 10, Jan Engelhardt wrote:
/tmp is one of the weirder places in a system.
It is nice that FHS says it is not persistent across reboots, but if you have a workstation or server which is "never" (or at least, seldomly) rebooted, the directory can still fill up - and take away RAM from both oneself and other users.
We analyzed many systems for that. On standard servers (if the admin does not do stupid things like storing many installations DVD in /tmp or so or use it as Desktop), /tmp is nearly empty.
Not sure what servers you are talking about, but one of our development servers: # uptime 09:53:46 up 156 days 9:43, 5 users, load average: 0.13, 0.31, 0.25 # du -sh /tmp/ 30G /tmp/
Firefox for example has the very bad habit of dumping all its .xpi file downloads into /tmp, and not cleaning them.
Firefox is the only left over application writing things in /tmp and don't clean up for a long time on standard installations. The second one is "go", if you abort the build process. But that's the exception.
Sure. If you use only firefox and go.
So after all those 8 years, firefox is not fixed yet, right? I really don't like the idea that after a quick reboot or kexec I can no longer open documents from download history. Yes, let's fix firefox first (at last).
Users have bad habit :^) in abusing /tmp as the shortest way to store a file in a known location for some time - because any other location would be persistent (but /tmp might be too heh) and the path much longer.
Now they have to learn that they have a home directory for storing files and /tmp was always a bad idea.
Why would I store an iso file to ~? I usually need it exactly 3 seconds: to do a loop mount. 3 seconds is temporary enough, isn't it?
Why not use /var/tmp ?
Or firefox downloads for me kernel-debuginfo (over 1G) and I *open* it in Ark (not save it). So it ends up in /tmp/ too (see above).
So no, /tmp still should not be a tmpfs by default for everybody: 1) there are still brand new machines with only 1G of RAM installed. 2) /tmp is used for storing large files by users or firefox.
It would make sense to fix Firefox to use /var/tmp instead of /tmp for such case (or XDG_CACHE_DIR).
In sum, there are scenarios where /tmp on tmpfs makes sense. Like machines with big enough RAM. So make it default on those and opt-in during installation too.
15 years ago, in Mandriva/Mandrake Linux, for some security sensitive setup, we were setting TMPDIR to $HOME/tmp (which was causing some issues for applications which were expecting TMPDIR = /tmp, like ORBit but those were fixed). I'm wondering if we should use it on openSUSE ? -- Frederic Crozat Release Manager SUSE Linux Enterprise SUSE
On Thu, Jul 16, 2020 at 08:52, Frederic Crozat <FCrozat@suse.com> wrote:
Le jeudi 16 juillet 2020 à 10:16 +0200, Jiri Slaby a écrit :
Or firefox downloads for me kernel-debuginfo (over 1G) and I *open* it in Ark (not save it). So it ends up in /tmp/ too (see above).
So no, /tmp still should not be a tmpfs by default for everybody: 1) there are still brand new machines with only 1G of RAM installed. 2) /tmp is used for storing large files by users or firefox.
It would make sense to fix Firefox to use /var/tmp instead of /tmp for such case (or XDG_CACHE_DIR).
I disagree that user specific download history should be in a shared directory. Firefox should be able to: a) have per user download history b) clean that download history when it's cleaned from the interface and when files no longer exist in the cache directory Moving download history to ~/.cache/firefox seems like a better idea. LCP [Stasiek] https://lcp.world -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Le jeudi 16 juillet 2020 à 11:11 +0200, Stasiek Michalski a écrit :
On Thu, Jul 16, 2020 at 08:52, Frederic Crozat <FCrozat@suse.com> wrote:
Le jeudi 16 juillet 2020 à 10:16 +0200, Jiri Slaby a écrit :
Or firefox downloads for me kernel-debuginfo (over 1G) and I *open* it in Ark (not save it). So it ends up in /tmp/ too (see above).
So no, /tmp still should not be a tmpfs by default for everybody: 1) there are still brand new machines with only 1G of RAM installed. 2) /tmp is used for storing large files by users or firefox.
It would make sense to fix Firefox to use /var/tmp instead of /tmp for such case (or XDG_CACHE_DIR).
I disagree that user specific download history should be in a shared directory.
Right now, this directory is only accessible by the user (and root, obviously). I'm pretty sure the current behavior is just a side-effect of Firefox using TMPDIR as default (confirmed by https://dxr.mozilla.org/mozilla-release/source/xpcom/io/SpecialSystemDirecto...
Firefox should be able to: a) have per user download history b) clean that download history when it's cleaned from the interface and when files no longer exist in the cache directory
This should be reported to Mozilla, I think.
Moving download history to ~/.cache/firefox seems like a better idea.
Currently, Fedora is overriding TMPDIR="$XDG_CACHE_HOME/tmp"|' byt only when they build rpm to be put into flatpak. -- Frederic Crozat Release Manager SUSE Linux Enterprise SUSE
On 16/07/2020 11.11, Stasiek Michalski wrote:
On Thu, Jul 16, 2020 at 08:52, Frederic Crozat <FCrozat@suse.com> wrote:
Le jeudi 16 juillet 2020 à 10:16 +0200, Jiri Slaby a écrit :
Or firefox downloads for me kernel-debuginfo (over 1G) and I *open* it in Ark (not save it). So it ends up in /tmp/ too (see above).
So no, /tmp still should not be a tmpfs by default for everybody: 1) there are still brand new machines with only 1G of RAM installed. 2) /tmp is used for storing large files by users or firefox.
It would make sense to fix Firefox to use /var/tmp instead of /tmp for such case (or XDG_CACHE_DIR).
I disagree that user specific download history should be in a shared directory. Firefox should be able to: a) have per user download history b) clean that download history when it's cleaned from the interface and when files no longer exist in the cache directory
Moving download history to ~/.cache/firefox seems like a better idea.
There are advantages for having all users save their temporary FF on /tmp: that a system cron script can automatically delete old files from /tmp. It is much more difficult to do that on /home/*. Another thing I just found: vmware saves log files to /tmp. I have /tmp/vmware-root/ full of log files. It would be bad if after a crash the logs were deleted on reboot. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
On Friday 2020-07-17 14:29, Carlos E. R. wrote:
There are advantages for having all users save their temporary FF on /tmp: that a system cron script can automatically delete old files from /tmp. It is much more difficult to do that on /home/*.
Ironically, there is already a /usr/lib/systemd/user/systemd-tmpfiles-clean.timer which exists to faciliate just that. It is not active by default, and there is no shipped config file that says which paths to clean, though. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hello, On 2020-07-16 10:52, Frederic Crozat wrote:
Why not use /var/tmp ?
https://en.opensuse.org/openSUSE:Tmp_on_tmpfs#.2Ftmp.2F_versus_.2Fvar.2Ftmp.... Kind Regards Johannes Meixner -- SUSE Software Solutions Germany GmbH Maxfeldstr. 5 - 90409 Nuernberg - Germany (HRB 36809, AG Nuernberg) GF: Felix Imendoerffer -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Frederic Crozat <FCrozat@suse.com> writes:
15 years ago, in Mandriva/Mandrake Linux, for some security sensitive setup, we were setting TMPDIR to $HOME/tmp (which was causing some issues for applications which were expecting TMPDIR = /tmp, like ORBit but those were fixed). I'm wondering if we should use it on openSUSE ?
I guess this would be a potential application of Ludwig's pam_usertmp: https://github.com/lnussel/pam_usertmp Cheers, Dan -- Dan Čermák <dcermak@suse.com> Software Engineer Development tools SUSE Software Solutions Germany GmbH Maxfeldstr. 5 90409 Nuremberg Germany (HRB 36809, AG Nürnberg) Managing Director: Felix Imendörffer
On Thu, Jul 16, Jiri Slaby wrote:
Not sure what servers you are talking about, but one of our development servers: # uptime 09:53:46 up 156 days 9:43, 5 users, load average: 0.13, 0.31, 0.25 # du -sh /tmp/ 30G /tmp/
We looked at our production servers. So well maintained and always having the latest security fixes applied (which includes the latest kernel running). What do you have on that machine which is so big?
Sure. If you use only firefox and go.
So after all those 8 years, firefox is not fixed yet, right? I really don't like the idea that after a quick reboot or kexec I can no longer open documents from download history. Yes, let's fix firefox first (at last).
Use the XDG variables to let Firefox use ~/.cache for this data. Your expection is in conflict with FHS and standard behavior on (nearly) all other Linux distributions. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany Managing Director: Felix Imendoerffer (HRB 36809, AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thu, Jul 16, 2020 at 10:16:43AM +0200, Jiri Slaby wrote:
Not sure what servers you are talking about, but one of our development servers: # uptime 09:53:46 up 156 days 9:43, 5 users, load average: 0.13, 0.31, 0.25 # du -sh /tmp/ 30G /tmp/
If you mean noe then "server" may be a bit misleading here: noe:/dev/shm # du -sm /tmp 28627 /tmp noe:/dev/shm # du -sm /tmp/mc-mhocko /tmp/kernelbuild-pmladek /tmp/kernelbuild-mhocko 19752 /tmp/mc-mhocko 6508 /tmp/kernelbuild-pmladek 1874 /tmp/kernelbuild-mhocko noe:/dev/shm # echo $[28627 - 19752 - 6508 - 1874] 493 Here mc-mhocko contains some big cpio archives, my guess is that these were left behind by mc after opening rpm packages. And kenrelbuild-* contain package caches and buildroots, most likely from "osc build" (perhaps osc_wrapper?). Other (smaller) big directories have similar contents. In other words, mostly result of interactive activity of local users. Michal -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Fri, Jul 17, 2020 at 6:54 AM Michal Kubecek <mkubecek@suse.cz> wrote:
Here mc-mhocko contains some big cpio archives, my guess is that these were left behind by mc after opening rpm packages.
Then we need to fix MC not to write there, or better said..track down all known buggy apps. what should one use to audit /tmp usage ? systemtap? the audit subsys ? kprobes? an LSM I do not know about ? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Friday 2020-07-17 14:14, Cristian Rodríguez wrote:
On Fri, Jul 17, 2020 at 6:54 AM Michal Kubecek <mkubecek@suse.cz> wrote:
Here mc-mhocko contains some big cpio archives, my guess is that these were left behind by mc after opening rpm packages.
Then we need to fix MC not to write there, or better said..track down all known buggy apps.
what should one use to audit /tmp usage ? systemtap? the audit subsys ? kprobes? an LSM I do not know about ?
`strace -e open,openat` alone would already be a start. Or you can chmod 555 /tmp and watch the error messages. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Fri, Jul 17, 2020 at 9:34 AM Jan Engelhardt <jengelh@inai.de> wrote:
`strace -e open,openat` alone would already be a start. Or you can chmod 555 /tmp and watch the error messages.
Of course this came to mind.. but I was looking at a system-wide thing that could possibly run at very early boot and maybe raise Cthulhu if something lame like fopen("/tmp/fixednamewithoutdotrandompart". "wb") is used by an application . -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Fri, 2020-07-17 at 09:56 -0400, Cristian Rodríguez wrote:
Of course this came to mind.. but I was looking at a system-wide thing that could possibly run at very early boot and maybe raise Cthulhu if something lame like fopen("/tmp/fixednamewithoutdotrandompart". "wb") is used by an application .
There's the LD_PRELOAD-based PathAuditor [1]. It would be interesting to see if it can boot up a full openSUSE system, and what it finds. 1: https://github.com/google/path-auditor -- Malte Kraus <malte.kraus@suse.com> Security Engineer PGP Key: 8AFC 3C58 6880 2DDD 4792 C3C2 FDBD 2984 D4C3 C2F0 SUSE Software Solutions Germany GmbH / Maxfeldstr. 5 / 90409 Nürnberg / Germany / (HRB 36809, AG Nürnberg) / Geschäftsführer: Felix Imendörffer -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Fri, Jul 17, 2020 at 10:14 AM Malte Kraus <malte.kraus@suse.com> wrote:
There's the LD_PRELOAD-based PathAuditor [1]. It would be interesting to see if it can boot up a full openSUSE system, and what it finds.
Thanks!, that may as well do the job lacking a kernel level auditor which AFAIK will be much better. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Fri, Jul 17, 2020 at 10:14 AM Malte Kraus <malte.kraus@suse.com> wrote:
On Fri, 2020-07-17 at 09:56 -0400, Cristian Rodríguez wrote:
Of course this came to mind.. but I was looking at a system-wide thing that could possibly run at very early boot and maybe raise Cthulhu if something lame like fopen("/tmp/fixednamewithoutdotrandompart". "wb") is used by an application .
There's the LD_PRELOAD-based PathAuditor [1]. It would be interesting to see if it can boot up a full openSUSE system, and what it finds.
cat Dockerfile FROM opensuse/tumbleweed RUN zypper -n install --no-recommends gcc-c++ bazel systemd strace vim gdb COPY . /pathauditor/ RUN cd /pathauditor && bazel build //pathauditor/libc:libpath_auditor.so RUN echo "/pathauditor/bazel-bin/pathauditor/libc/libpath_auditor.so"
/etc/ld.so.preload CMD [ "/usr/lib/systemd/systemd" ]
kinda works with podman (because docker does not play nice with systemd) in the initial boot some false positives shown and UTS namespace didn't work for me, but could otherwise be used to find some interesting problems in apps ;) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 10/07/2020 18.00, Thorsten Kukuk wrote:
On Fri, Jul 10, Jan Engelhardt wrote:
Users have bad habit :^) in abusing /tmp as the shortest way to store a file in a known location for some time - because any other location would be persistent (but /tmp might be too heh) and the path much longer.
Now they have to learn that they have a home directory for storing files and /tmp was always a bad idea.
/home doesn't fit if one wants the file to be accessible by other people. For instance, when I want to attach a file to a bugzilla, and the file is owned by root, I first copy that file to /tmp so that my user FF can read it and attach it. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
On Fri, 17 Jul 2020 14:20:42 +0200 Carlos E. R. wrote:
For instance, when I want to attach a file to a bugzilla, and the file is owned by root, I first copy that file to /tmp so that my user FF can read it and attach it.
but what should keep root from copying the file directly to your home directory where your user FF can read it and attach it? In the worst case root can chown and chmod the copied file so it is readable for you. Regards, Dieter -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 17/07/2020 14.33, dieter wrote:
On Fri, 17 Jul 2020 14:20:42 +0200 Carlos E. R. wrote:
For instance, when I want to attach a file to a bugzilla, and the file is owned by root, I first copy that file to /tmp so that my user FF can read it and attach it.
but what should keep root from copying the file directly to your home directory where your user FF can read it and attach it?
That in /tmp it will be seen and deleted at some point. That /tmp is much shorter to write, twice. Reminds me: Telcontar:~ # save_y2logs Saving YaST logs to /tmp/y2log-Io0UJg.tar.xz Telcontar:~ # (17 megs)
In the worst case root can chown and chmod the copied file so it is readable for you.
I can not (should not) do that with the system directories where it is stored. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
On Fri, 17 Jul 2020 14:59:59 +0200 Carlos E. R. wrote:
On 17/07/2020 14.33, dieter wrote:
On Fri, 17 Jul 2020 14:20:42 +0200 Carlos E. R. wrote:
For instance, when I want to attach a file to a bugzilla, and the file is owned by root, I first copy that file to /tmp so that my user FF can read it and attach it.
but what should keep root from copying the file directly to your home directory where your user FF can read it and attach it?
That in /tmp it will be seen and deleted at some point. That /tmp is much shorter to write, twice. Does it make sense to keep it after you uploaded it? If not you can just delete it after you uploaded it. Or occasionally check your home directory for cruft.
Reminds me:
Telcontar:~ # save_y2logs Saving YaST logs to /tmp/y2log-Io0UJg.tar.xz Telcontar:~ #
(17 megs) If you have a script already to do it then it is a one time effort to modify the destination.
In the worst case root can chown and chmod the copied file so it is readable for you.
I can not (should not) do that with the system directories where it is stored. Seems I was not clear enough, sorry, I meant to "chown and chmod the copied file" at the destination it was copied to.
As I understand it the proposed change to tmpfs is a default configuration option. A user(the administrator of the system) can keep the /tmp directory if he prefers. I do not know yet how to decide myself. But it makes sense to every now and then rethink old habits. And very likely there is no "one setting fits all needs" way to configure it. Regards, Dieter -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 17/07/2020 16.03, dieter wrote:
On Fri, 17 Jul 2020 14:59:59 +0200 Carlos E. R. wrote:
On 17/07/2020 14.33, dieter wrote:
On Fri, 17 Jul 2020 14:20:42 +0200 Carlos E. R. wrote:
For instance, when I want to attach a file to a bugzilla, and the file is owned by root, I first copy that file to /tmp so that my user FF can read it and attach it.
but what should keep root from copying the file directly to your home directory where your user FF can read it and attach it?
That in /tmp it will be seen and deleted at some point. That /tmp is much shorter to write, twice. Does it make sense to keep it after you uploaded it? If not you can just delete it after you uploaded it.
Certainly, but one forgets. The user can not delete it, anyway, it's owned by root.
Or occasionally check your home directory for cruft.
See above :-)
Reminds me:
Telcontar:~ # save_y2logs Saving YaST logs to /tmp/y2log-Io0UJg.tar.xz Telcontar:~ #
(17 megs) If you have a script already to do it then it is a one time effort to modify the destination.
It is not my script. <https://en.opensuse.org/openSUSE:Report_a_YaST_bug>
In the worst case root can chown and chmod the copied file so it is readable for you.
I can not (should not) do that with the system directories where it is stored. Seems I was not clear enough, sorry, I meant to "chown and chmod the copied file" at the destination it was copied to.
Well, yes.
As I understand it the proposed change to tmpfs is a default configuration option. A user(the administrator of the system) can keep the /tmp directory if he prefers. I do not know yet how to decide myself. But it makes sense to every now and then rethink old habits. And very likely there is no "one setting fits all needs" way to configure it.
I much prefer not to change things. Those that so desire, can do. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
On Fri, Jul 17, 2020 at 07:54:09PM +0200, Carlos E. R. wrote:
On 17/07/2020 16.03, dieter wrote:
On Fri, 17 Jul 2020 14:59:59 +0200 Carlos E. R. wrote:
On 17/07/2020 14.33, dieter wrote:
On Fri, 17 Jul 2020 14:20:42 +0200 Carlos E. R. wrote:
For instance, when I want to attach a file to a bugzilla, and the file is owned by root, I first copy that file to /tmp so that my user FF can read it and attach it.
but what should keep root from copying the file directly to your home directory where your user FF can read it and attach it?
That in /tmp it will be seen and deleted at some point. That /tmp is much shorter to write, twice. Does it make sense to keep it after you uploaded it? If not you can just delete it after you uploaded it.
Certainly, but one forgets. The user can not delete it, anyway, it's owned by root.
Or occasionally check your home directory for cruft.
See above :-)
Really? lion:~ # touch ~mike/foo lion:~ # ls -l ~mike/foo -rw-r--r-- 1 root root 0 Jul 17 22:46 /home/mike/foo mike@lion:~> ls -l foo -rw-r--r-- 1 root root 0 Jul 17 22:46 foo mike@lion:~> rm -v foo rm: remove write-protected regular empty file 'foo'? y removed 'foo' mike@lion:~> ls -l foo ls: cannot access 'foo': No such file or directory Ironically, what you said would be true ... in /tmp (or any other directory with "t" bit set in its permissions). Michal Kubecek -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 17/07/2020 22.51, Michal Kubecek wrote:
On Fri, Jul 17, 2020 at 07:54:09PM +0200, Carlos E. R. wrote:
On 17/07/2020 16.03, dieter wrote:
On Fri, 17 Jul 2020 14:59:59 +0200 Carlos E. R. wrote:
On 17/07/2020 14.33, dieter wrote:
On Fri, 17 Jul 2020 14:20:42 +0200 Carlos E. R. wrote:
For instance, when I want to attach a file to a bugzilla, and the file is owned by root, I first copy that file to /tmp so that my user FF can read it and attach it.
but what should keep root from copying the file directly to your home directory where your user FF can read it and attach it?
That in /tmp it will be seen and deleted at some point. That /tmp is much shorter to write, twice. Does it make sense to keep it after you uploaded it? If not you can just delete it after you uploaded it.
Certainly, but one forgets. The user can not delete it, anyway, it's owned by root.
Or occasionally check your home directory for cruft.
See above :-)
Really?
lion:~ # touch ~mike/foo lion:~ # ls -l ~mike/foo -rw-r--r-- 1 root root 0 Jul 17 22:46 /home/mike/foo
mike@lion:~> ls -l foo -rw-r--r-- 1 root root 0 Jul 17 22:46 foo mike@lion:~> rm -v foo rm: remove write-protected regular empty file 'foo'? y removed 'foo' mike@lion:~> ls -l foo ls: cannot access 'foo': No such file or directory
Ok :-) But if I had saved the file to /home/cer/tmp, the user cron job would not purge it. I have not tried, though.
Ironically, what you said would be true ... in /tmp (or any other directory with "t" bit set in its permissions).
Yes, but a cron job would delete that eventually. Or myself in root mode eventually. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
Hello! On 7/10/20 11:49 AM, Richard Brown wrote:
Does anyone have any objections, concerns, thoughts?
I'm fine with the idea, but it would be nice if existing systems wouldn't be switched over without asking, so that there is no unexpected loss of data - I do happen to have dumped some stuff into /tmp that I still need and I assume other users might have done the same. Better be safe than sorry. It's definitely fine for new installations though. Adrian -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
John Paul Adrian Glaubitz wrote:
On 7/10/20 11:49 AM, Richard Brown wrote:
Does anyone have any objections, concerns, thoughts?
I'm fine with the idea, but it would be nice if existing systems wouldn't be switched over without asking,
Any creative idea how to do that with zypper dup?
so that there is no unexpected loss of data - I do happen to have dumped some stuff into /tmp that I still need and I assume other users might have done the same. Better be safe than sorry.
There would be no data loss. As Richard explained, no change on upgrade for btrfs systems that use the current defaults (tmp mounted from subvolume via fstab). Systems not using btrfs would get a tmpfs mount on top of the existing /tmp. So the content would still be there, just not visible. Which might be problem of it's own but regaining access should be as easy as "systemctl mask tmp.mount". cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Software Solutions Germany GmbH, HRB 36809 (AG Nürnberg), GF: Felix Imendörffer -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 7/10/20 1:18 PM, Ludwig Nussel wrote:
John Paul Adrian Glaubitz wrote:
On 7/10/20 11:49 AM, Richard Brown wrote:
Does anyone have any objections, concerns, thoughts?
I'm fine with the idea, but it would be nice if existing systems wouldn't be switched over without asking,
Any creative idea how to do that with zypper dup?
I don't know whether RPM supports that but Debian's debconf would allow to create a prompt to ask the user with the current setting as default. Does RPM have similar mechanisms?
so that there is no unexpected loss of data - I do happen to have dumped some stuff into /tmp that I still need and I assume other users might have done the same. Better be safe than sorry.
There would be no data loss. As Richard explained, no change on upgrade for btrfs systems that use the current defaults (tmp mounted from subvolume via fstab). Systems not using btrfs would get a tmpfs mount on top of the existing /tmp. So the content would still be there, just not visible. Which might be problem of it's own but regaining access should be as easy as "systemctl mask tmp.mount".
OK, sounds reasonable to me. Adrian -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Fri, Jul 10, 2020 at 7:21 AM John Paul Adrian Glaubitz <adrian.glaubitz@suse.com> wrote:
On 7/10/20 1:18 PM, Ludwig Nussel wrote:
John Paul Adrian Glaubitz wrote:
On 7/10/20 11:49 AM, Richard Brown wrote:
Does anyone have any objections, concerns, thoughts?
I'm fine with the idea, but it would be nice if existing systems wouldn't be switched over without asking,
Any creative idea how to do that with zypper dup?
I don't know whether RPM supports that but Debian's debconf would allow to create a prompt to ask the user with the current setting as default.
Does RPM have similar mechanisms?
RPM does not. Interactivity during package installation is antithetical to the ethos of RPM. -- 真実はいつも一つ！/ Always, there's only one truth! -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 7/10/20 1:23 PM, Neal Gompa wrote:
Does RPM have similar mechanisms?
RPM does not. Interactivity during package installation is antithetical to the ethos of RPM.
The interactivity of debconf is optional. You can also upgrade with non-interactively and either use presets or provide your desired configuration options using preseed files. Adrian -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Friday 2020-07-10 13:18, Ludwig Nussel wrote:
John Paul Adrian Glaubitz wrote:
On 7/10/20 11:49 AM, Richard Brown wrote:
Does anyone have any objections, concerns, thoughts?
I'm fine with the idea, but it would be nice if existing systems wouldn't be switched over without asking,
Any creative idea how to do that with zypper dup?
%post if [ "$(stat -c "%t" /tmp)" = 0 ]; then systemctl enable tmp.mount fi ? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 10.07.20 um 12:28 schrieb John Paul Adrian Glaubitz:
Hello!
On 7/10/20 11:49 AM, Richard Brown wrote:
Does anyone have any objections, concerns, thoughts?
I'm fine with the idea, but it would be nice if existing systems wouldn't be switched over without asking, so that there is no unexpected loss of data - I do happen to have dumped some stuff into /tmp that I still need and I assume other users might have done the same. Better be safe than sorry.
It will not get lost. Quite the contrary -- it will be very hard to (accidentally) delete stuff from the old /tmp ;-P ...wondering if I'm the only one who backs up the following directories before a reinstall: /etc /home /tmp ;-) -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 7/10/20 1:50 PM, Stefan Seyfried wrote:
Am 10.07.20 um 12:28 schrieb John Paul Adrian Glaubitz:
Hello!
On 7/10/20 11:49 AM, Richard Brown wrote:
Does anyone have any objections, concerns, thoughts?
I'm fine with the idea, but it would be nice if existing systems wouldn't be switched over without asking, so that there is no unexpected loss of data - I do happen to have dumped some stuff into /tmp that I still need and I assume other users might have done the same. Better be safe than sorry.
It will not get lost. Quite the contrary -- it will be very hard to (accidentally) delete stuff from the old /tmp ;-P
Which I consider a good thing. Dataloss should never happen during an upgrade.
...wondering if I'm the only one who backs up the following directories before a reinstall:
/etc /home /tmp
Same here. I also backup /opt, /srv/ and /var, depending on the machine. Adrian -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 10/07/2020 14.01, John Paul Adrian Glaubitz wrote:
On 7/10/20 1:50 PM, Stefan Seyfried wrote:
Am 10.07.20 um 12:28 schrieb John Paul Adrian Glaubitz:
...wondering if I'm the only one who backs up the following directories before a reinstall:
/etc /home /tmp
Same here. I also backup /opt, /srv/ and /var, depending on the machine.
I do a full backup. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
On 2020-07-10 07:50 AM, Stefan Seyfried wrote:
...wondering if I'm the only one who backs up the following directories before a reinstall:
/etc /home /tmp
I back up /etc, but /home is on a separate partition. In fact, back in the dark ages, when I had IDE drives, I had /home on a removable drive in a tray and would remove it during installs. I have also backed up other directories that contained things I wanted to retain. I never considered backing up /tmp, though it might have been during a regular backup. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Fri, Jul 10, 2020 at 5:49 AM Richard Brown <rbrown@suse.de> wrote:
Hello community,
We recently moved MicroOS and Kubic to use tmpfs for /tmp instead of writing files there to disk.
This means files written to /tmp as never written to disk and so dissapear on reboot.
This was for a number of reasons, including
- Reducing wear on SSDs/SD card storage - Using less disk space and being more tidy generally - Being more like many other Distro's and Unixes including Debian, Arch, Fedora, Solaris, etc - Being more consistant with the FHS recommendations that /tmp is flushed on reboot https://www.pathname.com/fhs/pub/fhs-2.3.html#TMPTEMPORARYFILES
All of these reasons also apply for regular openSUSE, so I would like to propose that Tumbleweed moves to tmpfs for /tmp soon also.
The impact should be minimal, as all POSIX compliant applications should already assume that /tmp is not persistant between invocations of the program.
As we're walking paths that other distros long have, my own research suggests that vast majority of problematic /tmp use has already been resolved, such as by using /var/tmp instead.
We will likely impliment this as systemd mount unit, meaning if people disable it then they will be able to return to the old behaviour.
Does anyone have any objections, concerns, thoughts?
So hilariously, I thought we already did this, and the fact we didn't actually caused problems in user support in the Discord community. So this gets a HUGE +1 for me. Let's do it! -- 真実はいつも一つ！/ Always, there's only one truth! -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hello, On 2020-07-10 11:49, Richard Brown wrote:
We recently moved MicroOS and Kubic to use tmpfs for /tmp instead of writing files there to disk.
I assume nowadays there are no issues with /tmp in RAM when applications need to temporarily store "something big" in particular on virtual machines that may not have much RAM. I ask because the old https://en.opensuse.org/openSUSE:Tmp_on_tmpfs mentiones "Applications that write huge files to /tmp/". Perhaps https://en.opensuse.org/openSUSE:Tmp_on_tmpfs could be updated to nowadays state or deleted when it is outdated. Kind Regards Johannes Meixner -- SUSE Software Solutions Germany GmbH Maxfeldstr. 5 - 90409 Nuernberg - Germany (HRB 36809, AG Nuernberg) GF: Felix Imendoerffer -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Fri, Jul 10, 2020 at 11:49:45AM +0200, Richard Brown wrote:
We recently moved MicroOS and Kubic to use tmpfs for /tmp instead of writing files there to disk.
[...]
All of these reasons also apply for regular openSUSE, so I would like to propose that Tumbleweed moves to tmpfs for /tmp soon also. [...] Does anyone have any objections, concerns, thoughts?
No objection to the general change but I would suggest two exceptions: 1. Systems where user created a specific mount point for /tmp (whether tmpfs or normal filesystem). According to the previous discussion, this should be taken care of already. 2. Systems with less memory than a certain threshold. I'm not sure what the threshold should be but I would be afraid to configure /tmp on tmpfs by default on systems with 4GB of RAM. 8GB might be OK, I have such configuration on my laptop with 8GB myself and didn't encounter any problems (but it took me quite some time to summon the courage). Michal Kubecek -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Fri, 10 Jul 2020 13:51:10 +0200, Michal Kubecek <mkubecek@suse.cz> wrote:
On Fri, Jul 10, 2020 at 11:49:45AM +0200, Richard Brown wrote:
Chiming in late, sorry
We recently moved MicroOS and Kubic to use tmpfs for /tmp instead of writing files there to disk. [...] All of these reasons also apply for regular openSUSE, so I would like to propose that Tumbleweed moves to tmpfs for /tmp soon also.
I would vehemently oppose, as we have 3rd-party applications that write to (NOT configurable) /tmp and expect it to last there for a certain time (even after a reboot). To workaround of that, I have created several symbolic links on /tmp to /data/tmp (or /opt/app/tmp or whatever) and I would be very unpleased to see all those symlinks disappear on a reboot. That would mean I have to write service files that fire up immediately after /tmp comes up and recreates those symlinks before the application wants to start. I really like to keep my /tmp's as clean as possible, but sometimes it is not under our control :( FWIW I never had to do anything like that on /usr/tmp
Does anyone have any objections, concerns, thoughts?
No objection to the general change but I would suggest two exceptions:
1. Systems where user created a specific mount point for /tmp (whether tmpfs or normal filesystem). According to the previous discussion, this should be taken care of already.
2. Systems with less memory than a certain threshold. I'm not sure what the threshold should be but I would be afraid to configure /tmp on tmpfs by default on systems with 4GB of RAM. 8GB might be OK, I have such configuration on my laptop with 8GB myself and didn't encounter any problems (but it took me quite some time to summon the courage).
:)
Michal Kubecek
-- H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/ using perl5.00307 .. 5.31 porting perl5 on HP-UX, AIX, and Linux https://useplaintext.email https://tux.nl http://www.test-smoke.org http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Fri, 2020-07-10 at 14:08 +0200, H.Merijn Brand wrote:
On Fri, 10 Jul 2020 13:51:10 +0200, Michal Kubecek <mkubecek@suse.cz> wrote:
On Fri, Jul 10, 2020 at 11:49:45AM +0200, Richard Brown wrote:
Chiming in late, sorry
We recently moved MicroOS and Kubic to use tmpfs for /tmp instead of writing files there to disk. [...] All of these reasons also apply for regular openSUSE, so I would like to propose that Tumbleweed moves to tmpfs for /tmp soon also.
I would vehemently oppose, as we have 3rd-party applications that write to (NOT configurable) /tmp and expect it to last there for a certain time (even after a reboot).
To workaround of that, I have created several symbolic links on /tmp to /data/tmp (or /opt/app/tmp or whatever) and I would be very unpleased to see all those symlinks disappear on a reboot. That would mean I have to write service files that fire up immediately after /tmp comes up and recreates those symlinks before the application wants to start.
I really like to keep my /tmp's as clean as possible, but sometimes it is not under our control :(
FWIW I never had to do anything like that on /usr/tmp
Those applications are in serious breach of both the FHS recommendations and POSIX requirements. I would imagine they have a vested interest in fixing that problem. -- Richard Brown Linux Distribution Engineer - Future Technology Team Phone +4991174053-361 SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, D-90409 Nuernberg (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Fri, 10 Jul 2020 14:10:30 +0200, Richard Brown <rbrown@suse.de> wrote:
On Fri, 2020-07-10 at 14:08 +0200, H.Merijn Brand wrote:
On Fri, 10 Jul 2020 13:51:10 +0200, Michal Kubecek <mkubecek@suse.cz> wrote:
On Fri, Jul 10, 2020 at 11:49:45AM +0200, Richard Brown wrote:
Chiming in late, sorry
[...]
I would vehemently oppose, as we have 3rd-party applications that write to (NOT configurable) /tmp and expect it to last there for a certain time (even after a reboot).
To workaround of that, I have created several symbolic links on /tmp to /data/tmp (or /opt/app/tmp or whatever) and I would be very unpleased to see all those symlinks disappear on a reboot. That would mean I have to write service files that fire up immediately after /tmp comes up and recreates those symlinks before the application wants to start.
I really like to keep my /tmp's as clean as possible, but sometimes it is not under our control :(
FWIW I never had to do anything like that on /usr/tmp
Those applications are in serious breach of both the FHS recommendations and POSIX requirements.
I would imagine they have a vested interest in fixing that problem.
The example I can come up with is a production system where 4 parties are involved: end-user application, management-layer, database layer, database server. Of those the management layer has been declared out-of service (dead, no maint) but the whole of the suite still depends on that for at least two more years (some weird law that causes this requirement). The owner of that product is unwilling to make any change to the product. No CVE fixes, not bug fixes, no feature request or whatever, so the engineers responsible for the end-user application and the database layer both have to work around those issues. Working with old propriatary software sometimes really takes away the fun out of ICT :( -- H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/ using perl5.00307 .. 5.31 porting perl5 on HP-UX, AIX, and Linux https://useplaintext.email https://tux.nl http://www.test-smoke.org http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Richard, Merijn, would switching to tmpfs be mandatory for everybody - or could Merijin for his system opt-out of it? Looking at the discussion, might be worth to create a page with more details on the implementation, Andreas -- Andreas Jaeger aj@suse.com Twitter: jaegerandi SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, D 90409 Nürnberg (HRB 36809, AG Nürnberg) GF: Felix Imendörffer GPG fingerprint = EF18 1673 38C4 A372 86B1 E699 5294 24A3 FF91 2ACB -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Fri, Jul 10, Andreas Jaeger wrote:
Richard, Merijn,
would switching to tmpfs be mandatory for everybody - or could Merijin for his system opt-out of it?
Looking at the discussion, might be worth to create a page with more details on the implementation,
On btrfs: mksubvolume /tmp On everything else: disable tmp.mount This is always a one liner. So people who really don't want /tmp on tmpfs can disable it easily during installation or afterwards with a fresh installation. With btrfs in upgrade case, you have to edit /tmp to enable /tmp on tmpfs. On other systems, disable tmp.mount. That's all no big magic and no complex thing with many manual steps. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany Managing Director: Felix Imendoerffer (HRB 36809, AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Fri, 10 Jul 2020 18:14:47 +0200, Thorsten Kukuk <kukuk@suse.de> wrote:
On Fri, Jul 10, Andreas Jaeger wrote:
Richard, Merijn,
would switching to tmpfs be mandatory for everybody - or could Merijin for his system opt-out of it?
Drop the second i, one will do :) Merijn, the salutation was ok
Looking at the discussion, might be worth to create a page with more details on the implementation,
On btrfs: mksubvolume /tmp On everything else: disable tmp.mount
In preparation on the upcoming changes as announced Date: Fri, 31 Jul 2020 15:00:54 +0200 From: Dominique Leuenberger / DimStar <dimstar@opensuse.org> wrote: Subject: [opensuse-factory] Tumbleweed - Review of the week 2020/31
* Change of /tmp to tmpfs
I checked • Using btrfs? No • Mounted? No $ di /tmp/ Filesystem Mount Size Used Avail %Used fs Type /dev/nvme0n1p6 / 220.7G 42.4G 178.3G 19% xfs $ sudo systemctl disable tmp.mount Unit /etc/systemd/system/tmp.mount is masked, ignoring. Uh Oh, now I don't know what to do to prevent /tmp turning into tmpfs
This is always a one liner. So people who really don't want /tmp on tmpfs can disable it easily during installation or afterwards with a fresh installation. With btrfs in upgrade case, you have to edit /tmp to enable /tmp on tmpfs. On other systems, disable tmp.mount. That's all no big magic and no complex thing with many manual steps.
Thorsten
-- H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/ using perl5.00307 .. 5.31 porting perl5 on HP-UX, AIX, and Linux https://useplaintext.email https://tux.nl http://www.test-smoke.org http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
On Friday 2020-07-31 15:32, H.Merijn Brand wrote:
$ sudo systemctl disable tmp.mount Unit /etc/systemd/system/tmp.mount is masked, ignoring.
Uh Oh, now I don't know what to do to prevent /tmp turning into tmpfs
Well if it is masked, it will never be started... which is exactly what you would probably want. "disable" on the other hand still means something can start it. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 31. Jul 2020, at 15:33, H.Merijn Brand <linux@tux.freedom.nl> wrote:
On Fri, 10 Jul 2020 18:14:47 +0200, Thorsten Kukuk <kukuk@suse.de> wrote:
On Fri, Jul 10, Andreas Jaeger wrote:
Richard, Merijn,
would switching to tmpfs be mandatory for everybody - or could Merijin for his system opt-out of it?
Drop the second i, one will do :) Merijn, the salutation was ok
Looking at the discussion, might be worth to create a page with more details on the implementation,
On btrfs: mksubvolume /tmp On everything else: disable tmp.mount
In preparation on the upcoming changes as announced
Date: Fri, 31 Jul 2020 15:00:54 +0200 From: Dominique Leuenberger / DimStar <dimstar@opensuse.org> wrote: Subject: [opensuse-factory] Tumbleweed - Review of the week 2020/31
* Change of /tmp to tmpfs
I checked
• Using btrfs? No • Mounted? No
$ di /tmp/ Filesystem Mount Size Used Avail %Used fs Type /dev/nvme0n1p6 / 220.7G 42.4G 178.3G 19% xfs
$ sudo systemctl disable tmp.mount Unit /etc/systemd/system/tmp.mount is masked, ignoring.
Uh Oh, now I don't know what to do to prevent /tmp turning into tmpfs
Existing systems will not be impacted For fresh installations /tmp will be tmpfs soon (Just some coordination needed to get all the changes out in a snapshot) The documentation for how to either convert existing systems to the new way, or convert new systems to the old way, is here: https://en.opensuse.org/openSUSE:Tmp_on_tmpfs
This is always a one liner. So people who really don't want /tmp on tmpfs can disable it easily during installation or afterwards with a fresh installation. With btrfs in upgrade case, you have to edit /tmp to enable /tmp on tmpfs. On other systems, disable tmp.mount. That's all no big magic and no complex thing with many manual steps.
Thorsten
-- H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/ using perl5.00307 .. 5.31 porting perl5 on HP-UX, AIX, and Linux https://useplaintext.email https://tux.nl http://www.test-smoke.org http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
Hello, Am Samstag, 1. August 2020, 10:12:29 CEST schrieb Richard Brown: [...]
Uh Oh, now I don't know what to do to prevent /tmp turning into tmpfs
Existing systems will not be impacted
For fresh installations /tmp will be tmpfs soon (Just some coordination needed to get all the changes out in a snapshot)
The documentation for how to either convert existing systems to the new way, or convert new systems to the old way, is here:
That page says Using disk space for /tmp If you do not wish to use tmpfs for tmp, you need to just define a mount point for it in /etc/fstab. Then tmpfs will no longer be used for /tmp. However, I miss a description how to use disk space for /tmp/ if it's just a directory on the / partition. Can you please add some information about that case? Oh, and please ensure that a note about this will also end up in the release notes for Leap 16 (I guess this change won't be part of 15.3.) Regards, Christian Boltz -- They patched his code. Which, of course is a bad assault against his highness, because Jörg's code does not need patches of unworthy users of such unworthy operating systems as "Linux". [Stefan Seyfried in opensuse-factory] -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
* Christian Boltz <opensuse@cboltz.de> [08-01-20 08:33]:
Hello,
Am Samstag, 1. August 2020, 10:12:29 CEST schrieb Richard Brown: [...]
Uh Oh, now I don't know what to do to prevent /tmp turning into tmpfs
Existing systems will not be impacted
For fresh installations /tmp will be tmpfs soon (Just some coordination needed to get all the changes out in a snapshot)
The documentation for how to either convert existing systems to the new way, or convert new systems to the old way, is here:
That page says Using disk space for /tmp If you do not wish to use tmpfs for tmp, you need to just define a mount point for it in /etc/fstab. Then tmpfs will no longer be used for /tmp.
However, I miss a description how to use disk space for /tmp/ if it's just a directory on the / partition. Can you please add some information about that case?
Oh, and please ensure that a note about this will also end up in the release notes for Leap 16 (I guess this change won't be part of 15.3.)
and I have a Tw install ext4 which has /tmp and no entry in /etc/fstab. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
* Patrick Shanahan <paka@opensuse.org> [01-01-70 12:34]:
* Christian Boltz <opensuse@cboltz.de> [08-01-20 08:33]:
Hello,
Am Samstag, 1. August 2020, 10:12:29 CEST schrieb Richard Brown: [...]
Uh Oh, now I don't know what to do to prevent /tmp turning into tmpfs
Existing systems will not be impacted
For fresh installations /tmp will be tmpfs soon (Just some coordination needed to get all the changes out in a snapshot)
The documentation for how to either convert existing systems to the new way, or convert new systems to the old way, is here:
That page says Using disk space for /tmp If you do not wish to use tmpfs for tmp, you need to just define a mount point for it in /etc/fstab. Then tmpfs will no longer be used for /tmp.
However, I miss a description how to use disk space for /tmp/ if it's just a directory on the / partition. Can you please add some information about that case?
Oh, and please ensure that a note about this will also end up in the
release notes for Leap 16 (I guess this change won't be part of 15.3.)
and I have a Tw install ext4 which has /tmp and no entry in /etc/fstab.
Today I tried to initiate the *new* tempfs and failed. My system is Tumbleweed 20200803 I have no "tmp" in /etc/fstab so nothing to remove. di /tmp/ Filesystem Mount Size Used Avail %Used fs Type /dev/sdc1 / 45.6G 15.8G 27.5G 40% ext4 I did: rm -rm /tmp rmdir /tmp rebooted, noted failed ssh filesystem connections long wait for recognition of login password noted creation of empty file "/tmp" Rebooted again, just-in-case same long wait for login password recognition What did I do wrong? -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wed, Aug 05, Patrick Shanahan wrote:
Today I tried to initiate the *new* tempfs and failed. My system is Tumbleweed 20200803 I have no "tmp" in /etc/fstab so nothing to remove.
di /tmp/ Filesystem Mount Size Used Avail %Used fs Type /dev/sdc1 / 45.6G 15.8G 27.5G 40% ext4
I did: rm -rm /tmp rmdir /tmp rebooted, noted failed ssh filesystem connections long wait for recognition of login password noted creation of empty file "/tmp"
Rebooted again, just-in-case same long wait for login password recognition
What did I do wrong?
That you did delete /tmp. If the "rmdir" should be a "mkdir", then your mistake is, that afterwards /tmp has wrong permissions. If you want to have tmpfs for /tmp, you should wait until systemd with the necessary changes is released. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany Managing Director: Felix Imendoerffer (HRB 36809, AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
* Thorsten Kukuk <kukuk@suse.de> [08-05-20 08:32]:
On Wed, Aug 05, Patrick Shanahan wrote:
Today I tried to initiate the *new* tempfs and failed. My system is Tumbleweed 20200803 I have no "tmp" in /etc/fstab so nothing to remove.
di /tmp/ Filesystem Mount Size Used Avail %Used fs Type /dev/sdc1 / 45.6G 15.8G 27.5G 40% ext4
I did: rm -rm /tmp rmdir /tmp rebooted, noted failed ssh filesystem connections long wait for recognition of login password noted creation of empty file "/tmp"
Rebooted again, just-in-case same long wait for login password recognition
What did I do wrong?
That you did delete /tmp.
If the "rmdir" should be a "mkdir", then your mistake is, that afterwards /tmp has wrong permissions.
no, instructions when moving from "/tmp/" to tmpfs were to remove tmp entry in fstab and remove /tmp/ and contents, reboot. Or I read incorrectly. I did mkdir after to return system to *normal* operation.
If you want to have tmpfs for /tmp, you should wait until systemd with the necessary changes is released.
my err, thought 20200803 had that. waiting & watching. tks -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wed, Aug 05, Patrick Shanahan wrote:
* Thorsten Kukuk <kukuk@suse.de> [08-05-20 08:32]:
On Wed, Aug 05, Patrick Shanahan wrote:
Today I tried to initiate the *new* tempfs and failed. My system is Tumbleweed 20200803 I have no "tmp" in /etc/fstab so nothing to remove.
di /tmp/ Filesystem Mount Size Used Avail %Used fs Type /dev/sdc1 / 45.6G 15.8G 27.5G 40% ext4
I did: rm -rm /tmp rmdir /tmp rebooted, noted failed ssh filesystem connections long wait for recognition of login password noted creation of empty file "/tmp"
Rebooted again, just-in-case same long wait for login password recognition
What did I do wrong?
That you did delete /tmp.
If the "rmdir" should be a "mkdir", then your mistake is, that afterwards /tmp has wrong permissions.
no, instructions when moving from "/tmp/" to tmpfs were to remove tmp entry in fstab and remove /tmp/ and contents, reboot. Or I read incorrectly.
Yes, you did read incorrectly: "Remove all files __in__ /tmp" Not /tmp itself. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany Managing Director: Felix Imendoerffer (HRB 36809, AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
* Thorsten Kukuk <kukuk@suse.de> [08-05-20 09:41]:
On Wed, Aug 05, Patrick Shanahan wrote: [...]
no, instructions when moving from "/tmp/" to tmpfs were to remove tmp entry in fstab and remove /tmp/ and contents, reboot. Or I read incorrectly.
Yes, you did read incorrectly: "Remove all files __in__ /tmp"
Not /tmp itself.
tks, I *will* remember :( or not, seems to happen more and more and ... :( -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
* Patrick Shanahan <paka@opensuse.org> [08-05-20 09:54]:
* Thorsten Kukuk <kukuk@suse.de> [08-05-20 09:41]:
On Wed, Aug 05, Patrick Shanahan wrote: [...]
no, instructions when moving from "/tmp/" to tmpfs were to remove tmp entry in fstab and remove /tmp/ and contents, reboot. Or I read incorrectly.
Yes, you did read incorrectly: "Remove all files __in__ /tmp"
Not /tmp itself.
tks, I *will* remember :( or not, seems to happen more and more and ... :(
ok, Snapshot 20200806 installed, did "rm -rf /tmp/*" and verified it was empty and rebooted note: there is/was no "tmp" entry in /etc/fstab. ls -la /tmp drwxrwxrwt 16 root root 340 Aug 7 12:24 . drwxr-xr-x 23 root root 4096 Aug 5 00:58 .. drwx------ 2 paka users 60 Aug 7 12:23 .esd-1000 drwxrwxrwt 2 root root 40 Aug 7 12:05 .font-unix drwxrwxrwt 2 root root 40 Aug 7 12:05 .ICE-unix drwx------ 3 root root 60 Aug 7 12:05 systemd-private-ad9ba14d579e42919130df95bef7d8ae-chronyd.service-sQh1Wg drwx------ 3 root root 60 Aug 7 12:05 systemd-private-ad9ba14d579e42919130df95bef7d8ae-colord.service-qqbl7g drwx------ 3 root root 60 Aug 7 12:05 systemd-private-ad9ba14d579e42919130df95bef7d8ae-ModemManager.service-T0vBTe drwx------ 3 root root 60 Aug 7 12:23 systemd-private-ad9ba14d579e42919130df95bef7d8ae-rtkit-daemon.service-VIgRYi drwx------ 3 root root 60 Aug 7 12:05 systemd-private-ad9ba14d579e42919130df95bef7d8ae-systemd-logind.service-ICOuSf drwx------ 3 root root 60 Aug 7 12:05 systemd-private-ad9ba14d579e42919130df95bef7d8ae-systemd-timesyncd.service-EkUuli drwx------ 2 paka users 40 Aug 7 12:23 Temp-9fb294c9-bba7-4914-b058-1cd52e8f3ebf drwx------ 2 paka users 40 Aug 7 12:23 Temp-dfc2a3da-aab6-48fb-ad2a-3dbed092ae52 drwxrwxrwt 2 root root 40 Aug 7 12:05 .Test-unix drwxrwxrwt 2 root root 60 Aug 7 12:20 .X11-unix drwxrwxrwt 2 root root 40 Aug 7 12:05 .XIM-unix -r--r--r-- 1 root root 11 Aug 7 12:20 .X0-lock guess the method to change to tempfs is not quite universal. Any update? -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
* Patrick Shanahan <paka@opensuse.org> [08-07-20 14:41]:
* Patrick Shanahan <paka@opensuse.org> [08-05-20 09:54]:
* Thorsten Kukuk <kukuk@suse.de> [08-05-20 09:41]:
On Wed, Aug 05, Patrick Shanahan wrote: [...]
no, instructions when moving from "/tmp/" to tmpfs were to remove tmp entry in fstab and remove /tmp/ and contents, reboot. Or I read incorrectly.
Yes, you did read incorrectly: "Remove all files __in__ /tmp"
Not /tmp itself.
tks, I *will* remember :( or not, seems to happen more and more and ... :(
ok, Snapshot 20200806 installed, did "rm -rf /tmp/*" and verified it was empty and rebooted note: there is/was no "tmp" entry in /etc/fstab.
please disregard. tmp is indeed using tmpfs. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 5. Aug 2020, at 13:59, Patrick Shanahan <paka@opensuse.org> wrote:
* Patrick Shanahan <paka@opensuse.org> [01-01-70 12:34]:
* Christian Boltz <opensuse@cboltz.de> [08-01-20 08:33]:
Hello,
Am Samstag, 1. August 2020, 10:12:29 CEST schrieb Richard Brown: [...]
Uh Oh, now I don't know what to do to prevent /tmp turning into tmpfs
Existing systems will not be impacted
For fresh installations /tmp will be tmpfs soon (Just some coordination needed to get all the changes out in a snapshot)
The documentation for how to either convert existing systems to the new way, or convert new systems to the old way, is here:
That page says Using disk space for /tmp If you do not wish to use tmpfs for tmp, you need to just define a mount point for it in /etc/fstab. Then tmpfs will no longer be used for /tmp.
However, I miss a description how to use disk space for /tmp/ if it's just a directory on the / partition. Can you please add some information about that case?
Oh, and please ensure that a note about this will also end up in the
release notes for Leap 16 (I guess this change won't be part of 15.3.)
and I have a Tw install ext4 which has /tmp and no entry in /etc/fstab.
Today I tried to initiate the *new* tempfs and failed. My system is Tumbleweed 20200803 I have no "tmp" in /etc/fstab so nothing to remove.
di /tmp/ Filesystem Mount Size Used Avail %Used fs Type /dev/sdc1 / 45.6G 15.8G 27.5G 40% ext4
I did: rm -rm /tmp rmdir /tmp rebooted, noted failed ssh filesystem connections long wait for recognition of login password noted creation of empty file "/tmp"
Rebooted again, just-in-case same long wait for login password recognition
What did I do wrong?
You didn’t wait for the changes to be in the distribution....
-- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Fri, 2020-07-10 at 14:20 +0200, H.Merijn Brand wrote:
On Fri, 10 Jul 2020 14:10:30 +0200, Richard Brown <rbrown@suse.de> wrote:
Those applications are in serious breach of both the FHS recommendations and POSIX requirements.
I would imagine they have a vested interest in fixing that problem.
The example I can come up with is a production system where 4 parties are involved: end-user application, management-layer, database layer, database server. Of those the management layer has been declared out- of service (dead, no maint) but the whole of the suite still depends on that for at least two more years (some weird law that causes this requirement). The owner of that product is unwilling to make any change to the product. No CVE fixes, not bug fixes, no feature request or whatever, so the engineers responsible for the end-user application and the database layer both have to work around those issues.
Working with old propriatary software sometimes really takes away the fun out of ICT :(
And you're running this on Tumbleweed? I'm pretty sure you're not expecting us to support such bad practice indefinately, right? -- Richard Brown Linux Distribution Engineer - Future Technology Team Phone +4991174053-361 SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, D-90409 Nuernberg (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Fri, 10 Jul 2020 14:26:01 +0200, Richard Brown <rbrown@suse.de> wrote:
On Fri, 2020-07-10 at 14:20 +0200, H.Merijn Brand wrote:
On Fri, 10 Jul 2020 14:10:30 +0200, Richard Brown <rbrown@suse.de> wrote:
Those applications are in serious breach of both the FHS recommendations and POSIX requirements.
I would imagine they have a vested interest in fixing that problem.
The example I can come up with is a production system where 4 parties are involved: end-user application, management-layer, database layer, database server. Of those the management layer has been declared out- of service (dead, no maint) but the whole of the suite still depends on that for at least two more years (some weird law that causes this requirement). The owner of that product is unwilling to make any change to the product. No CVE fixes, not bug fixes, no feature request or whatever, so the engineers responsible for the end-user application and the database layer both have to work around those issues.
Working with old propriatary software sometimes really takes away the fun out of ICT :(
And you're running this on Tumbleweed?
No :) Though Tumbleweed has never bees so stable for me as it has the past 6 months. I'd almost say it is more stable than an old 42.3
I'm pretty sure you're not expecting us to support such bad practice indefinately, right?
If it would be an option, why not? Let me expand on that a bit I've updated a 10-year old Windows box for my daughter by replacing the hardware with similar hardware I had on the attic (faster CPU mainly), then I added 4 Gb of RAM and the system worked fine. Slooooooow, but fine. Then I replaced the RAID disks (2 x WD320 Gb) with a single SSD disk of 512Gb and the boot time reduced from a whopping 13 minutes to a mere 15 seconds. Me happy, daughter happy. (lets shuv' aside the real problems I faced with incompatible drivers that cost me another three days. A system with no network is kinda useless these days) Then I thought, well, if it is that much faster, why not replace my 2 Tb root HDD disk on openSUSE 15.1 with an SSD and see if it gets that much faster too. Long story short: it took me a week to read all the steps to take if you don't want to install a new system afresh and some things in cloning *really* work different in Linux, so what I ended up is a working system with a 2Tb SSD that holds the root FS (xfs) and the old disk still installed for the UEFI partition and the swap partition (and I got an on-line backup of the root partition for free). The system is now noticeably faster and I learned a lot, but it was not the ease I got on Windows. There will be people trying to install new Operating Systems and/or new software on (very) old hardware and most of the time, this just works (unlike with Windows: do not try to install Windows 10 on a 10 year old PC). It will make hobbyists more enthusiastic about Linux and its community. They get old hardware and build it into a hobby-system with 18 Gb disks and 2 Gb of RAM and take it that it is slow, but it WORKS! Not allowing some app to write to /tmp is a different thing than saying that if you do it is gone when you reboot. I for one would accept that /tmp is slower when used with a HDD (well, I now have 1.5Tb free to be mounted for /tmp) and have enough to dump data there over a /tmp that is a bit quicker but takes away my RAM. I have a choice at this point in time to use a disk as /tmp and use my RAM for something else. I do have more than enough disks stacked away that I could use, but my memory slots are all used and I do not have a real need to trade that for faster /tmp. Short: I like to have that option for a long time forward -- H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/ using perl5.00307 .. 5.31 porting perl5 on HP-UX, AIX, and Linux https://useplaintext.email https://tux.nl http://www.test-smoke.org http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
Hi, On 7/10/20 8:10 AM, Richard Brown wrote:
On Fri, 2020-07-10 at 14:08 +0200, H.Merijn Brand wrote:
On Fri, 10 Jul 2020 13:51:10 +0200, Michal Kubecek <mkubecek@suse.cz> <snip> I would vehemently oppose, as we have 3rd-party applications that write to (NOT configurable) /tmp and expect it to last there for a certain time (even after a reboot).
To workaround of that, I have created several symbolic links on /tmp to /data/tmp (or /opt/app/tmp or whatever) and I would be very unpleased to see all those symlinks disappear on a reboot. That would mean I have to write service files that fire up immediately after /tmp comes up and recreates those symlinks before the application wants to start.
I really like to keep my /tmp's as clean as possible, but sometimes it is not under our control :(
FWIW I never had to do anything like that on /usr/tmp
Those applications are in serious breach of both the FHS recommendations and POSIX requirements.
I am not opposed to the change and recognize that applications that do not conform to standards are difficult to deal with. However, lecturing the users of those applications about the problem is not really helpful.
I would imagine they have a vested interest in fixing that problem.
Why? Making the assumption that these are proprietary applications the question would arise how many new customers a modified application that adheres to the standard would attract? A feature in an application description "now FHS and POSIX compliant for temporary file handling" doesn't sound very sexy to me and I would hap hazard a guess that it will not have a large influence on purchasing decisions. Bottom line a change of an application that does not provide a tangible benefit to attract new customers is pure cost to an ISV and that is hard to swallow. Again, it comes down to making the transition obvious to handle, and for users to disable the new behavior in an easy way when necessary. Later, Robert -- Robert Schweikert MAY THE SOURCE BE WITH YOU Distinguished Engineer LINUX Technical Team Lead Public Cloud rjschwei@suse.com IRC: robjo
On Fri, 10 Jul 2020 14:08:02 +0200, "H.Merijn Brand" <linux@tux.freedom.nl> wrote:
On Fri, 10 Jul 2020 13:51:10 +0200, Michal Kubecek <mkubecek@suse.cz> wrote:
On Fri, Jul 10, 2020 at 11:49:45AM +0200, Richard Brown wrote:
Chiming in late, sorry
We recently moved MicroOS and Kubic to use tmpfs for /tmp instead of writing files there to disk. [...] All of these reasons also apply for regular openSUSE, so I would like to propose that Tumbleweed moves to tmpfs for /tmp soon also.
I would vehemently oppose, as we have 3rd-party applications that write to (NOT configurable) /tmp and expect it to last there for a certain time (even after a reboot).
Maybe important thing to add, I do not have systems with btrfs, all Linux systems I have access to use ext2, ext3, ext4, or xfs (and some are really old)
To workaround of that, I have created several symbolic links on /tmp to /data/tmp (or /opt/app/tmp or whatever) and I would be very unpleased to see all those symlinks disappear on a reboot. That would mean I have to write service files that fire up immediately after /tmp comes up and recreates those symlinks before the application wants to start.
I really like to keep my /tmp's as clean as possible, but sometimes it is not under our control :(
FWIW I never had to do anything like that on /usr/tmp
Does anyone have any objections, concerns, thoughts?
No objection to the general change but I would suggest two exceptions:
1. Systems where user created a specific mount point for /tmp (whether tmpfs or normal filesystem). According to the previous discussion, this should be taken care of already.
2. Systems with less memory than a certain threshold. I'm not sure what the threshold should be but I would be afraid to configure /tmp on tmpfs by default on systems with 4GB of RAM. 8GB might be OK, I have such configuration on my laptop with 8GB myself and didn't encounter any problems (but it took me quite some time to summon the courage).
:)
Michal Kubecek -- H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/ using perl5.00307 .. 5.31 porting perl5 on HP-UX, AIX, and Linux https://useplaintext.email https://tux.nl http://www.test-smoke.org http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 10.07.20 um 14:08 schrieb H.Merijn Brand:
On Fri, 10 Jul 2020 13:51:10 +0200, Michal Kubecek <mkubecek@suse.cz> wrote:
On Fri, Jul 10, 2020 at 11:49:45AM +0200, Richard Brown wrote:
Chiming in late, sorry
We recently moved MicroOS and Kubic to use tmpfs for /tmp instead of writing files there to disk. [...] All of these reasons also apply for regular openSUSE, so I would like to propose that Tumbleweed moves to tmpfs for /tmp soon also.
I would vehemently oppose, as we have 3rd-party applications that write to (NOT configurable) /tmp and expect it to last there for a certain time (even after a reboot).
To workaround of that, I have created several symbolic links on /tmp to /data/tmp (or /opt/app/tmp or whatever) and I would be very unpleased to see all those symlinks disappear on a reboot. That would mean I have to write service files that fire up immediately after /tmp comes up and recreates those symlinks before the application wants to start.
#> cat /usr/share/systemd/tmp.mount # This file is part of systemd. # # systemd is free software; you can redistribute it and/or modify it # under the terms of the GNU Lesser General Public License as published by # the Free Software Foundation; either version 2.1 of the License, or # (at your option) any later version. [Unit] Description=Temporary Directory (/tmp) Documentation=man:hier(7) Documentation=https://www.freedesktop.org/wiki/Software/systemd/APIFileSystems ConditionPathIsSymbolicLink=!/tmp DefaultDependencies=no Conflicts=umount.target Before=local-fs.target umount.target After=swap.target [Mount] What=tmpfs Where=/tmp Type=tmpfs Options=mode=1777,strictatime,nosuid,nodev Notice the "ConditionPathIsSymbolicLink=!/tmp", which, I guess, will prevent damage in your case.
I really like to keep my /tmp's as clean as possible, but sometimes it is not under our control :(
FWIW I never had to do anything like that on /usr/tmp
Does anyone have any objections, concerns, thoughts?
No objection to the general change but I would suggest two exceptions:
1. Systems where user created a specific mount point for /tmp (whether tmpfs or normal filesystem). According to the previous discussion, this should be taken care of already.
2. Systems with less memory than a certain threshold. I'm not sure what the threshold should be but I would be afraid to configure /tmp on tmpfs by default on systems with 4GB of RAM. 8GB might be OK, I have such configuration on my laptop with 8GB myself and didn't encounter any problems (but it took me quite some time to summon the courage).
:)
Michal Kubecek
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Fri, Jul 10, 2020 at 5:49 AM Richard Brown <rbrown@suse.de> wrote:
Hello community,
We recently moved MicroOS and Kubic to use tmpfs for /tmp instead of writing files there to disk.
Right off the bat, +1 .. I have been using this since a long time..that said..
- Reducing wear on SSDs/SD card storage
This is actually a non issue with modern SSD devices.
- Using less disk space and being more tidy generally
I'd buy the more tidy argument.. see.. you unfortunately cannot trust software to clean after themselves.. this is the sad state of things and one of the main reasons this has to be done, as long as something uses the mk*stmp* tmpn* interfaces this will continue happen. (tmpfile() now uses O_TMPFILE so it is excluded from nasties list)
The impact should be minimal, as all POSIX compliant applications should already assume that /tmp is not persistant between invocations of the program.
Those who don't are broken, yes.
We will likely impliment this as systemd mount unit, meaning if people disable it then they will be able to return to the old behaviour.
Yes, it is as simple as re-adding and enabling one upstream unit by default.
Does anyone have any objections, concerns, thoughts?
Not really. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2020-07-10 22:25, Cristian Rodríguez wrote:
you unfortunately cannot trust software to clean after themselves.. this is the sad state of things and one of the main reasons this has to be done, as long as something uses the mk*stmp* tmpn* interfaces this will continue happen. (tmpfile() now uses O_TMPFILE so it is excluded from nasties list)
A problem is when a program which creates temporary files can't know when they have to be deleted later, e.g. a mail program saving an attachment and then starting an application to display it. There's no golden rule when would be the best time to delete the file, but IMO a time-based rule (e.g. a week) is better than a reboot-based cleanup ... especially on Tumbleweed where we boot quite often due to updates. Have a nice day, Berny -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Sat, 2020-07-11 at 16:55 +0200, Bernhard Voelker wrote:
On 2020-07-10 22:25, Cristian Rodríguez wrote:
you unfortunately cannot trust software to clean after themselves.. this is the sad state of things and one of the main reasons this has to be done, as long as something uses the mk*stmp* tmpn* interfaces this will continue happen. (tmpfile() now uses O_TMPFILE so it is excluded from nasties list)
A problem is when a program which creates temporary files can't know when they have to be deleted later, e.g. a mail program saving an attachment and then starting an application to display it.
The FHS and POSIX standards are very clear on this. No application should expect a file in /tmp to be there after the current execution of the application.
There's no golden rule when would be the best time to delete the file, but IMO a time-based rule (e.g. a week) is better than a reboot-based cleanup ... especially on Tumbleweed where we boot quite often due to updates.
Given the recommendations of the FHS and the hard requirement of the POSIX standard, then any reboot is _the_ perfect time to clean up /tmp, because it's the one time we can be sure there is nothing currently executing, therefore nothign can be using /tmp at that time. Regards, -- Richard Brown Linux Distribution Engineer - Future Technology Team Phone +4991174053-361 SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, D-90409 Nuernberg (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2020-07-11 17:05, Richard Brown wrote:
On Sat, 2020-07-11 at 16:55 +0200, Bernhard Voelker wrote:
On 2020-07-10 22:25, Cristian Rodríguez wrote:
you unfortunately cannot trust software to clean after themselves.. this is the sad state of things and one of the main reasons this has to be done, as long as something uses the mk*stmp* tmpn* interfaces this will continue happen. (tmpfile() now uses O_TMPFILE so it is excluded from nasties list)
A problem is when a program which creates temporary files can't know when they have to be deleted later, e.g. a mail program saving an attachment and then starting an application to display it.
The FHS and POSIX standards are very clear on this.
The standard might be clear, but that still does not clarify which program is responsible for deletion. As a concrete example: Thunderbird saves a PDF file and starts Evince to open it.
No application should expect a file in /tmp to be there after the current execution of the application.
There's no golden rule when would be the best time to delete the file, but IMO a time-based rule (e.g. a week) is better than a reboot-based cleanup ... especially on Tumbleweed where we boot quite often due to updates.
Given the recommendations of the FHS and the hard requirement of the POSIX standard, then any reboot is _the_ perfect time to clean up /tmp, because it's the one time we can be sure there is nothing currently executing, therefore nothign can be using /tmp at that time.
Just for the record: I'm not really pro or contra the change to /tmp as /tmpfs. It's just that in my opinion, none of the given reasons are really forcing us to do the change. We _can_ do it, and maybe it's the right time to it now. Reading all the posts so far, I'd say nobody is against the change ... as long as a user can choose something different for his/her system. Have a nice day, Berny -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Bernhard Voelker wrote:
Reading all the posts so far, I'd say nobody is against the change ... as long as a user can choose something different for his/her system.
That is also my interpretation, yes. -- Per Jessen, Zürich (20.1°C) Member, openSUSE Heroes -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Fri, 10 Jul 2020, Cristian Rodríguez wrote:
On Fri, Jul 10, 2020 at 5:49 AM Richard Brown <rbrown@suse.de> wrote:
Hello community,
We recently moved MicroOS and Kubic to use tmpfs for /tmp instead of writing files there to disk.
Right off the bat, +1 .. I have been using this since a long time..that said..
- Reducing wear on SSDs/SD card storage
This is actually a non issue with modern SSD devices.
Is it really? I'm doing ~3-4 bootstrap / test cycles of GCC a day each ending up with around 10GB of throw-away storage (but the actual amount of written data is higher). That's of course still far away of consumer-grade SSD write endurance, for example a 256GB Samsung EVO has 5 years warranty at 150TBW but that makes only 82GB writes per day where those throw-away bootstraps would be more than half of the specified endurance. So I'm doing those in tmpfs (w/ 32GB ram my tmpfs is limited to 16GB via manual configuration). [no, I don't actually own a 256GB SSD but a 512GB one where endurance tends to be higher] Richard. -- Richard Biener <rguenther@suse.de> SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg)
On Mon, 2020-07-13 at 09:49 +0200, Richard Biener wrote:
On Fri, 10 Jul 2020, Cristian Rodríguez wrote:
On Fri, Jul 10, 2020 at 5:49 AM Richard Brown <rbrown@suse.de> wrote:
Hello community,
We recently moved MicroOS and Kubic to use tmpfs for /tmp instead of writing files there to disk.
Right off the bat, +1 .. I have been using this since a long time..that said..
- Reducing wear on SSDs/SD card storage
This is actually a non issue with modern SSD devices.
Is it really? I'm doing ~3-4 bootstrap / test cycles of GCC a day each ending up with around 10GB of throw-away storage (but the actual amount of written data is higher). That's of course still far away of consumer-grade SSD write endurance, for example a 256GB Samsung EVO has 5 years warranty at 150TBW but that makes only 82GB writes per day where those throw-away bootstraps would be more than half of the specified endurance.
So I'm doing those in tmpfs (w/ 32GB ram my tmpfs is limited to 16GB via manual configuration).
[no, I don't actually own a 256GB SSD but a 512GB one where endurance tends to be higher]
Richard.
It's most certainly an issue for SD Cards still. Regards, -- Richard Brown Linux Distribution Engineer - Future Technology Team Phone +4991174053-361 SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, D-90409 Nuernberg (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Friday, 10 July 2020 10:49:45 BST Richard Brown wrote:
Hello community,
We recently moved MicroOS and Kubic to use tmpfs for /tmp instead of writing files there to disk.
This means files written to /tmp as never written to disk and so dissapear on reboot.
i'd like to be able to keep /tmp files on disk as i've not got that much memory so if its configurable, that would be great. i'd love /tmp to be emptied on shutdown.
This was for a number of reasons, including
- Reducing wear on SSDs/SD card storage - Using less disk space and being more tidy generally - Being more like many other Distro's and Unixes including Debian, Arch, Fedora, Solaris, etc - Being more consistant with the FHS recommendations that /tmp is flushed on reboot https://www.pathname.com/fhs/pub/fhs-2.3.html#TMPTEMPORARYFILES
All of these reasons also apply for regular openSUSE, so I would like to propose that Tumbleweed moves to tmpfs for /tmp soon also.
The impact should be minimal, as all POSIX compliant applications should already assume that /tmp is not persistant between invocations of the program.
As we're walking paths that other distros long have, my own research suggests that vast majority of problematic /tmp use has already been resolved, such as by using /var/tmp instead.
We will likely impliment this as systemd mount unit, meaning if people disable it then they will be able to return to the old behaviour.
Does anyone have any objections, concerns, thoughts?
Regards,
-- opensuse:tumbleweed:20200701 Qt: 5.15.0 KDE Frameworks: 5.71.0 - KDE Plasma: 5.19.2 - kwin 5.19.2 kmail2 5.14.2 (20.04.2) - akonadiserver 5.14.2 (20.04.2) - Kernel: 5.7.5-1-default - xf86-video-nouveau: 1.0.16 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2020-07-10 11:49:45 +0200, Richard Brown wrote:
We recently moved MicroOS and Kubic to use tmpfs for /tmp instead of writing files there to disk.
This means files written to /tmp as never written to disk and so dissapear on reboot.
This was for a number of reasons, including
- Reducing wear on SSDs/SD card storage - Using less disk space and being more tidy generally - Being more like many other Distro's and Unixes including Debian, Arch, Fedora, Solaris, etc - Being more consistant with the FHS recommendations that /tmp is flushed on reboot https://www.pathname.com/fhs/pub/fhs-2.3.html#TMPTEMPORARYFILES
All of these reasons also apply for regular openSUSE, so I would like to propose that Tumbleweed moves to tmpfs for /tmp soon also.
The impact should be minimal, as all POSIX compliant applications should already assume that /tmp is not persistant between invocations of the program.
Hmm since most people in this thread are just concerned with persistency and/or memory usage, let's raise a different "issue":) Using tmpfs for /tmp might break existing (broken) workflows that assume that /tmp is not a tmpfs (or ramfs). For instance, consider the following _artificial_ script: - rm -rf /tmp/build-root-test-non-shared-mem - install required packages into /tmp/build-root-test-non-shared-mem - do not mount anything into /tmp/build-root-test-non-shared-mem/* - chroot /tmp/build-root-test-non-shared-mem /usr/bin/foo where foo.c looks like this (excerpt) int fd = shm_open("/foo", O_RDWR | O_CREAT, S_IRUSR | S_IWUSR); if (fd == -1) { // non-shared memory mode return do_non_shared_mem_mode(); } // shared memory mode return do_shared_mem_mode(fd); If "suddenly" tmpfs is used for /tmp, the script would not test the "intended" codepath (do_non_shared_mem_mode()) anymore... (A real world application in this chroot scenario is firefox: in the non tmpfs case, you cannot start firefox from within the chroot (it complains about missing shared mem support); in the tmpfs case, firefox can be started from within the chroot (if a /proc is also mounted).)
As we're walking paths that other distros long have, my own research suggests that vast majority of problematic /tmp use has already been resolved, such as by using /var/tmp instead.
We will likely impliment this as systemd mount unit, meaning if people disable it then they will be able to return to the old behaviour.
Would existing installations be affected by this change after a "zypper dup" or is this solely about new/fresh installations? As long as it is just about the latter, breaking workflows like the one from above is perfectly fine for me... Marcus -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Sat, Jul 11, Marcus Hüwe wrote:
Would existing installations be affected by this change after a "zypper dup" or is this solely about new/fresh installations? As long as it is just about the latter, breaking workflows like the one from above is perfectly fine for me...
As written in the thread: If /tmp is a mountpoint, only fresh installations are affected. If /tmp is no mountpoint, change will take affect with next reboot. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany Managing Director: Felix Imendoerffer (HRB 36809, AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (48)
-
Aaron Puchert -
Alexander Bokov -
Andreas Jaeger -
Arvin Schnell -
Axel Braun -
Benjamin Zeller -
Bernd Ritter -
Bernhard Voelker -
Bjoern Voigt -
Carlos E. R. -
Carlos E.R. -
Christian Boltz -
Cristian Rodríguez -
Dan Čermák -
dieter -
Dominik Heidler -
Dominique Leuenberger / DimStar -
Frederic Crozat -
H.Merijn Brand -
Ianseeks -
James Knott -
Jan Engelhardt -
Jason Craig -
Jiri Slaby -
Joerg Schilling -
Johannes Meixner -
John Paul Adrian Glaubitz -
Ludwig Nussel -
Malte Kraus -
Manfred Schwarb -
Marcus Hüwe -
Martin Liška -
Michal Kubecek -
Neal Gompa -
Olaf Hering -
Patrick Shanahan -
Per Jessen -
Rainer Klier -
Richard Biener -
Richard Brown -
Robert Schweikert -
Rodney Baker -
Stasiek Michalski -
Stefan Behlert -
Stefan Seyfried -
Stephan Kulow -
Thorsten Kukuk -
Werner Flamme