On 2014-06-21 22:38, Per Jessen wrote:

How about a daily cron job

Dig out the old suse cron job, adjust and reuse it. :-? -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

On Sat, Jun 21, 2014 at 11:35 PM, Jan Ritzerfeld wrote:

Am Samstag, 21. Juni 2014, 22:18:57 schrieb C:

...

What is the "right" way to clean up /tmp? [...]

SInce 12.3 and systemd: https://www.suse.com/releasenotes/i386/openSUSE/12.3/RELEASE-NOTES.en.html#s...

There is an age parameter, see man tmpfiles.d

I wrote a few words about the underlying mechanism some months ago: http://lists.opensuse.org/opensuse/2014-02/msg00545.html

Thanks for the advice everyone. I've cleaned up the /tmp and it seems to be less out of control now. I still have to poke about in my /usr/lib and see what's lurking there that I'm not using and I could clear out (using zypper of course). I'm back to +/-2 to 3 GB of my usual typical install size. That's a bit more... comfortable :-) C -- openSUSE 13.1 x86_64, KDE 4.13 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 06/22/2014 03:45 AM, C wrote:

On Sat, Jun 21, 2014 at 11:35 PM, Jan Ritzerfeld wrote:

...

Am Samstag, 21. Juni 2014, 22:18:57 schrieb C:

...

What is the "right" way to clean up /tmp? [...]

SInce 12.3 and systemd: https://www.suse.com/releasenotes/i386/openSUSE/12.3/RELEASE-NOTES.en.html#s...

There is an age parameter, see man tmpfiles.d

I wrote a few words about the underlying mechanism some months ago: http://lists.opensuse.org/opensuse/2014-02/msg00545.html

Thanks for the advice everyone. I've cleaned up the /tmp and it seems to be less out of control now. I still have to poke about in my /usr/lib and see what's lurking there that I'm not using and I could clear out (using zypper of course). I'm back to +/-2 to 3 GB of my usual typical install size. That's a bit more... comfortable :-)

C

So can anyone explain why the exclusion lines in /etc/tmp.conf # Exclude namespace mountpoints created with PrivateTmp=yes X /tmp/systemd-private-* X /var/tmp/systemd-private-* What are these directory entries, of which I have well over 300, some dating back years (12.3 system). What are they, and why are they excluded from cleaning? -- Explain again the part about rm -rf / -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

El dom 22 jun 2014 17:49:30 CLT, John Andersen escribió:

On 06/22/2014 03:45 AM, C wrote:

...

On Sat, Jun 21, 2014 at 11:35 PM, Jan Ritzerfeld wrote:

...

Am Samstag, 21. Juni 2014, 22:18:57 schrieb C:

...

What is the "right" way to clean up /tmp? [...]

SInce 12.3 and systemd: https://www.suse.com/releasenotes/i386/openSUSE/12.3/RELEASE-NOTES.en.html#s...

There is an age parameter, see man tmpfiles.d

I wrote a few words about the underlying mechanism some months ago: http://lists.opensuse.org/opensuse/2014-02/msg00545.html

Thanks for the advice everyone. I've cleaned up the /tmp and it seems to be less out of control now. I still have to poke about in my /usr/lib and see what's lurking there that I'm not using and I could clear out (using zypper of course). I'm back to +/-2 to 3 GB of my usual typical install size. That's a bit more... comfortable :-)

C

So can anyone explain why the exclusion lines in /etc/tmp.conf # Exclude namespace mountpoints created with PrivateTmp=yes X /tmp/systemd-private-* X /var/tmp/systemd-private-*

What are these directory entries, of which I have well over 300, some dating back years (12.3 system).

What are they,

This are directories where systemd sets up a private /tmp namespace, so services can't "see" or modify each other temporary files. Since the handling of temporary files is sometimes buggy and in many occasions this kind of bugs are security related, many services set PrivateTmp=true

and why are they excluded from cleaning?

Because they are managed exclusively by systemd. note that old systemd versions didn't properly garbage collected this directories, that is probably the reason you have very old ones around. -- Cristian "I don't know the key to success, but the key to failure is trying to please everybody." -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 22/06/14 20:45, C wrote:

On Sat, Jun 21, 2014 at 11:35 PM, Jan Ritzerfeld wrote:

...

Am Samstag, 21. Juni 2014, 22:18:57 schrieb C:

...

What is the "right" way to clean up /tmp? [...] SInce 12.3 and systemd: https://www.suse.com/releasenotes/i386/openSUSE/12.3/RELEASE-NOTES.en.html#s...

There is an age parameter, see man tmpfiles.d

I wrote a few words about the underlying mechanism some months ago: http://lists.opensuse.org/opensuse/2014-02/msg00545.html

Thanks for the advice everyone. I've cleaned up the /tmp and it seems to be less out of control now. I still have to poke about in my /usr/lib and see what's lurking there that I'm not using and I could clear out (using zypper of course). I'm back to +/-2 to 3 GB of my usual typical install size. That's a bit more... comfortable :-)

C

Well, doing what Cristian suggested has decreased my /tmp from 33GB down to 612Kb, and /var/tmp is now only 209MB from (?), ie I didn't take a note of (but it was 'really, really big', I am sure :-D ). BC -- Using openSUSE 13.1, KDE 4.13.2 & kernel 3.15.1-1 on a system with- AMD FX 8-core 3.6/4.2GHz processor 16GB PC14900/1866MHz Quad Channel RAM Gigabyte AMD3+ m/board; Gigabyte nVidia GTX660 GPU -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 23/06/14 17:15, C wrote:

On Mon, Jun 23, 2014 at 9:02 AM, Basil Chupin wrote:

...

...

Thanks for the advice everyone. I've cleaned up the /tmp and it seems to be less out of control now. I still have to poke about in my /usr/lib and see what's lurking there that I'm not using and I could clear out (using zypper of course). I'm back to +/-2 to 3 GB of my usual typical install size. That's a bit more... comfortable :-)

Well, doing what Cristian suggested has decreased my /tmp from 33GB down to 612Kb, and /var/tmp is now only 209MB from (?), ie I didn't take a note of (but it was 'really, really big', I am sure :-D ). I'm wondering.. what changed. In previous releases, I never had to bother with the size of /tmp. It managed itself quite nicely and didn't grow out of control. I'm seeing my /tmp slowly grow again since cleaning it (I didn't set up a cron.. i just cleaned it and have been "watching" it since cleaning). With Basil's /tmp being 33GB and mine 4GB befor a tidy-up... I'm wondering... is some app not behaving nicely here?

When I poked in my /tmp I did notice that Steam has dropped a lot of debris in there that was removed in the cleanup... but it wasn't the only one.

C.

I have no knowledge of anything to do with this 'cleaning up' of /tmp except that long time ago one could set 'MAX Days' in some control file or other (it's in my notebook somewhere, I know) but I am wondering if what Cristian suggested is at the "bottom" of this? Cristian suggested to insert lines d /tmp 1777 root root 10d d /var/tmp 1777 root root 30d in /etc/tmpfiles.d/localtmp.conf -- except that 'localtmp.conf' does not exist, at least not on my system. I had to use nano to manually create this *conf file with those lines. BC -- Using openSUSE 13.1, KDE 4.13.2 & kernel 3.15.1-1 on a system with- AMD FX 8-core 3.6/4.2GHz processor 16GB PC14900/1866MHz Quad Channel RAM Gigabyte AMD3+ m/board; Gigabyte nVidia GTX660 GPU -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Le 23/06/2014 09:32, Basil Chupin a écrit :

Cristian suggested to insert lines

d /tmp 1777 root root 10d d /var/tmp 1777 root root 30d

in /etc/tmpfiles.d/localtmp.conf -- except that 'localtmp.conf' does not exist, at least not on my system.

I had to use nano to manually create this *conf file with those lines.

sources in locate tmpfiles.d /data/mesdocs-jdd/culte/mulet-reborn.bk/etc/tmpfiles.d /etc/tmpfiles.d /usr/lib/tmpfiles.d /usr/lib/tmpfiles.d/gvfsd-fuse-tmpfiles.conf /usr/lib/tmpfiles.d/legacy.conf /usr/lib/tmpfiles.d/lvm2.conf /usr/lib/tmpfiles.d/nscd.conf /usr/lib/tmpfiles.d/openvpn.conf /usr/lib/tmpfiles.d/parallel-printer.conf /usr/lib/tmpfiles.d/samba.conf /usr/lib/tmpfiles.d/screen.conf /usr/lib/tmpfiles.d/svnserve.conf /usr/lib/tmpfiles.d/systemd.conf /usr/lib/tmpfiles.d/tmp.conf /usr/lib/tmpfiles.d/vpnc.conf /usr/lib/tmpfiles.d/x11.conf /usr/share/man/man5/tmpfiles.d.5.gz jdd -- http://www.dodin.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 06/23/2014 03:32 AM, Basil Chupin wrote:

Cristian suggested to insert lines

d /tmp 1777 root root 10d d /var/tmp 1777 root root 30d

in /etc/tmpfiles.d/localtmp.conf -- except that 'localtmp.conf' does not exist, at least not on my system.

Do RTFM TMPFILES.D(5) -- /"\ \ / ASCII Ribbon Campaign X Against HTML Mail / \ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 6/23/2014 12:15 AM, C wrote:

On Mon, Jun 23, 2014 at 9:02 AM, Basil Chupin wrote:

...

...

Thanks for the advice everyone. I've cleaned up the /tmp and it seems to be less out of control now. I still have to poke about in my /usr/lib and see what's lurking there that I'm not using and I could clear out (using zypper of course). I'm back to +/-2 to 3 GB of my usual typical install size. That's a bit more... comfortable :-)

Well, doing what Cristian suggested has decreased my /tmp from 33GB down to 612Kb, and /var/tmp is now only 209MB from (?), ie I didn't take a note of (but it was 'really, really big', I am sure :-D ).

I'm wondering.. what changed. In previous releases, I never had to bother with the size of /tmp. It managed itself quite nicely and didn't grow out of control.

What changed? SystemD. SystemD happened, and it decided it had to take care of cleaning directories instead of allowing the cronjob do it. Why was this necessary? SystemD's mission was to make booting faster. Why in gods name does it have to mess with Cleaning of directories and do such a poor job of it? I'd like to hear a good rational for that. -- _____________________________________ ---This space for rent--- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2014-06-24 00:20, Cristian Rodríguez wrote:

It cleans temporary directories by default just the way the OP wanted. unfortunately someone at SUSE decided to change the default behaviour as well to skip mounting /tmp as tmpfs by default.

Fortunately! >:-) - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlOoyQ8ACgkQtTMYHG2NR9X3/ACfTp1L1q93nLzWCUkhcs2zBR7k qOIAniFFEBJYQMTzagxWyBj1mTkBQtMb =0zMr -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 06/23/2014 03:02 AM, Basil Chupin wrote:

On 22/06/14 20:45, C wrote:

...

On Sat, Jun 21, 2014 at 11:35 PM, Jan Ritzerfeld wrote:

...

Am Samstag, 21. Juni 2014, 22:18:57 schrieb C:

...

What is the "right" way to clean up /tmp? [...] SInce 12.3 and systemd: https://www.suse.com/releasenotes/i386/openSUSE/12.3/RELEASE-NOTES.en.html#s...

There is an age parameter, see man tmpfiles.d

I wrote a few words about the underlying mechanism some months ago: http://lists.opensuse.org/opensuse/2014-02/msg00545.html

Thanks for the advice everyone. I've cleaned up the /tmp and it seems to be less out of control now. I still have to poke about in my /usr/lib and see what's lurking there that I'm not using and I could clear out (using zypper of course). I'm back to +/-2 to 3 GB of my usual typical install size. That's a bit more... comfortable :-)

C

Well, doing what Cristian suggested has decreased my /tmp from 33GB down to 612Kb, and /var/tmp is now only 209MB from (?), ie I didn't take a note of (but it was 'really, really big', I am sure :-D ).

However I get this: # systemd-tmpfiles --clean Two or more conflicting lines for /tmp configured, ignoring. Two or more conflicting lines for /var/tmp configured, ignoring. I think what its _meaning_ is 'two or more conflicting FILES" TMPFILED.D(5) says <quote> Files in /etc/tmpfiles.d override files with the same name in /usr/lib/tmpfiles.d and /run/tmpfiles.d. </quote> I have only the one file in /etc/tmpfiled.s and it reads as per the suggestion in this thread. I'm running # systemd-tmpfiles --version systemd 210 +PAM +LIBWRAP +AUDIT +SELINUX -IMA +SYSVINIT +LIBCRYPTSETUP +GCRYPT +ACL +XZ +SECCOMP +APPARMOR Is there a debug mode for this? -- /"\ \ / ASCII Ribbon Campaign X Against HTML Mail / \ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 06/23/2014 08:52 AM, Basil Chupin wrote:

On 23/06/14 22:44, Anton Aylward wrote:

...

On 06/23/2014 03:02 AM, Basil Chupin wrote:

...

On 22/06/14 20:45, C wrote:

...

On Sat, Jun 21, 2014 at 11:35 PM, Jan Ritzerfeld wrote:

...

Am Samstag, 21. Juni 2014, 22:18:57 schrieb C:

...

What is the "right" way to clean up /tmp? [...] SInce 12.3 and systemd: https://www.suse.com/releasenotes/i386/openSUSE/12.3/RELEASE-NOTES.en.html#s...

There is an age parameter, see man tmpfiles.d

I wrote a few words about the underlying mechanism some months ago: http://lists.opensuse.org/opensuse/2014-02/msg00545.html Thanks for the advice everyone. I've cleaned up the /tmp and it seems to be less out of control now. I still have to poke about in my /usr/lib and see what's lurking there that I'm not using and I could clear out (using zypper of course). I'm back to +/-2 to 3 GB of my usual typical install size. That's a bit more... comfortable :-)

C Well, doing what Cristian suggested has decreased my /tmp from 33GB down to 612Kb, and /var/tmp is now only 209MB from (?), ie I didn't take a note of (but it was 'really, really big', I am sure :-D ).

However I get this:

# systemd-tmpfiles --clean Two or more conflicting lines for /tmp configured, ignoring. Two or more conflicting lines for /var/tmp configured, ignoring.

I think what its _meaning_ is 'two or more conflicting FILES"

TMPFILED.D(5) says <quote> Files in /etc/tmpfiles.d override files with the same name in /usr/lib/tmpfiles.d and /run/tmpfiles.d. </quote>

I have only the one file in /etc/tmpfiled.s and it reads as per the suggestion in this thread.

I'm running

# systemd-tmpfiles --version systemd 210 +PAM +LIBWRAP +AUDIT +SELINUX -IMA +SYSVINIT +LIBCRYPTSETUP +GCRYPT +ACL +XZ +SECCOMP +APPARMOR

Is there a debug mode for this?

"Do RTFM TMPFILES.D(5)"

No debug mode mentioned on the man page, sadly. I would have thought that there would be, or perhaps a mode that explains what it would do but doesn't actually such as we find in, for example, 'rsync'. A mode that explains what is being parsed and why those actions are going to be done would be superb. No mention of anything like this in the man page. Running /strings/ on the binary shows where the getopts dispatch table is but there isn't any undocumented option there. So of you know of a debug mode please do tell. -- /"\ \ / ASCII Ribbon Campaign X Against HTML Mail / \ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 06/23/2014 09:05 AM, Carlos E. R. wrote:

On 2014-06-23 14:44, Anton Aylward wrote:

...

However I get this:

# systemd-tmpfiles --clean Two or more conflicting lines for /tmp configured, ignoring. Two or more conflicting lines for /var/tmp configured, ignoring.

Same here.

Telcontar:~ # systemd-tmpfiles --clean Two or more conflicting lines for /tmp configured, ignoring. Two or more conflicting lines for /var/tmp configured, ignoring. Two or more conflicting lines for /tmp/systemd-private-* configured, ignoring. Two or more conflicting lines for /var/tmp/systemd-private-* configured, ignoring. stat(/run/user/1000/gvfs) failed: Permission denied Telcontar:~ #

And "man systemd-tmpfiles" does not mention a report or verbose mode or syntax check or dry run mode. Nor does "man tmpfiles.d".

+1 -- /"\ \ / ASCII Ribbon Campaign X Against HTML Mail / \ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 23/06/14 18:19, Andrey Borzenkov wrote:

В Mon, 23 Jun 2014 15:05:15 +0200 "Carlos E. R." пишет:

...

On 2014-06-23 14:44, Anton Aylward wrote:

...

However I get this:

# systemd-tmpfiles --clean Two or more conflicting lines for /tmp configured, ignoring. Two or more conflicting lines for /var/tmp configured, ignoring.

Same here.

Telcontar:~ # systemd-tmpfiles --clean Two or more conflicting lines for /tmp configured, ignoring. Two or more conflicting lines for /var/tmp configured, ignoring. Two or more conflicting lines for /tmp/systemd-private-* configured, ignoring. Two or more conflicting lines for /var/tmp/systemd-private-* configured, ignoring.

That more or less matches documentation:

If multiple files specify the same path, the entry in the file with the lexicographically earliest name will be applied, all all other conflicting entries logged as errors.

To avoid these errors you would need to copy /usr/lib/tmpfiles.d/tmp.conf into /etc/tmpfiles.d and edit, so it hides file in /usr/lib.

So since the (relevant) files in /usr/lib/tmpfiles.d and /run/tmpfiles.d are called tmp.conf, and the one Cristian suggested making in /etc/tmpfiles.d/ is called localtmp.conf; the new file is acted upon and the others cause errors. Had the manpage been read, this would have been blindingly obvious - it was here... -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 06/23/2014 03:14 PM, Carlos E. R. wrote:

On 2014-06-23 19:31, Dylan wrote:

...

On 23/06/14 18:19, Andrey Borzenkov wrote:

...

В Mon, 23 Jun 2014 15:05:15 +0200 "Carlos E. R." пишет:

...

On 2014-06-23 14:44, Anton Aylward wrote:

...

However I get this:

# systemd-tmpfiles --clean Two or more conflicting lines for /tmp configured, ignoring. Two or more conflicting lines for /var/tmp configured, ignoring.

Same here.

Telcontar:~ # systemd-tmpfiles --clean Two or more conflicting lines for /tmp configured, ignoring. Two or more conflicting lines for /var/tmp configured, ignoring. Two or more conflicting lines for /tmp/systemd-private-* configured, ignoring. Two or more conflicting lines for /var/tmp/systemd-private-* configured, ignoring.

That more or less matches documentation:

If multiple files specify the same path, the entry in the file with the lexicographically earliest name will be applied, all all other conflicting entries logged as errors.

To avoid these errors you would need to copy /usr/lib/tmpfiles.d/tmp.conf into /etc/tmpfiles.d and edit, so it hides file in /usr/lib.

...

So since the (relevant) files in /usr/lib/tmpfiles.d and /run/tmpfiles.d are called tmp.conf, and the one Cristian suggested making in /etc/tmpfiles.d/ is called localtmp.conf; the new file is acted upon and the others cause errors. Had the manpage been read, this would have been blindingly obvious - it was here...

It is not obvious to me. I still do not understand what happens, even after reading the manpage several times.

For instance, what exact lines are conflicting, and from what exact files are they being read? I still do not see a "--verbose" or "--debug" option that would tell me that.

I agree, not only with the point about the lack of "--verbose" or "--debug" (or "--explain") but with it NOT being obvious. Yes a /etc/tmpfiles.d/tmp.conf would override the one in /usr/lib. But that's not the point. The localtemp.conf Does not override any lines in tmp.conf, it add lines that don't exit. It does not contradict them. It suplements them. The closest I can see to a problem lies in this phrase: <quote> All configuration files are sorted by their filename in lexicographic order, regardless of which of the directories they reside in. If multiple files specify the same path, the entry in the file with the lexicographically earliest name will be applied, all all other conflicting entries logged as errors. </quote> That means localtemp comes before tmp. Maybe it should be renamed "zzlocaltemp" Well, no, it seems that interpretation of tha man page is not correct either: # mv localtmp.conf zzlocaltmp.conf # systemd-tmpfiles --remove --clean Two or more conflicting lines for /tmp configured, ignoring. Wrote > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 В Mon, 23 Jun 2014 21:14:50 +0200 "Carlos E. R." пишет:

It is not obvious to me. I still do not understand what happens, even after reading the manpage several times.

For instance, what exact lines are conflicting,

Any two lines that specify the same path and are not exactly the same will conflict.

and from what exact files are they being read? I still do not see a "--verbose" or "--debug" option that would tell me that.

Yes, error message could be more clear, at least tell in which file line is ignored. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlOogz4ACgkQR6LMutpd94x8PACgmnxccha4Hi8aQdktgXJhG20F QEMAoNRharK28/GbrRzf+XR5qW3FxDON =PgxI -----END PGP SIGNATURE-----

El 23/06/14 17:35, Anton Aylward escribió:

Chistian: could you bump this 'upstairs' for comment please.

This is the expected behaviour..however I agree that it should tell which lines conflict with one another. -- Cristian "I don't know the key to success, but the key to failure is trying to please everybody." -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2014-06-24 00:04, Cristian Rodríguez wrote:

El 23/06/14 17:35, Anton Aylward escribió:

...

Chistian: could you bump this 'upstairs' for comment please.

This is the expected behaviour..however I agree that it should tell which lines conflict with one another.

Then, if we want temp dirs to be cleared _our_ way, it is not enough to create files in "/etc/tmpfiles.d/", but delete the distribution provided entries in the files in "/usr/lib/tmpfiles.d/". This is contrary to the behaviour with "/etc/systemd/system/", which I understand supersedes "/usr/lib/systemd/system/", so we can have our local configs. And, what you said that we could create "/etc/tmpfiles.d/localtmp.conf" simply does not work. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlOozDIACgkQtTMYHG2NR9UdyQCeJqDT6O0DsVKbVQq3oGdRZiUj k7wAmwaU9oytizJQGDWFEkV5gsbTNLPp =hG9V -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2014-06-24 02:56, Cristian Rodríguez wrote:

El 23/06/14 20:54, Carlos E. R. escribió:

...

This is contrary to the behaviour with "/etc/systemd/system/", which I understand supersedes "/usr/lib/systemd/system/", so we can have our local configs.

It is not contrary../etc/tmpfiles.d with the same name replace those in /usr/lib...

The entire file gets replaced? Not just the lines for the same jobs?

...

And, what you said that we could create "/etc/tmpfiles.d/localtmp.conf" simply does not work.

Yes, I messed that up..

Never mind, as long as we finally figure out how to do it :-) - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlOozs8ACgkQtTMYHG2NR9U6zwCffKqGul8ihW691jr+6EcXoLZe IBAAnRBNcZh2Yy0qPm4x+peyMGEkogap =5Ick -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 6/23/2014 12:14 PM, Carlos E. R. wrote:

...

So since the (relevant) files in /usr/lib/tmpfiles.d and

...

/run/tmpfiles.d are called tmp.conf, and the one Cristian suggested making in /etc/tmpfiles.d/ is called localtmp.conf; the new file is acted upon and the others cause errors. Had the manpage been read, this would have been blindingly obvious - it was here...

It is not obvious to me. I still do not understand what happens, even after reading the manpage several times.

The problem is in the first paragraph above. The thread is so muddeled now that nobody can figure it out. Somebody, (perhaps it was Christian) said: making in /etc/tmpfiles.d/ is called localtmp.conf; That is wrong, according to my man file reading. tmp.conf is ALREADY a local copy of the one in /usr/lib/tmpfiles.d and /etc/tmpfiles.d/tmp.conf IS THE ONE you should edit with your local changes. Adding another one called /etc/tmpfiles.d/localtmp.conf just confuses the issue. Once you do make a localtmp.conf you have conflicting specifications. Just edit /etc/tmpfiles.d/tmp.conf, that's all that is needed. If you fuckitup(tm) just delete it and it reverts to the system supplied one in /usr/lib/tmpfiles.d. - -- _____________________________________ - ---This space for rent--- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAlOojQ8ACgkQv7M3G5+2DLIpBACbB1YfZ/HSBfWmiZW4aPemZ98a MB4Anjs76o7Qgv41KnYGwrRay78XZZ42 =v9Y8 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 В Tue, 24 Jun 2014 03:03:38 +0200 "Carlos E. R." пишет:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On 2014-06-23 22:24, John Andersen wrote:

...

On 6/23/2014 12:14 PM, Carlos E. R. wrote:

...

That is wrong, according to my man file reading.

tmp.conf is ALREADY a local copy of the one in /usr/lib/tmpfiles.d and /etc/tmpfiles.d/tmp.conf IS THE ONE you should edit with your local changes.

Adding another one called /etc/tmpfiles.d/localtmp.conf just confuses the issue. Once you do make a localtmp.conf you have conflicting specifications.

Just edit /etc/tmpfiles.d/tmp.conf, that's all that is needed.

I don't have that file.

So, I copy "/usr/lib/tmpfiles.d/tmp.conf" to "/etc/tmpfiles.d/tmp.conf", and I leave there only the lines I want to modify:

d /tmp 1777 root root 100d d /var/tmp 1777 root root 300d

Now, does this mean that the other lines not conflicting with those two in "/usr/lib/tmpfiles.d/tmp.conf" keep working, or does it mean that the entire "/usr/lib/tmpfiles.d/tmp.conf" is ignored, and only my "/etc/tmpfiles.d/tmp.conf" is used?

The later - entire /usr/lib/tmpfiles.d/tmp.conf is ignored. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlOo4fMACgkQR6LMutpd94zklwCghkvIy0ZIz6w+C1vcPNi077rJ PjUAoLetnxR6VmMBgIsAKOr0BiIDgBs6 =Gp6E -----END PGP SIGNATURE-----

24 июня 2014 г., в 6:53, "Carlos E. R." написал(а):

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

...

On 2014-06-24 04:26, Andrey Borzenkov wrote: В Tue, 24 Jun 2014 03:03:38 +0200 "Carlos E. R." <> пишет:

...

...

Now, does this mean that the other lines not conflicting with those two in "/usr/lib/tmpfiles.d/tmp.conf" keep working, or does it mean that the entire "/usr/lib/tmpfiles.d/tmp.conf" is ignored, and only my "/etc/tmpfiles.d/tmp.conf" is used?

The later - entire /usr/lib/tmpfiles.d/tmp.conf is ignored.

That poses a problem for upgrades.

If I copy that file, modify it to my liking, then the distribution, in an update or upgrade changes something in the lines I did not touch, or add new lines: I will not get that upgrade. I will not even notice about it!

How is it different from the case of file in /etc marked as configuration? You won't get new version if you change it as well. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 В Tue, 24 Jun 2014 18:16:33 +0200 "Carlos E. R." пишет:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On 2014-06-24 05:57, arvidjaar@gmail.com wrote:

...

How is it different from the case of file in /etc marked as configuration? You won't get new version if you change it as well. --

I do get a notice. Either the new config file is marked as ".rpmnew", or my old one gets renamed to ".rpmsave", and the new one is activated.

The service "rpmconfigcheck" tells me about it on every boot - but you will not see this if you have the splash screen active. That's why I disable it. Or one of the reasons ;-)

It is disabled here. I do not remember doing it intentionally, so may be it is not default? May be someone needs to think about adapting it to modern realities ... as long as we have to live with modern realities. Regarding the thread topic - personally I think tmpfiles.d is overused and pushed far beyond its original use case - pre-creating directories on tmpfs during boot. In particular, current implementation makes it impossible to a) periodically clean /tmp b) skip /tmp/systemd-private-* during this periodical cleanup (it is a must) c) remove /tmp/systemd-private-* on boot because you can only specify either b) or c). -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlOprLoACgkQR6LMutpd94ynCwCgmv8H4eu4ufhc4ZH/ZeVh2Iel P6UAnRXI0brJ1ph8+0U0acjuoQcCk7tU =Zo0t -----END PGP SIGNATURE-----

El 24/06/14 14:04, Carlos E. R. escribió:

This way /tmp/systemd-private-* can also be purged during use, if wanted.

No, nothing other than systemd should touch that directories..running services will break, including systemd own's services..in current incarnations, systemd itself uses this feature for its own helpers and it is not limited to just temporary files..but include private device nodes and possibly private mount points. -- Cristian "I don't know the key to success, but the key to failure is trying to please everybody." -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 24/06/14 09:00, jdd wrote:

Le 24/06/2014 04:26, Andrey Borzenkov a écrit :

...

The later - entire /usr/lib/tmpfiles.d/tmp.conf is ignored.

this seems the only way to remove one particular line.

I also d'ont understand why /tmp should not be in tmpfs.

A some of us have already commented, some software generates large amounts of data in temp files - if /tmp was in tmpfs on my machine it would quickly get overloaded when I run physics simulations for 3d graphics rendering, for example.

tmp files are just that, temporary! that mean "can be removed at any time".

Yes, they're temporary, but not necessarily small and not necessarily few.

tmpfiles are only removed at boot.

I have temp fomders on my install, and I know that these files can be removed, if I forgot to backup them, my bad...

this is specially true for large file, that should never be written to /tmp. / is not intended to receive large files.

A - Where do you get that little nugget from? B - /tmp (or /var/tmp) are not necessarily on the same partition as / : I have /tmp and /var mounted on a separate drive from / (and /home) for exactly the reason mentioned above.

defaut / size are often under 10Gb.

Are they? Dx -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 24/06/14 09:52, jdd wrote:

Le 24/06/2014 10:29, Dylan a écrit :

...

A some of us have already commented, some software generates large amounts of data in temp files - if /tmp was in tmpfs on my machine it would quickly get overloaded when I run physics simulations for 3d graphics rendering, for example.

making HD video I know what are temporary large files, but make them in /tmp is just a way to kill any system - can you host 3 Blu-Ray images in your /tmp?

Yes, if I wanted to

...

...

this is specially true for large file, that should never be written to /tmp. / is not intended to receive large files.

A - Where do you get that little nugget from?

as big as you make the /, you can always kill your system this way

This isn't an answer to my question: Where do you get the idea that "large file[s...] should never be written to /tmp. / is not intended to receive large files"?

...

B - /tmp (or /var/tmp) are not necessarily on the same partition as / : I have /tmp and /var mounted on a separate drive from / (and /home) for exactly the reason mentioned above.

so you use applications that makes tmp files grow without control?

No, I use applications which create very many quite large tmpfiles with good control and garbage collection.

openSUSE Linux is a multiuser multitask system, allowing one user or one application to kill the system is IMHO a very bad practice.

Which is more likely if /tmp is in RAM, IMHO

...

...

defaut / size are often under 10Gb.

Are they?

yes

Without some kind of supporting reference you might as well say the Earth is flat -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 24/06/14 10:23, jdd wrote:

Le 24/06/2014 11:09, Dylan a écrit :

...

No, I use applications which create very many quite large tmpfiles with good control and garbage collection.

and do not control where these files are stored? pretty surprising. I have seen this on Windows, but on Linux?

And how does one go about configuring mktemp() on a per-application, or worse per-project, basis?

...

...

...

...

defaut / size are often under 10Gb.

Are they?

yes

Without some kind of supporting reference you might as well say the Earth is flat

15 years and probably more than 1000 linux installs using nearly always the default of any distribution, using Hosting providers default installs... most defaults under 8Gb, only recently seen 20Gb default for 1Tb disks.

I don't say your particular install do not need hacking, but it's very uncommon.

But you do generalise from the specific case of hosted (possibly virtual) servers where (A) storage capacity is likely charged on a per [M|G]B basis (either explicitly or as part of the package cost); and (B) the installation is less likely to include e.g. GUI DEs or office/productivity suites... Dx -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2014-06-24 12:03, jdd wrote:

Le 24/06/2014 11:58, Dylan a écrit :

...

And how does one go about configuring mktemp() on a per-application, or worse per-project, basis?

kdenlive do not write work files in /tmp!

Mozilla does. Click on a pdf or another large file, click on view, not download. It goes into /tmp. Some tools I have used to create an iso, use /tmp. For instance, k3b, I just looked: the default destination is "/tmp/kde-cer/". That can be about 4.7 GB per disk. You can change the default, yes, but that is the default. YaST backup uses /tmp to first create a compressed copy of what it is going to backup - and if you tell it to backup home, it can be terabytes.

...

But you do generalise from the specific case of hosted (possibly virtual) servers where (A) storage capacity is likely charged on a per [M|G]B basis (either explicitly or as part of the package cost); and (B) the installation is less likely to include e.g. GUI DEs or office/productivity suites...

not at all.

I speak mostly of setting a dvd in the reader and clic install, all default

But most serious users customize the defaults. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2014-06-24 17:13, jdd wrote:

Le 24/06/2014 15:34, Carlos E. R. a écrit :

That said to go back to the subject, /tmp in tmpfs would be a strong commitment to have large files elsewhere, and making it easy to move from one distribution to an other (upgrade) is a strong reason to keep /home separate. so the right way depends of your usage :-(

But it is part of the Linux standard, so to say, to have "/tmp", and that it is the default temporary disk space. It is already a standard. Changing it would break things. It is just up to the system administrator to decide if HE wants /tmp to be a directory in "/", a separate disk partition, or tmpfs. HE decides, based on what he is going to use the machine for. Distributions just make sensible defaults, allowing the administrators to change them. They simply make defaults that should work for most people. And having "/tmp" in disk has a higher probability of working right than having it in RAM, by default choice. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlOpnykACgkQtTMYHG2NR9VEMgCfeNsDtqFjYFtcbihhLsb5XFr7 XwYAn2eb5PMYGvoDGq4slX6Rba1HWqzQ =wnGK -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2014-06-24 11:23, jdd wrote:

Le 24/06/2014 11:09, Dylan a écrit :

...

No, I use applications which create very many quite large tmpfiles with good control and garbage collection.

and do not control where these files are stored? pretty surprising. I have seen this on Windows, but on Linux?

No, this is a standard, and it is the same in Windows, by the way. There is (on both systems) a system defined place for storing temporary files, and it can be as large as needed. Terabytes, if needed. There is no standard limiting this. Applications simply ask the system where to store temporary files, and use it. Some applications can supersede the system-wide config, and use a local definition for temporary space.

I don't say your particular install do not need hacking, but it's very uncommon.

Not at all. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlOpfAAACgkQtTMYHG2NR9V7AQCfe94RYhRIu1IREJCshNbXvK67 UgAAn065R8OasPHxwLvUKYtDwGUvRsVr =buh6 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2014-06-25 15:17, Herbert Graeber wrote:

Am 24.06.2014 15:24, schrieb Carlos E. R.:

more work to change from tmpfs to a real disk. So tmps is a good default for most users on actual hardware.

I think not. My /tmp is normally small, at this moment, 300 MB. But I'd rather have that RAM available for programs, and I don't know when a program may need way more. For instance, k3b, uses tmp for temporary DVD iso creation. YaST backup creates the backup image there, and THIS can be huge. Applications like mozilla do some downloads there, too. Besides, I prefer /tmp to be persistent, in case of reboot or crashes. I would consider a tmpfs only if I could limit the RAM usage to something small, and force overflow to swap (or disk directory) early. That is, as a specialized disk cache for a special directory. An hybrid. As a default distribution setting, it is safer to keep /tmp on real disk, than on tmpfs. On tmpfs would cause interesting crashes for people not expecting it. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlOq0AoACgkQtTMYHG2NR9UkogCeO2qR2aCxIw97hs7/yFFgZejc qwsAn3kp/VfcjfiB/DwIyENEXXYrbl6M =UCSm -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2014-06-25 16:33, Anton Aylward wrote:

On 06/25/2014 09:35 AM, Carlos E. R. wrote:

As they say "YMMV" As I say "Context is everything"

Absolutely :-)

...

I would consider a tmpfs only if I could limit the RAM usage to something small, and force overflow to swap (or disk directory) early. That is, as a specialized disk cache for a special directory. An hybrid.

Years ago, Mike Tilson wrote a disk driver for V7 UNIX that kept the inode table in memory. Its since been outdated by better inode caching and by pathname caching and more. Perhaps what we need isn't so much a tmpfs as a better trade-off of the way memory is used. Perhaps a FUSE can do this, but it would need to be metricated. Many imaginative ideas don't hold up in the real world.

Years ago, in MsDOS, I had a third party disk cache that could be applied to a single partition, IIRC. That's basically it, dedicate a cache with fixed ram space to a single directory, in this case, "/tmp". Most accesses would work only in RAM, it would be persistent, and size would not be a problem. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlOq6GoACgkQtTMYHG2NR9UuwQCfcbpCMCrxWHT6f+mfubjthndc KpEAnR+HruzqomR+AeTdk0UvDQst5gdo =xhz9 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2014-06-25 17:43, Anton Aylward wrote:

On 06/25/2014 11:19 AM, Carlos E. R. wrote:

...

Years ago, in MsDOS, I had a third party disk cache that could be applied to a single partition, IIRC.

That's basically it, dedicate a cache with fixed ram space to a single directory, in this case, "/tmp". Most accesses would work only in RAM, it would be persistent, and size would not be a problem.

Yes but is it worth it? We have inode caching. We have file pathname lookup caching. We have page caching that amounts to file content caching.

The issue is this:

* Is it smart enough? * Would giving preference to /tmp for any of the above degrade performance in other areas?

Sometimes the admin may know things that the kernel does not :-) For instance. If I'm playing a DVD, or a movie from an iso file, I'm not interested in the system caching the entire file. In fact, I'm not interested in caching it at all. Or, if I'm coping a bunch of files, I do want the inodes and such cached, but not the contents, because as in the previous case, I only need the contents once. Read once, write once on another place, be done. Having the previous used file contents in cache when I read the next is a waste. In fact, I learned bout this reading xine docs, where they mentioned using some type of raw read library in order to impede the kernel caching movies. The cache is much more useful on files that often read and written, continuously. Thus if you can tell the kernel the areas not to cache, it can dedicate more effort on others. And the other way round. People like tmp on a tmpfs because it is very fast. Data and metadata are in memory. The problem, for other people, is that the size is limited, or it can impact other programs needing ram. If it grows a lot, it will cause swapping. Will it cause application memory to be swapped out in order to write a temporary file? I do not want that! (On the other hand, what is the purpose of having tmp in ram? The application could directly store that data in ram and skip the effort. If it uses a tmp file is to conserve ram, no? On the other hand, there are intermediary results and pipes and such. Just thinking aloud) If we had an hybrid tmpfs, limited to a fixed ram value, overflowing to disk when needed (not swap, perhaps), or a dedicated and limited cache on a certain directory, it would be ram-speed fast on small usages, and disk based for large files, and everybody could be happy. Worth it? Dunno. For me, probably. :-)

Years ago I worked on a project where the PM didn't understand 'systems'. He didn't understand that C deals with dynamic variables on the stack, he still thought of C as 'Fortran with semicolons' and required that all variables be global. That buggered up many nested loops! I had to metricate the compiler to show that the global segment was via a pointer. This was on the VAX. Global variables were no faster than locals. Another of his idiocies was a lack of understanding of how virtual memory and page caching works. He required each program to be locked in memory. Think about that. I made sure that my code was small (and hence fast) and so small that the memory allocators pretty much ignored it. Because I made heavy use of shared libraries my read code only amounted to a couple of the 4K pages.

:-)

So my question becomes this: unless you have lots of memory (so that you never even swap) then what is the advantage in this? The system is already caching the inodes and paths you use a lot. Your machine might want to swap out unused apps to speed up disk access of running ones.

The idea is to cache file content as well, in order to get the performance of a tmpfs, at least till the usage passes a given amount. That it behaves like a tmpfs till, say, 500 MB are used, and beyond that, like a hard disk, so that you can write terabytes if you need to.

I think this is another case where the machine knows more about what's going on than you do in the 95% case. Yes, we have the fringe use-cases like the phone/image rendering that uses big, persistent temp files, and the development situation where the compiler is using small transient ones. The sysadmin should pay attention. And yes there are ways to tune this. In the limiting case we should be able to creat a tmfs and set

TMP=/var/specialtmp

in the application environment. But will it be honoured?

See 15.1.7 http://doc.opensuse.org/products/draft/SLES/SLES-tuning_sd_draft/cha.tuning....

That's quite complicated to adjust, and get good results... -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

On 2014-06-27 04:11, Cristian Rodríguez wrote:

El 26/06/14 21:50, Carlos E. R. escribió:

...

Sometimes the admin may know things that the kernel does not :-)

Have you seen the kernel memory management code ?

Not really, no. I'm sure they know a lot more than me, and things have changed a lot since I studied such things :-)

I am very skeptical about that statement.. kernel developers have gone into excruciating pain tuning the implementation to deal with the most obscure, corner cases you can imagine.. it almost always knows better.

Most often it does, I agree. Then I see reports of people with computers that become useless when copying a large directory to/from an external usb disk. That should not happen. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

On 06/26/2014 09:50 PM, Carlos E. R. wrote:

The cache is much more useful on files that often read and written, continuously.

WHICH CACHE? If you mean the file content buffers in VM then I agree. If you mean the means by which the vfs caches other things such as the inodes of the directories traversed to get to a file, and the name segments, then no, they get used by other processes on a LRU basis. And by the way, if you read the documentation, all this is tunable. How much is tunable on a per process or per uid basis, I'm not sure, but yes, if the sysadmin 'knows better' he can make a difference. -- /"\ \ / ASCII Ribbon Campaign X Against HTML Mail / \ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Dne Po 23. června 2014 08:44:13, Anton Aylward napsal(a):

On 06/23/2014 03:02 AM, Basil Chupin wrote:

...

On 22/06/14 20:45, C wrote:

...

On Sat, Jun 21, 2014 at 11:35 PM, Jan Ritzerfeld wrote:

...

Am Samstag, 21. Juni 2014, 22:18:57 schrieb C:

...

What is the "right" way to clean up /tmp? [...]

SInce 12.3 and systemd: https://www.suse.com/releasenotes/i386/openSUSE/12.3/RELEASE-NOTES.en.ht ml#sec.123.systemd-tmpdir

There is an age parameter, see man tmpfiles.d

I wrote a few words about the underlying mechanism some months ago: http://lists.opensuse.org/opensuse/2014-02/msg00545.html

Thanks for the advice everyone. I've cleaned up the /tmp and it seems to be less out of control now. I still have to poke about in my /usr/lib and see what's lurking there that I'm not using and I could clear out (using zypper of course). I'm back to +/-2 to 3 GB of my usual typical install size. That's a bit more... comfortable :-)

C

Well, doing what Cristian suggested has decreased my /tmp from 33GB down to 612Kb, and /var/tmp is now only 209MB from (?), ie I didn't take a note of (but it was 'really, really big', I am sure :-D ).

However I get this:

# systemd-tmpfiles --clean Two or more conflicting lines for /tmp configured, ignoring. Two or more conflicting lines for /var/tmp configured, ignoring.

# systemd-tmpfiles --clean stat(/run/user/1000/gvfs) failed: Permission denied What? V. -- Vojtěch Zeisek Komunita openSUSE GNU/Linuxu Community of the openSUSE GNU/Linux http://www.opensuse.org/ http://trapa.cz/

On 06/23/2014 10:56 AM, Carlos E. R. pecked at the keyboard and wrote:

On 2014-06-23 15:27, Vojtěch Zeisek wrote:

...

# systemd-tmpfiles --clean stat(/run/user/1000/gvfs) failed: Permission denied

What?

No, that one is expected. That directory gets "dr-x------" permissions, and 'root' can not look inside. Many tools (even systemd) have not been told not to try look inside it.

I found another interesting item:

cer@Telcontar:/run/user/1000> l /run/user/1000 | \ grep icedteaplugin-cer | wc -l 1458 cer@Telcontar:/run/user/1000>

That is, "icedteaplugin" produced no less than 1458 (empty) directories in there!

And all are dated Jun 15 (my current uptime is 29 days).

I have no such after adjusting for my login name. -- Ken Schneider SuSe since Version 5.2, June 1998 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 06/23/2014 04:59 AM, Rainer Klier wrote:

Am 22.06.2014 13:40, schrieb Bruce Ferrell:

...

https://forums.opensuse.org/showthread.php/491654-openSUSE-13-1-RC2-%28relea...

and unfortunately the driver doesn't build against kernel linux-3.15.1-34.gee8dd2b

Anyone have a thought on how to get it to build? you need this patch: http://ubuntuforums.org/showthread.php?t=2216779&page=2

it works for me on kernel 3.15

Well, I tried that on 3.15.1 adjusting the patch as required: #if LINUX_VERSION_CODE >= KERNEL_VERSION(3, 15, 1) cfg80211_ibss_joined(ndev, (u8 *)&wl->bssid, &wl->conf->channel, GFP_KERNEL); #else cfg80211_ibss_joined(ndev, (u8 *)&wl->bssid, GFP_KERNEL); #endif for the version shift and got this: KBUILD_NOPEDANTIC=1 make -C /lib/modules/`uname -r`/build M=`pwd` make[1]: Entering directory `/usr/src/linux-3.15.1-35.g3289da4-obj/x86_64/desktop' CFG80211 API is prefered for this kernel version Using CFG80211 API make[4]: *** No rule to make target `/home/bferrell/asus-wireless/bcmwl-6.30.223.141+bdcom/src/shared/linux_osl.o', needed by `/home/bferrell/asus-wireless/bcmwl-6.30.223.141+bdcom/wl.o'. Stop. make[3]: *** [_module_/home/bferrell/asus-wireless/bcmwl-6.30.223.141+bdcom] Error 2 make[2]: *** [sub-make] Error 2 make[1]: *** [all] Error 2 make[1]: Leaving directory `/usr/src/linux-3.15.1-35.g3289da4-obj/x86_64/desktop' make: *** [all] Error 2 :~/asus-wireless/bcmwl-6.30.223.141+bdcom> -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

* Rainer Klier [06-27-14 02:58]:

Am 27.06.2014 02:47, schrieb Bruce Ferrell:

...

On 06/23/2014 04:59 AM, Rainer Klier wrote:

...

Am 22.06.2014 13:40, schrieb Bruce Ferrell:

...

for the version shift and got this:

KBUILD_NOPEDANTIC=1 make -C /lib/modules/`uname -r`/build M=`pwd` make[1]: Entering directory `/usr/src/linux-3.15.1-35.g3289da4-obj/x86_64/desktop' CFG80211 API is prefered for this kernel version Using CFG80211 API make[4]: *** No rule to make target `/home/bferrell/asus-wireless/bcmwl-6.30.223.141+bdcom/src/shared/linux_osl.o', needed by `/home/bferrell/asus-wireless/bcmwl-6.30.223.141+bdcom/wl.o'. Stop. make[3]: *** [_module_/home/bferrell/asus-wireless/bcmwl-6.30.223.141+bdcom] Error 2 make[2]: *** [sub-make] Error 2 make[1]: *** [all] Error 2 make[1]: Leaving directory `/usr/src/linux-3.15.1-35.g3289da4-obj/x86_64/desktop' make: *** [all] Error 2 :~/asus-wireless/bcmwl-6.30.223.141+bdcom>

maybe you miss one of the previous patches. there were some other patches to support kernel versions prior to 3.15.

to speed things up, here is my currently used, patched and working source package of this driver:

https://drive.google.com/file/d/0Bwpj5Wm8iVh-MUlkbHhLU1RBOWc/edit?usp=sharin...

Please try and find a patch to not hijack threads, then start a new thread instead of poluting information if an existing one. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535 @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Fri, Jun 27, 2014 at 1:01 PM, Bruce Ferrell wrote:

On 06/27/2014 03:52 AM, Patrick Shanahan wrote:

...

* Rainer Klier [06-27-14 02:58]:

...

Am 27.06.2014 02:47, schrieb Bruce Ferrell:

...

On 06/23/2014 04:59 AM, Rainer Klier wrote:

...

Am 22.06.2014 13:40, schrieb Bruce Ferrell:

for the version shift and got this:

KBUILD_NOPEDANTIC=1 make -C /lib/modules/`uname -r`/build M=`pwd` make[1]: Entering directory `/usr/src/linux-3.15.1-35.g3289da4-obj/x86_64/desktop' CFG80211 API is prefered for this kernel version Using CFG80211 API make[4]: *** No rule to make target

`/home/bferrell/asus-wireless/bcmwl-6.30.223.141+bdcom/src/shared/linux_osl.o', needed by `/home/bferrell/asus-wireless/bcmwl-6.30.223.141+bdcom/wl.o'. Stop. make[3]: *** [_module_/home/bferrell/asus-wireless/bcmwl-6.30.223.141+bdcom] Error 2 make[2]: *** [sub-make] Error 2 make[1]: *** [all] Error 2 make[1]: Leaving directory `/usr/src/linux-3.15.1-35.g3289da4-obj/x86_64/desktop' make: *** [all] Error 2 :~/asus-wireless/bcmwl-6.30.223.141+bdcom>

maybe you miss one of the previous patches. there were some other patches to support kernel versions prior to 3.15.

to speed things up, here is my currently used, patched and working source package of this driver:

https://drive.google.com/file/d/0Bwpj5Wm8iVh-MUlkbHhLU1RBOWc/edit?usp=sharin...

Please try and find a patch to not hijack threads, then start a new thread instead of poluting information if an existing one.

Patrick, There was no "thread hijacking" as you like to call it. He was very helpfully responding to MY request for assistance to the list so I can pretty definitively say this.

If you can't be helpful (as you almost never are) then sit down and shut up!

the only list pollution here is you.

Sorry Mr Ferrell, but the thread WAS hijacked by you. You took an existing thread email, deleted the contents, changed the subject and asked your question. This breaks threading in email clients, and interleaves your question into the thread, mixing things up rather effectively (and makes it rather messy in threading email clients.. ie most email clients). The solution? Always create a NEW email for a new topic. Never "re-use" an old email as you did. C. -- openSUSE 13.1 x86_64, KDE 4.13 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Fri, 2014-06-27 at 13:45 +0200, jdd wrote:

Le 27/06/2014 13:36, C a écrit :

...

The solution? Always create a NEW email for a new topic. Never "re-use" an old email as you did.

ie: right clic on the list adress, email to and voilà

jdd

-- http://www.dodin.org

I am running Ubuntu 14.04. How do I install firefox? L x -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Fri, Jun 27, 2014 at 1:56 PM, Bruce Ferrell wrote:

On 06/27/2014 04:36 AM, C wrote:

...

On Fri, Jun 27, 2014 at 1:01 PM, Bruce Ferrell wrote:

...

On 06/27/2014 03:52 AM, Patrick Shanahan wrote:

...

* Rainer Klier [06-27-14 02:58]:

...

Am 27.06.2014 02:47, schrieb Bruce Ferrell:

...

On 06/23/2014 04:59 AM, Rainer Klier wrote: > > Am 22.06.2014 13:40, schrieb Bruce Ferrell: > for the version shift and got this:

KBUILD_NOPEDANTIC=1 make -C /lib/modules/`uname -r`/build M=`pwd` make[1]: Entering directory `/usr/src/linux-3.15.1-35.g3289da4-obj/x86_64/desktop' CFG80211 API is prefered for this kernel version Using CFG80211 API make[4]: *** No rule to make target

`/home/bferrell/asus-wireless/bcmwl-6.30.223.141+bdcom/src/shared/linux_osl.o', needed by `/home/bferrell/asus-wireless/bcmwl-6.30.223.141+bdcom/wl.o'. Stop. make[3]: *** [_module_/home/bferrell/asus-wireless/bcmwl-6.30.223.141+bdcom] Error 2 make[2]: *** [sub-make] Error 2 make[1]: *** [all] Error 2 make[1]: Leaving directory `/usr/src/linux-3.15.1-35.g3289da4-obj/x86_64/desktop' make: *** [all] Error 2 :~/asus-wireless/bcmwl-6.30.223.141+bdcom>

maybe you miss one of the previous patches. there were some other patches to support kernel versions prior to 3.15.

to speed things up, here is my currently used, patched and working source package of this driver:

https://drive.google.com/file/d/0Bwpj5Wm8iVh-MUlkbHhLU1RBOWc/edit?usp=sharin...

Please try and find a patch to not hijack threads, then start a new threadr

instead of poluting information if an existing one.

Patrick, There was no "thread hijacking" as you like to call it. He was very helpfully responding to MY request for assistance to the list so I can pretty definitively say this.

If you can't be helpful (as you almost never are) then sit down and shut up!

the only list pollution here is you.

No sir, I suggest that you look into the list archive. I started thread, posting with the original topic on regarding the Asus system. Nor did I reply to the topic on how to clear tmp. I can prove it from my mail logs.

You too are a troll. go away

OK... fine... whatever. Have a nice day. Sigh... yah.. whatever. C. -- openSUSE 13.1 x86_64, KDE 4.13 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 06/26/2014 11:56 PM, Rainer Klier wrote:

...

On 06/23/2014 04:59 AM, Rainer Klier wrote:

...

Am 22.06.2014 13:40, schrieb Bruce Ferrell:

for the version shift and got this:

KBUILD_NOPEDANTIC=1 make -C /lib/modules/`uname -r`/build M=`pwd` make[1]: Entering directory `/usr/src/linux-3.15.1-35.g3289da4-obj/x86_64/desktop' CFG80211 API is prefered for this kernel version Using CFG80211 API make[4]: *** No rule to make target `/home/bferrell/asus-wireless/bcmwl-6.30.223.141+bdcom/src/shared/linux_osl.o', needed by `/home/bferrell/asus-wireless/bcmwl-6.30.223.141+bdcom/wl.o'. Stop. make[3]: *** [_module_/home/bferrell/asus-wireless/bcmwl-6.30.223.141+bdcom] Error 2 make[2]: *** [sub-make] Error 2 make[1]: *** [all] Error 2 make[1]: Leaving directory `/usr/src/linux-3.15.1-35.g3289da4-obj/x86_64/desktop' make: *** [all] Error 2 :~/asus-wireless/bcmwl-6.30.223.141+bdcom> maybe you miss one of the previous patches.

Am 27.06.2014 02:47, schrieb Bruce Ferrell: there were some other patches to support kernel versions prior to 3.15.

to speed things up, here is my currently used, patched and working source package of this driver:

https://drive.google.com/file/d/0Bwpj5Wm8iVh-MUlkbHhLU1RBOWc/edit?usp=sharin...

Thank you, We're closer now. On attempting to load the pre-compiled module in your tarball, I the following error: insmod: ERROR: could not insert module ./wl.ko: Unknown symbol in module dmesg shows this: [ 1004.888107] wl: Unknown symbol cfg80211_scan_done (err 0) [ 1004.888140] wl: Unknown symbol cfg80211_disconnected (err 0) [ 1004.888154] wl: Unknown symbol cfg80211_inform_bss_width_frame (err 0) [ 1004.888169] wl: Unknown symbol wiphy_register (err 0) [ 1004.888177] wl: Unknown symbol wiphy_new (err 0) [ 1004.888185] wl: Unknown symbol cfg80211_put_bss (err 0) [ 1004.888192] wl: Unknown symbol cfg80211_roamed (err 0) [ 1004.888201] wl: Unknown symbol cfg80211_inform_bss_width (err 0) [ 1004.888210] wl: Unknown symbol lib80211_get_crypto_ops (err 0) [ 1004.888218] wl: Unknown symbol cfg80211_ibss_joined (err 0) [ 1004.888228] wl: Unknown symbol cfg80211_michael_mic_failure (err 0) [ 1004.888235] wl: Unknown symbol cfg80211_connect_result (err 0) [ 1004.888249] wl: Unknown symbol wiphy_unregister (err 0) [ 1004.888258] wl: Unknown symbol cfg80211_get_bss (err 0) [ 1004.888268] wl: Unknown symbol __ieee80211_get_channel (err 0) [ 1004.888287] wl: Unknown symbol ieee80211_channel_to_frequency (err 0) [ 1004.888310] wl: Unknown symbol ieee80211_frequency_to_channel (err 0) [ 1004.888322] wl: Unknown symbol wiphy_free (err 0) rebuilding with make clean make API=CFG80211 KBUILD_NOPEDANTIC=1 make -C /lib/modules/`uname -r`/build M=`pwd` make[1]: Entering directory `/usr/src/linux-3.15.1-35.g3289da4-obj/x86_64/desktop' CFG80211 API specified in command line Using CFG80211 API LD /home/bferrell/Downloads/bcm4352/bcm_6_30_223_141/built-in.o CC [M] /home/bferrell/Downloads/bcm4352/bcm_6_30_223_141/src/shared/linux_osl.o CC [M] /home/bferrell/Downloads/bcm4352/bcm_6_30_223_141/src/wl/sys/wl_linux.o CC [M] /home/bferrell/Downloads/bcm4352/bcm_6_30_223_141/src/wl/sys/wl_iw.o CC [M] /home/bferrell/Downloads/bcm4352/bcm_6_30_223_141/src/wl/sys/wl_cfg80211_hybrid.o LD [M] /home/bferrell/Downloads/bcm4352/bcm_6_30_223_141/wl.o WARNING: modpost: missing MODULE_LICENSE() in /home/bferrell/Downloads/bcm4352/bcm_6_30_223_141/wl.o see include/linux/module.h for more information WARNING: /home/bferrell/Downloads/bcm4352/bcm_6_30_223_141/wl.o(.data+0x77fc0): Section mismatch in reference from the variable wl_pci_driver to the function .init.text:wl_pci_probe() The variable wl_pci_driver references the function __init wl_pci_probe() If the reference is valid then annotate the variable with __init* or __refdata (see linux/init.h) or name the variable: *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console Building modules, stage 2. CFG80211 API specified in command line Using CFG80211 API MODPOST 1 modules WARNING: modpost: missing MODULE_LICENSE() in /home/bferrell/Downloads/bcm4352/bcm_6_30_223_141/wl.o see include/linux/module.h for more information WARNING: /home/bferrell/Downloads/bcm4352/bcm_6_30_223_141/wl.o(.data+0x77fc0): Section mismatch in reference from the variable wl_pci_driver to the function .init.text:wl_pci_probe() The variable wl_pci_driver references the function __init wl_pci_probe() If the reference is valid then annotate the variable with __init* or __refdata (see linux/init.h) or name the variable: *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console CC /home/bferrell/Downloads/bcm4352/bcm_6_30_223_141/wl.mod.o LD [M] /home/bferrell/Downloads/bcm4352/bcm_6_30_223_141/wl.ko make[1]: Leaving directory `/usr/src/linux-3.15.1-35.g3289da4-obj/x86_64/desktop' the new module has the same error Thanks in advance Bruce -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2014-06-30 11:45, Rainer Klier wrote:

i don't understand. how can it be, that the same code compiles and loads on my system, but not on your's?

after a kernel update i always go to /usr/src/linux-obj/x86_64/desktop and there i call "make prepare" and then "make modules_prepare".

Before that, I go to "/usr/src/linux/" and run "make cloneconfig". -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

Am 30.06.2014 12:03, schrieb Bruce Ferrell:

...

after a kernel update i always go to /usr/src/linux-obj/x86_64/desktop and there i call "make prepare" and then "make modules_prepare".

after this i go to the bcm_6_30_223_141 directory and call "make".

then i copy the wl.ko to the modules directory.

right now, this would be /lib/modules/3.15.2-1.gfb7c781-desktop/kernel/drivers/net/wireless/

and i have installed the following kernel-packages: kernel-devel-3.15.2-1.1.gfb7c781.noarch kernel-source-3.15.2-1.1.gfb7c781.noarch kernel-desktop-devel-3.15.2-1.1.gfb7c781.x86_64 kernel-firmware-20140624git-90.1.noarch kernel-desktop-3.15.2-1.1.gfb7c781.x86_64

Rainer,

Thank you so much fro your assistance. That procedure worked for me and I now have a working BCM4352 802.11ac driver and more importantly the correct build method.

i am glad, i could help. despite the mailinglist-mess i created..... and abpout the Asus G750JW: does the keyboard lightning control work for you? for me it works only, if i restart KDE. -- Rainer Klier Research & Development xyzmo Software GmbH, SIGNificant E-Signature Solutions A-4052 Ansfelden, Haiderstraße 23 Tel.: +43 7229 88060-0, E-Mail: rainer.klier@xyzmo.com -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Am 30.06.2014 12:34, schrieb Bruce Ferrell:

On 06/30/2014 03:14 AM, Rainer Klier wrote:

...

Am 30.06.2014 12:03, schrieb Bruce Ferrell:

does the keyboard lightning control work for you? for me it works only, if i restart KDE.

In regards keyboard lighting, my keyboard does light up, but the function keys that are supposed to alter the light level don't seem to do anything. All the other function keys seem to work

the keyboard light control from KDE works for me, when i restrt KDE. -- Rainer Klier Research & Development xyzmo Software GmbH, SIGNificant E-Signature Solutions A-4052 Ansfelden, Haiderstraße 23 Tel.: +43 7229 88060-0, E-Mail: rainer.klier@xyzmo.com -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Mon, Jun 23, 2014 at 3:27 PM, Rodney Baker wrote:

On Sat, 21 Jun 2014 22:18:57 C wrote:

...

What is the "right" way to clean up /tmp? [...]

Mount /tmp as a RAM disk (use type tmpfs). That way it starts clean every time the machine boots up.

Works for me...

That's a solution if you reboot regularly. I considered remounting to tmpfs, but can go months without a restart. :-) I'm more inclined to go the route suggested by Cristian R. and set up systemd to look after it. I've been reading everything here in the conversation.. and still need to do a bit more RTFMing. I still want to dig into things a bit and find out what's making my install grow - not only in /tmp, but in /usr/lib and /usr/lib64 as well (as in what the heck have I installed that is taking up so much of my usually ample 20GB / partition). /tmp was one part of the equation. C. -- openSUSE 13.1 x86_64, KDE 4.13 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2014-06-23 16:29, Dylan wrote:

On 23/06/14 14:27, Rodney Baker wrote:

...

On Sat, 21 Jun 2014 22:18:57 C wrote:

...

What is the "right" way to clean up /tmp? [...]

Mount /tmp as a RAM disk (use type tmpfs). That way it starts clean every time the machine boots up.

My current uptime is 29 days, so it would not work.

...

Works for me...

But not for everyone... I, for example, use 3d animation software which generates literally thousands of temporary files per frame while running pre-rendering physics simulations and the like. This can amount to tens of megabytes for a moderately complex scene of 250 frames (25 seconds.) The software is very good at garbage collection, so they don't hang around once the simulation is completed and "baked", but they have to go to disk not memory while they are needed... It can also take several /days/ to "bake" and render a scene so being able to set a, say, 10-day age limit on /tmp is quite important here.

Right. There are many applications that can generate huge amounts of temporary files, and only some can be redirected to another directory. For instance, YaST backup (try telling it to do full backup of a large home). It could be an option if you could set separately a size, and how much of it actually goes on RAM. Then I could set it happily for maximun size of 10 GiB, and maximum RAM usage of just 100 M. The rest would have to overflow to swap, or to some other disk space. Some download utilities download first to "/tmp". Even Firefox does so sometimes. If you are downloading for some hours, and the machine crashes or power fails, I would not be happy to find those files gone. Some applications can recover from interruptions, but not if tmp is volatile... -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)