On Sun, 2 May 2010, Guido Berhoerster wrote:

* Andreas Jaeger [2010-05-02 19:16]:

...

Looking at the failures, I wrote up the following and will post it as blog post later - anything wrong or missing on this?

Feature #303793 (https://features.opensuse.org/303793) proposes to mount /var/run as tmpfs.

The description says:

"This would avoid the cleaning of stale files or

This also applies to /tmp, why not make it tmpfs, too? That would (partially) address https://features.opensuse.org/307510. The only prerequisite would be to ensure a big enough swap in the installer and mounting with -o size accordingly so that hibernating is still possible.

I can only urge you to keep away from tmpfs for /tmp, at least at the moment (X11, other not easy to fix programs). What i can recoment is using /dev/shm for most uses. Esp if login/profile scripts are modified to create a 'private' temp dir, like /dev/shm/$USER and propagate via export TMP=/dev/shm/$USER TEMP=$TMP TMPDIR=$TMP TEMPDIR=$TMP; mkdir -m 700 -p /dev/shm/$USER This works NOW without big changes, and could easily implemeted for 11.3 For 11.4 / 12.0 the work would be to reduce the amount of programs/scripts that are hard coded for /tmp. Do NOT make work where it's not needed. most of /tmp use is hardcoded upstream, and thus not likely to change in less than 3 month. Even better would be getting the other (bigger) distros onboard for this change, this would be a great speedup for this (- that is reducing hardcoded /tmp use) Sorry if this seems harsh, but please see the reality, - most upsteam maintainace is done privatly in peoples free time. A wide public recommendation to use TMP/TEMP/TMPDIR/TEMPDIR instead of blindly using /tmp should be given ahead of the change, maybe asking Linus Torwalds for referral on this? Thanks for listening, Michael PS: I'll say it again: this is NO attack on Guido Berhoerster, just a urging on precauction, with background on the why. You try to get a patch into Xorg as a nobody and you'll know why. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

On Sunday 02 May 2010 23:36:00 Guido Berhoerster wrote:

* Michael Foerster [2010-05-02 21:37]:

...

I can only urge you to keep away from tmpfs for /tmp, at least at the moment (X11, other not easy to fix programs).

Huh, what is the actual problem, could you elaborate this a bit? /tmp has been tmpfs on Solaris for ages, it also works just fine NetBSD and Ubuntu, alhough I've not yet tested this on openSUSE.

I'm running a setup with /tmp on tmpfs for about a year now with Factory on my desktop and my laptop and do not see any serious issues, what should I look for ? -- with kind regards (mit freundlichem Grinsen), Ruediger Oertel (ro@novell.com,ro@suse.de,bugfinder@t-online.de) ---------------------------------------------------------------------- Linux MacBookRudi.suse.de 2.6.34-rc5-6-desktop #1 SMP PREEMPT 2010-04-22 21:18:20 +0200 x86_64 Key fingerprint = 17DC 6553 86A7 384B 53C5 CA5C 3CE4 F2E7 23F2 B417 SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

Hi, On Mon, 3 May 2010, Guido Berhoerster wrote:

...

...

Huh, what is the actual problem, could you elaborate this a bit? /tmp has been tmpfs on Solaris for ages, it also works just fine NetBSD and Ubuntu, alhough I've not yet tested this on openSUSE.

I'm running a setup with /tmp on tmpfs for about a year now with Factory on my desktop and my laptop and do not see any serious issues, what should I look for ?

There should be none whatsoever. OpenBSD, Solaris/Opensolaris, Debian, and Ubuntu clear /tmp by default on bootup. The FHS even recommends clearing /tmp on boot. It has just not been the default on openSUSE.

And that's exactly why the default shouldn't be changed. It was a conscious decision everytime that discussion came up during the past 10+ years to not clean /tmp on reboot. Nothing has changed since then. If you want to change the default, play with CLEAR_TMP_DIRS_AT_BOOTUP in /etc/sysconfig/cron (using tmpfs for /tmp could then be conditional on that variable). Ciao, Michael. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

On Mon, 3 May 2010, Guido Berhoerster wrote:

* Michael Matz [2010-05-03 14:12]:

...

And that's exactly why the default shouldn't be changed. It was a

If I got this right, tmpwatch will now be installed by default and remove files older than 10 days though a daily cronjob, see http://lists.opensuse.org/opensuse-factory/2010-05/msg00020.html So

Whose bullshit idea was that? It's not even configurable and simply hardcodes paths and time for everyone. Marvelous :-( It would even have been better to change the defaults as suggested in the feature request than to add crap packages. Only slightly better but still. Probably somebody wanted to avoid the usual discussion ... Bah.

the default has already changed to match the behavior of RedHat/Fedora which is IMO a good thing considering the cruft that tends to accumulate there.

So what, set MAX_DAYS_IN_TMP. Oh wait, that's not the Redhat way. Yeah right. Ciao, Michael. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

On Mon, May 3, 2010 at 9:34 AM, Guido Berhoerster wrote:

* Michael Matz [2010-05-03 15:06]:

...

So what, set MAX_DAYS_IN_TMP.  Oh wait, that's not the Redhat way.  Yeah right.

No, it matches the historical practice and current default behavior of most other UNIX and UNIX-like operating systems as well as the specified behavior of /tmp according to the FHS 2.3 Chapter 3 and IEEE Std 1003.1 XBD Chapter 10.1.  It should not cause any problems with the software included in openSUSE. Manually putting data into /tmp and expecting it to persist is (and has always been) completely braindamaged.  The openSUSE default install does not put /tmp on a separate partition so filling up /tmp means filling up the root filesystem.

-- Guido Berhoerster

For those of us that have been long term suse users, this is a big change that could easily bite us in the butt when we do that first "zypper dup". I hope there are big pre-upgrade warnings to ensure people don't have data in /tmp they expect to survive an upgrade. Greg -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

Am Montag 03 Mai 2010 schrieb Michael Matz:

On Mon, 3 May 2010, Guido Berhoerster wrote:

...

* Michael Matz [2010-05-03 14:12]:

...

And that's exactly why the default shouldn't be changed. It was a

If I got this right, tmpwatch will now be installed by default and remove files older than 10 days though a daily cronjob, see http://lists.opensuse.org/opensuse-factory/2010-05/msg00020.html So

Whose bullshit idea was that? It's not even configurable and simply https://bugzilla.novell.com/show_bug.cgi?id=594778 handles it.

Greetings, Stephan -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

On Mon, May 03, 2010 at 05:54:45PM +0200, Stefan Seyfried wrote:

On Mon, 3 May 2010 14:49:14 +0200 Guido Berhoerster wrote:

...

If I got this right, tmpwatch will now be installed by default and remove files older than 10 days though a daily cronjob, see holy crap. This bastard tool got installed yesterday during an innocent "zypper up", without any warning and notification, and had I not read your message, I would have had a bad surprise 9 days from now ;-(

I don't think 'zypper up' behaves that way. Do you mean 'zypper dup'? Cheers, Michael. -- Michael Schroeder mls@suse.de SUSE LINUX Products GmbH, GF Markus Rex, HRB 16746 AG Nuernberg main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);} -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

* Michael Foerster [2010-05-02 21:37]:

Esp if login/profile scripts are modified to create a 'private' temp dir, like /dev/shm/$USER and propagate via

export TMP=/dev/shm/$USER TEMP=$TMP TMPDIR=$TMP TEMPDIR=$TMP; mkdir -m 700 -p /dev/shm/$USER

Per-user tmpdirs are also a nice thing to have for security reasons, there's even a pam module which takes care of securely creating a unique per-user tmpdir on login, see http://packages.debian.org/source/sid/pam-tmpdir -- Guido Berhoerster -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

Am 02.05.2010 23:08, schrieb Christian Boltz:

If you really see the need for a recommendation to use the environment variable, please decide before which one is the recommended one.

The real recommendation should be to use the functionality provided by the programming language/framework one is using instead of manually evaluating environment variables. Regards, Bernhard -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

Andreas Jaeger wrote:

...

- Place a script in /etc/tmpdirs.d that creates the directories and

files, you can look at /etc/tmpdirs.d/01_aaa_base from package aaa_base for an example.

Doesn't that make the fastboot people cry? What about using a simple configuration file format like in /etc/permissions and have a while/read loop or a small C program do the actual job? That would potentially also allow to natively integrate the feature into other boot methods that don't rely on scripts. well, actually I was thinking about the read loop initially. For one I was scared it would be slower than script snippets and the snippets do offer more flexibility. If you think all we will ever need there is really "installl -d -m $mode -u $user -g $group $dir"

On Monday 03 May 2010 09:33:56 Ludwig Nussel wrote: then I'm fine with that approach.

Note that the actual implementation in boot.cleanup currently also executes backup files like *.rpmnew etc.

good point, will fix that as soon as the above question is settled. -- with kind regards (mit freundlichem Grinsen), Ruediger Oertel (ro@novell.com,ro@suse.de,bugfinder@t-online.de) ---------------------------------------------------------------------- Linux MacBookRudi.suse.de 2.6.34-rc5-6-desktop #1 SMP PREEMPT 2010-04-22 21:18:20 +0200 x86_64 Key fingerprint = 17DC 6553 86A7 384B 53C5 CA5C 3CE4 F2E7 23F2 B417 SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

On Monday 03 May 2010 09:33:56 Ludwig Nussel wrote:

Andreas Jaeger wrote:

...

- Place a script in /etc/tmpdirs.d that creates the directories and

files, you can look at /etc/tmpdirs.d/01_aaa_base from package aaa_base for an example.

Doesn't that make the fastboot people cry? What about using a simple

IMO yes - since it is invoked at every time. That's why I recommend it as "last resort" or add it only for files used by everybody.

configuration file format like in /etc/permissions and have a while/read loop or a small C program do the actual job? That would potentially also allow to natively integrate the feature into other boot methods that don't rely on scripts.

Andreas -- Andreas Jaeger, Program Manager openSUSE, aj@{novell.com,opensuse.org} Twitter: jaegerandi | Identica: jaegerandi SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126

On 05/03/2010 05:34 PM, Stephan Kulow wrote:

Am Montag 03 Mai 2010 schrieb Dave Plater:

...

Am I wrong or is this going to cause a serious problem for poor people like me with only a gig of ram who do dvd work with programs that default to /tmp for temporary files?

Noone is saying that /var/run _has_ to be on tmpfs. What we say is that a) packages should be able to cope with it b) that it _might_ be a future feature to default to it under certain conditions (as in 11.3+)

And /tmp in ram was just a side note. Packages should cope with that too, but defining good defaults for that will be hard.

Greetings, Stephan

Sorry I've nothing against /var/run although in my unqualified opinion, it should rather be ramfs which wouldn't need to have a large initial size. /tmp being mounted as either ramfs or tmpfs would need a lot of changes in programs that use tmp for large files like dvds for instance moving to /var/tmp. Regards Dave P -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

On Mon, May 03, 2010 at 06:17:35PM +0200, Guido Berhoerster wrote:

* Dave Plater [2010-05-03 18:02]:

...

Sorry I've nothing against /var/run although in my unqualified opinion, it should rather be ramfs which wouldn't need to have a large initial

No, tmpfs grows dynamically and it can be limited to a maximum size.

It has a maximum size unless explicitly disables. Oversizing or even unlimiting tmpfs can deadlock the machine (according to the doc).

...

size. /tmp being mounted as either ramfs or tmpfs would need a lot of changes in programs that use tmp for large files like dvds for instance moving to /var/tmp.

It is just a matter of having a big enough swap partition.

Esp. since during hibernate the content of tmpfs must be written to swap. Regards, Arvin -- Arvin Schnell, Senior Software Engineer, Research & Development SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

* Dave Plater [2010-05-03 19:56]:

...

It is just a matter of having a big enough swap partition.

I'm worrying about protecting my meger 1Gig ram, I've a 1.5 Gig swap mainly because I hibernate regularily and that fails if I have too many tabs open in firefox. I usualy close and save firefox, if I remember. Can you imagine what would happen if /tmp is on any ram based file system and I process a dvd which uses four and a half gig in /tmp. If a change is made like that there are going to be a lot of very unhappy desktop users if, mainly packman packages don't change the default temporary directory.

tmpfs lives in the page cache and is backed by swap, it will not tak away any memory from firefox or other applications. However you would need a bigger partition for hibernation which is large enough to acommodate the tmpfs filesystem as well. BTW, you can create a larger separate partition exclusively for hibernation in order to solve your problem with firefox taking too much memory. -- Guido Berhoerster -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

* Stefan Seyfried [2010-05-03 21:37]:

Yeah. Big swapspace. Good idea if you want to make a machine unusable. But not for normal operation.

If you want to be able to hibernate you already need a big swapspace to acommodate all the memory you intend to use, so I don't see much difference here. When you run your servers with the default install (e.g. without /tmp on a separate partition and MAX_DAYS_IN_TMP=0) there are good chances to make your machine unusable in other ways... -- Guido Berhoerster -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

Hello, 2010-05-04 09:19 keltezéssel, Andreas Jaeger írta:

Btw. the following packages are still using /var/run (in the last published factory):

[...]

syslog-ng

[...]

Some of these might be fixed already but not yet checked into factory,

What needs to be fixed here? I did not follow this discussion, as many posts were emotional rather than technical... I can take care for syslog-ng, if I know, what I need to fix :-) Currently syslog-ng has its pid and ctl file in /var/run, which definitely could stay. There is also a file for additional log sockets generated /etc/init.d/syslogd on each invocation, which is under the directory /var/run/syslog-ng (as discussed with mt). This could me more of a problem. Possible solutions: - move /var/run/syslog-ng to somwhere else. Where? This would involve changing the following packages: syslogd, syslog-ng and apparmor-profiles. - remove the /var/run/syslog-ng directory from the syslog-ng package and create it dynamically by /etc/init.d/syslogd Both solutions have advantages and disadvantages. Rsyslog has the exact same problem, so should be solved the same way. Which one should be chosen? Bye, CzP -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

2010-05-04 10:04 keltezéssel, Andreas Jaeger írta:

On Tuesday 04 May 2010 09:56:29 Peter Czanik wrote:

...

Hello,

2010-05-04 09:19 keltezéssel, Andreas Jaeger írta:

...

Btw. the following packages are still using /var/run (in the last published

...

factory):

[...]

...

syslog-ng

[...]

...

Some of these might be fixed already but not yet checked into factory,

What needs to be fixed here? I did not follow this discussion, as many posts were emotional rather than technical... I can take care for syslog-ng, if I know, what I need to fix :-)

http://lizards.opensuse.org/2010/05/03/preparation-for-mounting-varrun-as- tmpfs/

...

Currently syslog-ng has its pid and ctl file in /var/run, which definitely could stay.

Yes, no problem with that.

...

There is also a file for additional log sockets generated /etc/init.d/syslogd on each invocation, which is under the directory /var/run/syslog-ng (as discussed with mt). This could me more of a problem. Possible solutions:

- move /var/run/syslog-ng to somwhere else. Where? This would involve changing the following packages: syslogd, syslog-ng and apparmor-profiles.

Do this only if you have data that needs to survive a reboot.

...

- remove the /var/run/syslog-ng directory from the syslog-ng package and create it dynamically by /etc/init.d/syslogd

Yes.

...

Both solutions have advantages and disadvantages. Rsyslog has the exact same problem, so should be solved the same way. Which one should be chosen?

Create it if it does not exist,

OK, done: bigone112:/local/tmp/home:czanik:branches:Base:System/syslogd # osc sr created request id 39390 bigone112:/local/tmp/home:czanik:branches:Base:System/syslogd # cd ../syslog-ng/ bigone112:/local/tmp/home:czanik:branches:Base:System/syslog-ng # osc sr created request id 39391 /var/run/syslog-ng is removed from the syslog-ng package and created on demand by /etc/init.d/syslog. Also added some patches to syslog-ng from git, which were made for the openSUSE version of syslog-ng 2.0.9 and now accepted by upstream. Bye, CzP -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

2010-05-04 20:19 keltezéssel, Marcus Rueckert írta:

On 2010-05-04 18:46:04 +0200, Peter Czanik wrote:

...

/var/run/syslog-ng is removed from the syslog-ng package and created on demand by /etc/init.d/syslog. Also added some patches to syslog-ng from git, which were made for the openSUSE version of syslog-ng 2.0.9 and now accepted by upstream.

do not remove it. just make it %ghost %dir /var/run/syslog-ng

OK, previous request revoked, fixed it, and added a new sr: bigone112:/local/tmp/home:czanik:branches:Base:System/syslog-ng # osc sr created request id 39406 Bye, CzP -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org