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 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 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 Fri, Jul 10, 2020 at 3:46 PM Bernhard Voelker 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

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

On Fri, Jul 10, 2020 at 13:44, Richard Brown 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

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, 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, 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, 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, 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, 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, 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, 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 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

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

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)

Am Fri, 10 Jul 2020 12:08:19 +0200 schrieb Joerg Schilling :

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... Olaf

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

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

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

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 написано:

...

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

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

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 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 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 Friday 2020-07-10 12:34, Joerg Schilling wrote:

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.

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

On Fri, 2020-07-10 at 12:42 +0200, Joerg Schilling wrote:

Jan Engelhardt 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 2020-07-10 12:42, Joerg Schilling wrote:

Jan Engelhardt 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

Carlos E. R. schrieb am 10.07.20 um 14:16:

On 10/07/2020 12.42, Joerg Schilling wrote:

...

Jan Engelhardt 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 :) --

On Fri, Jul 10, 2020 at 12:34:01PM +0200, Joerg Schilling wrote:

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.

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, 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 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

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

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

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

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)

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)

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

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

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

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

Le jeudi 16 juillet 2020 à 11:11 +0200, Stasiek Michalski a écrit :

On Thu, Jul 16, 2020 at 08:52, Frederic Crozat 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 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

Frederic Crozat 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 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, 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 Friday 2020-07-17 14:14, Cristian Rodríguez wrote:

On Fri, Jul 17, 2020 at 6:54 AM Michal Kubecek 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, 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 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 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.

1: https://github.com/google/path-auditor

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

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 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 Fri, 2020-07-10 at 14:08 +0200, H.Merijn Brand wrote:

On Fri, 10 Jul 2020 13:51:10 +0200, Michal Kubecek 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

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, 10 Jul 2020 18:14:47 +0200, Thorsten Kukuk 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 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 31. Jul 2020, at 15:33, H.Merijn Brand wrote:

On Fri, 10 Jul 2020 18:14:47 +0200, Thorsten Kukuk 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 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/

* Christian Boltz [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:

https://en.opensuse.org/openSUSE:Tmp_on_tmpfs

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

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

On Wed, Aug 05, Patrick Shanahan wrote:

* Thorsten Kukuk [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

* Patrick Shanahan [08-05-20 09:54]:

* Thorsten Kukuk [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

On 5. Aug 2020, at 13:59, Patrick Shanahan wrote:

* Patrick Shanahan [01-01-70 12:34]:

...

* Christian Boltz [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:

https://en.opensuse.org/openSUSE:Tmp_on_tmpfs

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, 10 Jul 2020 14:26:01 +0200, Richard Brown 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 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/

On Fri, 10 Jul 2020 14:08:02 +0200, "H.Merijn Brand" wrote:

On Fri, 10 Jul 2020 13:51:10 +0200, Michal Kubecek 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

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

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