[opensuse] The "right" way to clear up /tmp?
What is the "right" way to clean up /tmp? I know about the setting in /etc/sysconfig eg, what is documented here: http://lizards.opensuse.org/2009/07/19/howto-regular-cleanup-the-tempfolders... But... that isn't really working, and I rarely reboot - maybe once per month at most. Is there a better way to keep this under control? Should I even be bothered with it? Why be concerned about what's in /tmp? Well, lately my computer is chewing through the 20GB / partition at a rather fast rate. I started looking around and discovered that /tmp is over 3.5GB and growing. The other rather overpopulated directories in / are /usr/lib and /usr/lib64... together those two account for 4.2GB of my install... I've started poking at what's installed, but... it's not really any different than usual. Basically, I'm running out of room on my 20GB / partition... something that has never happened before. Finding the culprit is proving to be... a challenge. 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
C wrote:
What is the "right" way to clean up /tmp?
I know about the setting in /etc/sysconfig eg, what is documented here:
http://lizards.opensuse.org/2009/07/19/howto-regular-cleanup-the-tempfolders...
But... that isn't really working, and I rarely reboot - maybe once per month at most.
Ditto.
Is there a better way to keep this under control? Should I even be bothered with it?
Yes and maybe.
Why be concerned about what's in /tmp? Well, lately my computer is chewing through the 20GB / partition at a rather fast rate. I started looking around and discovered that /tmp is over 3.5GB and growing.
How about a daily cron job find /tmp -type f -ctime -30 -print0 | xargs -r -0 rm
Basically, I'm running out of room on my 20GB / partition... something that has never happened before. Finding the culprit is proving to be... a challenge.
3.5Gb in /tmp sounds like a culprit. -- Per Jessen, Zürich (18.3°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2014-06-21 22:18, C wrote:
The other rather overpopulated directories in / are /usr/lib and /usr/lib64... together those two account for 4.2GB of my install... I've started poking at what's installed, but... it's not really any different than usual.
If you need to move things to another partition, /usr/share/ is an easy candidate. Mine has 8 GB. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
El 21/06/14 16:18, C escribió:
What is the "right" way to clean up /tmp?
I know about the setting in /etc/sysconfig eg, what is documented here: http://lizards.opensuse.org/2009/07/19/howto-regular-cleanup-the-tempfolders...
This is a pre-systemd era article.
But... that isn't really working, and I rarely reboot - maybe once per month at most.
Is there a better way to keep this under control? Should I even be bothered with it?
d /tmp 1777 root root 10d d /var/tmp 1777 root root 30d adjust the number of days to your needs, save that in /etc/tmpfiles.d/localtmp.conf , it will be applied in the next reboot. -- 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
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 HTH Jan -- If you understand what you're doing, you're not learning anything. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Sat, Jun 21, 2014 at 11:35 PM, Jan Ritzerfeld <suse@mailinglists.jan.ritzerfeld.org> 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
C wrote:
On Sat, Jun 21, 2014 at 11:35 PM, Jan Ritzerfeld <suse@mailinglists.jan.ritzerfeld.org> 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 :-)
Dude, /usr/lib is full of executable code (library files, to be exact). If it's there, it's there for a reason. Removing stuff because you don't know what it's there for will just break things. LEAVE IT ALONE. The ONLY proper way to remove things from /usr/lib is through the package manager (zypp or yast2->software management) -- 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 <suse@mailinglists.jan.ritzerfeld.org> 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
On 2014-06-22 23:49, John Andersen wrote:
What are they, and why are they excluded from cleaning?
Let me guess. Those are needed by systemd, and probably should only be cleared on boot, but not on a running system, in case they are needed. I think that the rules we have seen here delete old tmp files on a running system, thus those are excluded. I think the rule should be more complex, and not exclude them if older than the current uptime. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
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 <suse@mailinglists.jan.ritzerfeld.org> 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
John Andersen wrote:
On 06/22/2014 03:45 AM, C wrote:
On Sat, Jun 21, 2014 at 11:35 PM, Jan Ritzerfeld <suse@mailinglists.jan.ritzerfeld.org> 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?
The correct way to do this is with a cron job.... Because when systemd gets replaced, you won't have to reinvent the wheel AGAIN. -- 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 <suse@mailinglists.jan.ritzerfeld.org> 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 Mon, Jun 23, 2014 at 9:02 AM, Basil Chupin <blchupin@iinet.net.au> 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. -- 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 23/06/14 17:15, C wrote:
On Mon, Jun 23, 2014 at 9:02 AM, Basil Chupin <blchupin@iinet.net.au> 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
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.
I had to use nano to manually create this *conf file with those lines.
I suspect anything *.conf found in /etc/tmpfiles.d/ will be taken into account. Just like a cron file in /etc/cron.d etc -- Per Jessen, Zürich (24.9°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- 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 04:55 AM, jdd wrote:
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
DO NOT EDIT THOSE FILES ! ! ! ! ! ! RTFM TMPFILES.D(5) <quote> Files in /etc/tmpfiles.d override files with the same name in /usr/lib/tmpfiles.d and /run/tmpfiles.d. </quote> You specify the local overrides for the defaults by setting up files in /etc/tmpfiles.d -- /"\ \ / 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 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2014-06-23 09:32, Basil Chupin wrote:
On 23/06/14 17:15, C wrote:
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?
Yes. There was a setting, for decades, in sysconfig, to adjust the cronjob that deleted old files, so it was clearly visible, and about everybody knew where to find it. But the script was removed, systemd had to take care of it (I'm unsure why), the defaults did a poor job, there were also some bugs, and few people know where to adjust it now. So the result was that /tmp started to grow out of control. Maybe an adequate comment added to the default cron file in sysconfig would help (it should have been added two releases ago, at least)
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.
Yes, I just added them as well. Only that I increased the number of days, because my systems have quite longer uptimes. - -- 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/ iEYEARECAAYFAlOoI5oACgkQtTMYHG2NR9Ww7gCghlIpwTdViiue7xPjYIBaMXTg 9RsAn0SvZba5BgacuwYV+KmnGRckxicx =DKGj -----END PGP SIGNATURE----- -- 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 <blchupin@iinet.net.au> 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
El 23/06/14 16:15, John Andersen escribió:
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.
No, systemd's mission is not to make boot faster, it is to provide the basic core infrastructure to build distributions. Why in gods name does it have to mess with Cleaning of
directories and do such a poor job of it?
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. Why it is not done by cron ? well.. this cron job was already being retired and replaced by a package called "tmpwatch" when systemd came along with the tmpfiles functionality, which significantly simplifies packager's work, has more fine granted control on what can be done, does not require scripting and therefore all the snippets can potentially be checked for logical/syntatic errors during package build It also provide an uniform way to do things across different distributions, this means such snippets can be included in upstream projects, lifting the need of having to take care of them ourselves. Also, such functionality requires people working on it and willing to maintain it. -- 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: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
El 23/06/14 16:15, John Andersen escribió: [...]
Why in gods name does it have to mess with Cleaning of
directories and do such a poor job of it? 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. I think that they don't want to have too much change at once and so
Am 24.06.2014 00:20, schrieb Cristian Rodríguez: prevent at least one of those annoying ranting threads on this list. I would like to be more close to the original spirit of systemd. At least part of the problems with systemd in openSUSE are the result of improper compromise.
[...] Herbert -- -- 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 <suse@mailinglists.jan.ritzerfeld.org> 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 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 <suse@mailinglists.jan.ritzerfeld.org> 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)" 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 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 <suse@mailinglists.jan.ritzerfeld.org> 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 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". -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
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
В Mon, 23 Jun 2014 15:05:15 +0200 "Carlos E. R." <robin.listas@telefonica.net> пишет:
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.
On 23/06/14 18:19, Andrey Borzenkov wrote:
В Mon, 23 Jun 2014 15:05:15 +0200 "Carlos E. R." <robin.listas@telefonica.net> пишет:
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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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." <robin.listas@telefonica.net> пишет:
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. - -- 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/ iEYEARECAAYFAlOofKoACgkQtTMYHG2NR9WH4wCcDxvcNgytGyd26UyfQV+Fr/NZ 2s0AoI6e1g/iIKc292Jd/HoU8lPilXnm =WRrl -----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: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." <robin.listas@telefonica.net> пишет:
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
В Mon, 23 Jun 2014 15:28:33 -0400 Anton Aylward <opensuse@antonaylward.com> пишет:
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.
Given path can appear only once. You cannot specify multiple actions for a path. It was a bit unexpected to me 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 В Mon, 23 Jun 2014 21:14:50 +0200 "Carlos E. R." <carlos.e.r@opensuse.org> пишет:
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-----
On 06/23/2014 03:42 PM, Andrey Borzenkov wrote:
В Mon, 23 Jun 2014 21:14:50 +0200 "Carlos E. R." <carlos.e.r@opensuse.org> пишет:
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.
That makes no sense. If it is in fact the case then the design is broken. Its perfectly reasonable to want t ensure that the tmp directories are created, perhaps at boot time on a tmpfs, and at a later time to apply a 10 or 30 day clean-out of those same directories. All of which is quite reasonable. Yes I could copy tmp.conf, edit out those two lines and edit in the other two, but that manes my system won't work it at some time in the future if I run with a tmpfs /tmp or /var/tmp. Chistian: could you bump this 'upstairs' for comment please. -- /"\ \ / 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
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
On 06/23/2014 06:04 PM, 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.
Thank you, but what about the use-case I described? -- /"\ \ / 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
-----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
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...
And, what you said that we could create "/etc/tmpfiles.d/localtmp.conf" simply does not work.
Yes, I messed that up.. -- 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 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
On 06/23/2014 08:54 PM, Carlos E. R. wrote:
And, what you said that we could create "/etc/tmpfiles.d/localtmp.conf" simply does not work.
+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
-----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 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? - -- 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/ iEYEARECAAYFAlOozmoACgkQtTMYHG2NR9VvmwCePKHywDukZnc1mEOhcsOC6pJ/ GJsAnRSgtzf9sFuskCzpI9bQUpSfQC+M =fX+X -----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." <carlos.e.r@opensuse.org> пишет:
-----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-----
-----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! - -- 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/ iEYEARECAAYFAlOo6B8ACgkQtTMYHG2NR9WN9wCdF+keiRqXxHg9GQBYURCdk2qL 5isAn2Wo4vI9OFdvGTSz6a0FwGMb+/i2 =vl/C -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
24 июня 2014 г., в 6:53, "Carlos E. R." <carlos.e.r@opensuse.org> написал(а):
-----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 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 ;-) - -- 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/ iEYEARECAAYFAlOppGEACgkQtTMYHG2NR9UhgwCfVnHr3pzRMYqpQWxcRf6AUbSA AqMAoJhsfu1CXVa86vG3fY/fOBCljrHS =la3E -----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 18:16:33 +0200 "Carlos E. R." <carlos.e.r@opensuse.org> пишет:
-----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-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2014-06-24 18:52, Andrey Borzenkov wrote:
В Tue, 24 Jun 2014 18:16:33 +0200 "Carlos E. R." <> пишет:
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?
It should be a default. It has been for decades ;-)
May be someone needs to think about adapting it to modern realities ... as long as we have to live with modern realities.
That's true. It goes into syslog, too, and it may take long to run - during boot. But it does not hold boot, as far as I remember. I just modified the script to send an email to myself.
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).
Yes, I agree. The older implementation, in cron, had more adjustments, like for instance, leave alone root's files. A refinement would be to only periodically remove files older than the current uptime (in case this is longer than the configured period). This way /tmp/systemd-private-* can also be purged during use, if wanted. - -- 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/ iEYEARECAAYFAlOpvasACgkQtTMYHG2NR9UaXwCdF16YjSE9RVBcqt87391tMIKO CVsAn1movS+HXpjDFKyaD1Jz6uq0bm/y =2gQ6 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
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
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. tmp files are just that, temporary! that mean "can be removed at any time". 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. defaut / size are often under 10Gb. jdd -- http://www.dodin.org -- 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
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?
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
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? openSUSE Linux is a multiuser multitask system, allowing one user or one application to kill the system is IMHO a very bad practice.
defaut / size are often under 10Gb.
Are they?
yes -- http://www.dodin.org -- 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
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?
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. jdd -- http://www.dodin.org -- 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
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!
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 jdd -- http://www.dodin.org -- 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)
Le 24/06/2014 15:34, Carlos E. R. a écrit :
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.
50 Go with Blu-Ray, and you can keep several You can change the default, yes, but that is the
default.
yes but can be changed very easily - and k3b *do not* accept tmp files bigger than free space - the free space is shown in the config and write window - as it have to be.
I speak mostly of setting a dvd in the reader and clic install, all default
But most serious users customize the defaults.
defaults, by definition, should accommodate the majority. There where some long discussion(s) here about the need of having a separate /home, and this is where the /tmp problem come, as in most cases it's home that needs to be hudge and it's the default for openSUSE now, but sometime it's not. 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 :-( jdd -- http://www.dodin.org -- 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 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
On 06/24/2014 11:54 AM, Carlos E. R. wrote:
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.
We've got many people saying what they do, what they need, and a few with an absolutist attitude saying what /tmp should be. This isn't like buying a car where GM decides (limited by government regulations) what you should have and offers a few meaningless 'options' like colour and and trim and transmission (if you are lucky). And its not s if you can change the engine size or the gearbox ratios. But the whole point of open source is that you CAN. Yes, its an absolute that few take but we've seen recently discussions about file system choices, boot loader choices and Linda makes it very clear that even inird is a choice. Its one reason I get fed up with the people who think that KDE4 or systemd is a fascist conspiracy. That you can't do certain mix-and-match combinations with some distributions isn't the point. I can't fit a full size refrigerator in the trunk of my Buick (though I could in my Volvo wagon!). But the real point is the one Carlos is making. You have an incredible amount for flexibility and control. Rather than bitching about the immediate past (and all to often in ignorance of the more distance past since change has been persistent), learn the new. Its the ability to keep learning that keeps you young :-) I roll my eyes whenever I hear to myth about systemd being for a faster boot. Its about system management, and the booting is just part of that. Systemd implements with its 'units' what amounts to a DECLARATIVE rather than a _procedural_ language. Declarative programming is when you write your code in such a way that it describes what you want to do, and not how you want to do it. If you, for example, view a compiler as an 'expert system' on code production, then this is a good approach as the computer - systemd - know more about what else is going on. The important this is that a declarative approach is context-independent. Since such systems only declare what the ultimate goal is, but not the intermediary steps to reach that goal, the same program can be used in different contexts. This is hard to do with imperative programs, because they often depend on the context (e.g. Hidden state). An example here might be the contrast with re-running one of the sysvinit scripts _after_ boot or a state change. The result could be inappropriate since it was not run as part of a sequence of scripts. I keep saying 'context is everything' and that phrase has a lot of implications. Many human actions, programming included, are concerned with just a single matter and don't consider the side effects of the 'emergent properties' or the 'implied space'. See also http://www.forbes.com/sites/danwoods/2013/04/17/why-adopting-the-declarative... I found the reference to Puppet interesting. <quote> Most complex computing systems are controlled by various levels of configuration files. These files are the equivalent of the controls on an airplane dashboard. But while a typical cockpit may have a hundred or so switches, a single Linux server has hundreds of config files with thousands of controls. When you add networking equipment, firewalls, storage area networks, intrusion detection systems, and many other types of devices, the number of files to maintain skyrockets. </quote> Of course coming from a background of using YACC/LEX as a 'swiss army knife' for many application specific situation I'm biased toward the declarative approach. -- /"\ \ / 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
-----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
Am 24.06.2014 15:24, schrieb Carlos E. R.:
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. On many UNIX system I have worked with /tmp has been on a small special fast, but small disk. It was only for small short lived files. An application needing much temporary disk space has been expected to use another disk. Writing large temporary files makes those files non-short-lived by definition.
Sure, what's a large file or what's short lived has change over time. But by tradition /tmp provides rather limited space, not terabytes. If you like to have such large /tmp, you can configure it this way. But when you having the effort to configure it this way, it wouldn't be much more work to change from tmpfs to a real disk. So tmps is a good default for most users on actual hardware.
[...] Herbert -- "If privacy is outlawed, only outlaws will have privacy ..." /Phil Zimmermann/
-- 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
On 06/25/2014 09:35 AM, Carlos E. R. wrote:
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.
+1
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.
As they say "YMMV" As I say "Context is everything"
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. -- /"\ \ / 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
-----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 06/25/2014 11:19 AM, Carlos E. R. wrote:
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.
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? 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. 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.... -- 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)
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 ? 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.
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.
POSIX_FADV_DONTNEED exists for that reason, however the kernel may not honour it.. knows better..;) -- 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 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)
El 26/06/14 22:23, Carlos E. R. escribió:
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.
Yeah, I have seen those too, but as I understand it, it is a completely different problem... -- 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 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
On 2014-06-27 05:21, Anton Aylward wrote:
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.
Generic concept. In this case, I was talking of both types. :-)
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.
I was not aware that you could tune it per process. But for this case, I would need tuning per directory. And if this is possible, it would make sense that the kernel already tunes some directories differently. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
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 <suse@mailinglists.jan.ritzerfeld.org> 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 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). -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
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 2014-06-23 17:04, Ken Schneider - openSUSE wrote:
On 06/23/2014 10:56 AM, Carlos E. R. pecked at the keyboard and wrote:
And all are dated Jun 15 (my current uptime is 29 days).
I have no such after adjusting for my login name.
I had a problem with a specific web java application that did not run. I only tried one day. Then I saw that it specified "remove icedtead" in the specs, so I did (and tabooed it). Those directories belong to that trying session, I believe. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On Sat, 2014-06-21 at 22:18 +0200, C wrote:
What is the "right" way to clean up /tmp?
I know about the setting in /etc/sysconfig eg, what is documented here: http://lizards.opensuse.org/2009/07/19/howto-regular-cleanup-the-tempfolders...
But... that isn't really working, and I rarely reboot - maybe once per month at most.
Is there a better way to keep this under control? Should I even be bothered with it?
(yast2) /etc/sysconfig-editor -> system -> cron -> max_days_in_tmp I just keep it to "1" -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2014-06-23 01:24, Hans Witvliet wrote:
(yast2) /etc/sysconfig-editor -> system -> cron -> max_days_in_tmp
I just keep it to "1"
Sigh... again. :-( Please read the release notes. That does not work in 13.1. The method has been removed. Telcontar:~ # cat /other/bombadillo/etc/SuSE-brand openSUSE VERSION = 12.1 Telcontar:~ # grep -i max_days_in_tmp /other/bombadillo/etc/cron.daily/* /other/bombadillo/etc/cron.daily/suse.de-clean-tmp:cleanup_tmp ${MAX_DAYS_IN_TMP:-0} ${TMP_DIRS_TO_CLEAR:-/tmp} Telcontar:~ # Telcontar:~ # grep -i max_days_in_tmp /etc/cron.daily/* Telcontar:~ # cat /etc/SuSE-brand cat: /etc/SuSE-brand: No such file or directory Telcontar:~ # cat /etc/SuSE-release openSUSE 13.1 (x86_64) VERSION = 13.1 See? The script that did that job and read that variable does not exist in 13.1. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
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 -- 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 N�����r��y隊Z)z{.�ﮞ˛���m�)z{.��+�: �{Zr�az�'z��j)h���Ǿ� ޮ�^�ˬz��
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 -- 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 N�����r��y隊Z)z{.�ﮞ˛���m�)z{.��+�: �{Zr�az�'z��j)h���Ǿ� ޮ�^�ˬz��
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
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... -- 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
* Rainer Klier <Rainer.Klier@xyzmo.com> [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 06/27/2014 03:52 AM, Patrick Shanahan wrote:
* Rainer Klier <Rainer.Klier@xyzmo.com> [06-27-14 02:58]:
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...
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. -- 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 <bferrell@baywinds.org> wrote:
On 06/27/2014 03:52 AM, Patrick Shanahan wrote:
* Rainer Klier <Rainer.Klier@xyzmo.com> [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
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 -- 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
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 06/27/2014 04:36 AM, C wrote:
On Fri, Jun 27, 2014 at 1:01 PM, Bruce Ferrell <bferrell@baywinds.org> wrote:
* Rainer Klier <Rainer.Klier@xyzmo.com> [06-27-14 02:58]:
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...
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
On 06/27/2014 03:52 AM, Patrick Shanahan wrote: 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 -- 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 <bferrell@baywinds.org> wrote:
On 06/27/2014 04:36 AM, C wrote:
On Fri, Jun 27, 2014 at 1:01 PM, Bruce Ferrell <bferrell@baywinds.org> wrote:
On 06/27/2014 03:52 AM, Patrick Shanahan wrote:
* Rainer Klier <Rainer.Klier@xyzmo.com> [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
Bruce Ferrell wrote:
On 06/27/2014 03:52 AM, Patrick Shanahan wrote:
* Rainer Klier <Rainer.Klier@xyzmo.com> [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.
You're right, your first posting was new, it was Rainer Klier who replied to it, but somehow referring to the "The "right" way to clear up /tmp?" thread instead. -- Per Jessen, Zürich (24.0°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- 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
Am 27.06.2014 16:02, schrieb Bruce Ferrell:
On 06/26/2014 11:56 PM, Rainer Klier wrote:
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:
rebuilding with make clean make API=CFG80211 KBUILD_NOPEDANTIC=1 make -C /lib/modules/`uname -r`/build M=`pwd`
i always use a simple "make" to create the module. just now, i upgraded to kernel 3.15.2. i entered the bcm_6_30_223_141 directory and called "make".
the new module has the same error
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". 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 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 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)
On 06/30/2014 02:45 AM, Rainer Klier wrote:
Am 27.06.2014 16:02, schrieb Bruce Ferrell:
On 06/26/2014 11:56 PM, Rainer Klier wrote:
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:
rebuilding with make clean make API=CFG80211 KBUILD_NOPEDANTIC=1 make -C /lib/modules/`uname -r`/build M=`pwd` i always use a simple "make" to create the module. just now, i upgraded to kernel 3.15.2. i entered the bcm_6_30_223_141 directory and called "make".
the new module has the same error 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".
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. Bruce Ferrell -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
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
On 06/30/2014 03:14 AM, Rainer Klier wrote:
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.
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 -- 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 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... Rodney. -- ============================================================== Rodney Baker VK5ZTV rodney.baker@iinet.net.au ============================================================== -- 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 <rodney.baker@iinet.net.au> 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 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.
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. Dx -- 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)
participants (23)
-
Andrey Borzenkov -
Anton Aylward -
arvidjaar＠gmail.com
-
Basil Chupin -
Bruce Ferrell -
C -
Carlos E. R. -
Carlos E. R. -
Cristian Rodríguez -
Dirk Gently -
Dylan -
Hans Witvliet -
Herbert Graeber -
Jan Ritzerfeld -
jdd -
John Andersen -
Ken Schneider - openSUSE -
lynn -
Patrick Shanahan -
Per Jessen -
Rainer Klier -
Rodney Baker -
Vojtěch Zeisek