On Tuesday, 18 February 2020 09:35:08 GMT jdd@dodin.org wrote:

Le 18/02/2020 à 10:08, Ianseeks a écrit :

...

Hi

For ordinary lazy users like me who are not interested in or capable of system admin as a daily chore, should there not be the possibility of a section in Yast2 or Systemsettings where some standard user friendly housekeeping functions (e.g. flushing tmp folders, vacuuming journals etc) could be activated/configured to run at startup/shutdown

they are...

I'm thinking along the lines of a simple "Clear temporary files on exit Y/N" and "Only store X days of journals" not setting up cron jobs etc

...

I've just hit the "system disk full" message when running "zypper", it would have been better if a "disk getting full" message was displayed at login so i could have dealt with it.

Any thoughts?

what file system?

mine is all ext4

btrfs was known for such problem, but new installs get better. If you only update, the ancient system may be still there. with btrfs 50 gb is a minimum, 100 Gb is nice, for root only.

emse (no btrfs, but ext4 or other), the reason may be a lot of download from zypper, may be because the update is not frequent enough.

with small / (root) partitions, it's very difficult to know how much transient space an update needs, may be zypper, in an xterm, gives a clue before acting, I don't remember. It could just be give a warning when there is only e.g. 10% free space left

you *can* setup zypper to download and install each package separately, but you system is prone to become unstable if something goes wrong in the mean time. That was just my example of where i found out when i'd run out of space. I'm thinking for for the people who won't even know what a Konsole session is.

jdd

-- opensuse:tumbleweed:20200214 Qt: 5.14.1 KDE Frameworks: 5.67.0 - KDE Plasma: 5.18.0 - kwin 5.18.0 kmail2 5.13.2 (19.12.2) - akonadiserver 5.13.2 (19.12.2) - Kernel: 5.5.2-1-default - xf86-video-nouveau: 1.0.15 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Tuesday, 18 February 2020 11:31:33 GMT Carlos E. R. wrote:

On 18/02/2020 11.38, Ianseeks wrote:

...

On Tuesday, 18 February 2020 09:35:08 GMT jdd@dodin.org wrote:

...

Le 18/02/2020 à 10:08, Ianseeks a écrit :

...

Hi

For ordinary lazy users like me who are not interested in or capable of system admin as a daily chore, should there not be the possibility of a section in Yast2 or Systemsettings where some standard user friendly housekeeping functions (e.g. flushing tmp folders, vacuuming journals etc) could be activated/configured to run at startup/shutdown

they are...

I'm thinking along the lines of a simple "Clear temporary files on exit Y/N" and "Only store X days of journals" not setting up cron jobs etc

I don't think YaST handles it, but it should.

...

...

...

I've just hit the "system disk full" message when running "zypper", it would have been better if a "disk getting full" message was displayed at login so i could have dealt with it.

Any thoughts?

what file system?

mine is all ext4

Ah, then the ordinary fill up disk ssituation.

...

...

btrfs was known for such problem, but new installs get better. If you only update, the ancient system may be still there. with btrfs 50 gb is a minimum, 100 Gb is nice, for root only.

emse (no btrfs, but ext4 or other), the reason may be a lot of download from zypper, may be because the update is not frequent enough.

with small / (root) partitions, it's very difficult to know how much transient space an update needs, may be zypper, in an xterm, gives a clue before acting, I don't remember. It could just be give a warning when there is only e.g. 10% free space left

YaST package manager does tell you. A little window, down-left, often hidden.

There are some other desktop tools that can tell you as well.

I was thinking about the warning appearing somewhere visible like on the login screen as i found ssdm doesn't load to the login screen once the "/" is full, i just got a black screen with a cursor in the top left corner -- opensuse:tumbleweed:20200214 Qt: 5.14.1 KDE Frameworks: 5.67.0 - KDE Plasma: 5.18.0 - kwin 5.18.0 kmail2 5.13.2 (19.12.2) - akonadiserver 5.13.2 (19.12.2) - Kernel: 5.5.2-1-default - xf86-video-nouveau: 1.0.15 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Tuesday, 18 February 2020 12:13:25 GMT Carlos E. R. wrote:

On 18/02/2020 13.04, Ianseeks wrote:

...

On Tuesday, 18 February 2020 11:31:33 GMT Carlos E. R. wrote:

...

On 18/02/2020 11.38, Ianseeks wrote:

...

...

...

...

It could just be give a warning when there is only e.g. 10% free space left

YaST package manager does tell you. A little window, down-left, often hidden.

There are some other desktop tools that can tell you as well.

I was thinking about the warning appearing somewhere visible like on the login screen as i found ssdm doesn't load to the login screen once the "/" is full, i just got a black screen with a cursor in the top left corner

Problem is, the tool depends on the actual desktop used. The ways to present a message is different on each.

Someone would have to create a "health" application and a way to have it start on every desktop type.

Maybe that should be a warning function for each desktop to add to itself for its own protection

-- opensuse:tumbleweed:20200214 Qt: 5.14.1 KDE Frameworks: 5.67.0 - KDE Plasma: 5.18.0 - kwin 5.18.0 kmail2 5.13.2 (19.12.2) - akonadiserver 5.13.2 (19.12.2) - Kernel: 5.5.2-1-default - xf86-video-nouveau: 1.0.15 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 18/02/2020 13.24, Peter Suetterlin wrote:

Carlos E. R. wrote:

...

Someone would have to create a "health" application and a way to have it start on every desktop type.

Mine is called 'gkrellm', and does a lot more than just monitoring FS fill :D

(yes, I'm sort of a control freak when it comes to my computer...)

I use it as well. -- Cheers / Saludos, Carlos E. R. (from openSUSE 15.1 (Legolas))

On 02/18/2020 06:04 AM, Ianseeks wrote:

I was thinking about the warning appearing somewhere visible like on the login screen as i found ssdm doesn't load to the login screen once the "/" is full, i just got a black screen with a cursor in the top left corner

That is a good idea. Traditionally the role has been filled by desktop system monitors like conky or superkaramba that display the nice little CPU/Disk/Network/Battery statistics as either desktop overlays or as small systray applets. Konqueror in KDE has such a monitor and will warn the user on start if disk space is low. As does the KDiskFree app, see: https://susepaste.org/73133611 But a desktop agnostic system check would be much better -- the only stumbling block is how to display it when the system doesn't know what display manager or desktop the user will use? Since most users boot to the graphical.target, it would more or less be up to each of the display managers to implement the warning on the login screen. Otherwise you would have to display the warning in the text console and halt loading the desktop manager until the user acknowledges the warning (which if the disk space is consumed during a user-session, it won't be caught until next time the DM login screen is displayed) It would probably need to be implemented as either a daemon started during boot, or a timer that repeatedly checks at some reasonable interval. Would be cool to have... -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Wednesday 19 February 2020, Ianseeks wrote:

On Tuesday, 18 February 2020 11:31:33 GMT Carlos E. R. wrote: ... I was thinking about the warning appearing somewhere visible like on the login screen as i found ssdm doesn't load to the login screen once the "/" is full, i just got a black screen with a cursor in the top left corner

If you're happy to inform any already logged in sessions, then loginctl and notify-send can be combined to do the job. I put up a script to do this as a gist at github: https://gist.github.com/digitaltrails/26aad3282d8739db1de8bc2e59c812eb I use it for things like: notify-desktop -a Daily-backup -t 0 -i dialog-information.png "Starting daily backup" notify-desktop -a Daily-backup -t 0 -i dialog-error.png "backup device not online or is too small" notify-desktop -a Daily-backup -t 0 -i dialog-information.png "Finished daily backup" That way I get informed of daily timer tasks and background errors. It's especially useful for preventing me from doing any reboots while they are running. The scripts tries to identify the non remote X11 or wayland session (I've not actually tested it on wayland). The script sudos to the user to do a notify-send, but will fallback to wall otherwise. Michael -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Tuesday, 18 February 2020 10:01:09 GMT Per Jessen wrote:

Ianseeks wrote:

...

Hi

For ordinary lazy users like me who are not interested in or capable of system admin as a daily chore, should there not be the possibility of a section in Yast2 or Systemsettings where some standard user friendly housekeeping functions (e.g. flushing tmp folders, vacuuming journals etc) could be activated/configured to run at startup/shutdown rather than have to scour the net for solutions. For many like me, the computer should be doing more work with stuff that could be automated.

Agree completely. I think most if not all also does happen automagically ? I've got a pretty much stock set up and my tmp directory was full of months old stuff and the same went for the journals so it doesn't seem set up for automatic housekeeping out of the box.

...

A status page in YaST sounds like a neat idea, OTOH it might be overkill when the average user does not want ot know? They could be set to safe defaults for the user that won;t visit a housekeeping section.

...

I've just hit the "system disk full" message when running "zypper", it would have been better if a "disk getting full" message was displayed at login so i could have dealt with it.

I'm not sure if this is one of the conditions being monitored, anywhere. That was my thought too, but shouldn't it be there for those that do not know how to do these things. Gets a bit of nuisance if you can't write to a file to say the system is full when the system is full :)

-- opensuse:tumbleweed:20200214 Qt: 5.14.1 KDE Frameworks: 5.67.0 - KDE Plasma: 5.18.0 - kwin 5.18.0 kmail2 5.13.2 (19.12.2) - akonadiserver 5.13.2 (19.12.2) - Kernel: 5.5.2-1-default - xf86-video-nouveau: 1.0.15 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Tue, 18 Feb 2020 12:08:59 +0100 Peter Suetterlin wrote:

Ianseeks wrote:

...

I've got a pretty much stock set up and my tmp directory was full of months old stuff and the same went for the journals so it doesn't seem set up for automatic housekeeping out of the box.

I think tmp is indeed not cleaned (on purpose, IIRC).

https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s18.html "Although data stored in /tmp may be deleted in a site-specific manner, **it is recommended that files and directories located in /tmp be deleted whenever the system is booted.**" My /tmp gets very large as well particularly with stuff from firefox so I don't think openSUSE clears it at boot properly.

The journals are limited, just the limits are very generous. You'd have to adapt them in /etc/systemd/journald.conf. I have [Journal] SystemMaxUse=100M MaxRetentionSec=3month

journal works just fine with default settings for me 184M at the moment. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 18/02/2020 06:37, Carlos E. R. wrote:

On 18/02/2020 12.26, Dave Howorth wrote:

...

My /tmp gets very large as well particularly with stuff from firefox so I don't think openSUSE clears it at boot properly.

Intentionally so, I understand. The old setting, pre-systemd, was to delete aged files (I think there was a configuration setting to do at boot).

Yes, I recall and have been searching for that.

After systemd, it is broken, because the recommended systemd thing is to have /tmp on ram, and we don't by default (intentionally, we users demanded this).

I don't recall. Do programs honour the setting of the environment variable TMP? Yes, you can always set up a tmps but will programs make use of it? -- A: Yes. > 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

On 18/02/2020 10:29, Anton Aylward wrote:

I don't recall. Do programs honour the setting of the environment variable TMP?

Yes, you can always set up a tmps but will programs make use of it?

Well https://pubs.opengroup.org/onlinepubs/000095399/basedefs/xbd_chap08.html says that TMPDIR is reserved See also https://en.wikipedia.org/wiki/TMPDIR You can always use a fallback of: TMPDIR="{${TMPDIR:-$(dirname $(mktemp -d))/}" See MAN MKTEMP(1) -- A: Yes. > 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

On Tue, 18 Feb 2020 12:37:37 +0100 "Carlos E. R." wrote:

On 18/02/2020 12.26, Dave Howorth wrote:

...

On Tue, 18 Feb 2020 12:08:59 +0100 Peter Suetterlin wrote:

...

Ianseeks wrote:

...

I've got a pretty much stock set up and my tmp directory was full of months old stuff and the same went for the journals so it doesn't seem set up for automatic housekeeping out of the box.

I think tmp is indeed not cleaned (on purpose, IIRC).

https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s18.html

"Although data stored in /tmp may be deleted in a site-specific manner, **it is recommended that files and directories located in /tmp be deleted whenever the system is booted.**"

My /tmp gets very large as well particularly with stuff from firefox so I don't think openSUSE clears it at boot properly.

Intentionally so, I understand. The old setting, pre-systemd, was to delete aged files (I think there was a configuration setting to do at boot). After systemd, it is broken, because the recommended systemd thing is to have /tmp on ram, and we don't by default (intentionally, we users demanded this).

I don't understand what systemd has to do with it. FHS says: /tmp is for temporary files that should be cleared at boot. /var/tmp is for temporary files that must NOT be cleared at boot. There's also /run of course for anything small enough to be sensibly placed in memory. When I look in /usr/lib/tmpfiles.d/tmp.conf I see: # Clear tmp directories separately, to make them easier to override # SUSE policy: we don't clean those directories q /tmp 1777 root root - q /var/tmp 1777 root root - So I think the blame is quite clearly laid at SUSE's door. Can anybody tell me where this policy of SUSE's that contradicts FHS is (a) defined and (b) explained? Also how do I set the system to clear /tmp on reboot? It annoys me to have to override default conf just to get back to how the system is supposed to work and how other software is expecting and is designed to work. (I'm thinking of firefox especially) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Anton Aylward wrote:

On 18/02/2020 12:11, Dave Howorth wrote:

...

I don't understand what systemd has to do with it. FHS says:

/tmp is for temporary files that should be cleared at boot. /var/tmp is for temporary files that must NOT be cleared at boot.

it seems to be the other way round on my system.

It looks to me like systemd is using /var/tmp when you specify PrivateTmp=true. Otherwise my /var/tmp contains some TmpDir.xxxxxx and some zypp.xxxxxx. Some about a year old. -- Per Jessen, Zürich (6.0°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 Tue, 18 Feb 2020 19:29:05 +0100 "Carlos E. R." wrote:

On 18/02/2020 18.11, Dave Howorth wrote:

...

On Tue, 18 Feb 2020 12:37:37 +0100 "Carlos E. R." wrote:

...

On 18/02/2020 12.26, Dave Howorth wrote:

...

On Tue, 18 Feb 2020 12:08:59 +0100 Peter Suetterlin wrote:

...

Ianseeks wrote:

...

I've got a pretty much stock set up and my tmp directory was full of months old stuff and the same went for the journals so it doesn't seem set up for automatic housekeeping out of the box.

I think tmp is indeed not cleaned (on purpose, IIRC).

https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s18.html

"Although data stored in /tmp may be deleted in a site-specific manner, **it is recommended that files and directories located in /tmp be deleted whenever the system is booted.**"

My /tmp gets very large as well particularly with stuff from firefox so I don't think openSUSE clears it at boot properly.

Intentionally so, I understand. The old setting, pre-systemd, was to delete aged files (I think there was a configuration setting to do at boot). After systemd, it is broken, because the recommended systemd thing is to have /tmp on ram, and we don't by default (intentionally, we users demanded this).

I don't understand what systemd has to do with it. FHS says:

Forget what the FHS says. This was redesigned with the advent of systemd, and that is a fact.

Reference?

...

When I look in /usr/lib/tmpfiles.d/tmp.conf I see:

# Clear tmp directories separately, to make them easier to override # SUSE policy: we don't clean those directories q /tmp 1777 root root - q /var/tmp 1777 root root -

So I think the blame is quite clearly laid at SUSE's door. Can anybody tell me where this policy of SUSE's that contradicts FHS is (a) defined and (b) explained? Also how do I set the system to clear /tmp on reboot?

We insisted on this behaviour was wanted on the mail lists, the SuSE way.

For Dog's sake, WHY? Why would anybody want to keep a temporary file from before the system was booted? And if they did, why not put it in /var/tmp like they're supposed to? A URL to the appropriate mail thread archive would likely help me understand. Oh and note that the note in the file says 'SUSE' not 'openSUSE', which makes me even more curious. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Tue, 18 Feb 2020 21:58:33 +0100 "Carlos E. R." wrote:

On 18/02/2020 21.28, Dave Howorth wrote:

...

On Tue, 18 Feb 2020 19:29:05 +0100 "Carlos E. R." <> wrote:

...

On 18/02/2020 18.11, Dave Howorth wrote:

...

On Tue, 18 Feb 2020 12:37:37 +0100 "Carlos E. R." <> wrote:

...

On 18/02/2020 12.26, Dave Howorth wrote:

...

On Tue, 18 Feb 2020 12:08:59 +0100 Peter Suetterlin <> wrote: > Ianseeks wrote: > >> I've got a pretty much stock set up and my tmp directory was >> full of months old stuff and the same went for the journals so >> it doesn't seem set up for automatic housekeeping out of the >> box. > > I think tmp is indeed not cleaned (on purpose, IIRC).

https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s18.html

"Although data stored in /tmp may be deleted in a site-specific manner, **it is recommended that files and directories located in /tmp be deleted whenever the system is booted.**"

My /tmp gets very large as well particularly with stuff from firefox so I don't think openSUSE clears it at boot properly.

Intentionally so, I understand. The old setting, pre-systemd, was to delete aged files (I think there was a configuration setting to do at boot). After systemd, it is broken, because the recommended systemd thing is to have /tmp on ram, and we don't by default (intentionally, we users demanded this).

I don't understand what systemd has to do with it. FHS says:

Forget what the FHS says. This was redesigned with the advent of systemd, and that is a fact.

Reference?

My memory. Seek this list archive. :-D

My memory is not as good as it was, but I do remember that we discussed this for weeks.

Notice that I'm not referring (exclusively) to systemd devs. I'm referring mostly to the consequences of systemd advent, how openSUSE responded and how it applied things, how the community reacted, what was finally done.

See the highlighted line below as proof:

...

...

...

When I look in /usr/lib/tmpfiles.d/tmp.conf I see:

# Clear tmp directories separately, to make them easier to override # SUSE policy: we don't clean those directories <================ q /tmp 1777 root root - q /var/tmp 1777 root root -

So I think the blame is quite clearly laid at SUSE's door. Can anybody tell me where this policy of SUSE's that contradicts FHS is (a) defined and (b) explained? Also how do I set the system to clear /tmp on reboot?

We insisted on this behaviour was wanted on the mail lists, the SuSE way.

For Dog's sake, WHY? Why would anybody want to keep a temporary file from before the system was booted? And if they did, why not put it in /var/tmp like they're supposed to?

Many reasons I don't remember :-)

For example, downloads happening there. Scripts that save files there. Not saying good or bad, they just do.

But downloads happening there are exactly the sort of thing that are SUPPOSED to be cleared out. Them not being cleared is the source of my original problem! Name any scripts that do that? And expect them to be preserved. And if so, they should be bug-reported and after 8 years I'd hope they'd all been fixed.

...

A URL to the appropriate mail thread archive would likely help me understand.

I would have a tremendous job seeking the archive for some hundreds of posts.

Indeed, but my task would be even greater.

Yet, some:

Date: Mar 2012 13:53:20 +0200 Cc: opensuse-factory@opensuse.org Subject: Re: [opensuse-factory] to tmp-on-tmpfs or not tmp-on-tmpfs

Thanks, but that's about the wrong subject. I don't want to know about /tmp on tmpfs and I know that does clear /tmp at boot so clearly systems using it apparently have no problems with downloads or rogue scripts :) What I want to know about is clearing /tmp on a regular filesystem and why SUSE doesn't clear it on boot. Since it's stated policy, I'd expect the policy to be documented.

There was a blog: http://jaegerandi.blogspot.de/2012/03/tmp-as-tmpfs-for-opensuse.html Now it asks for password.

Yeah, so not useful and about the wrong subject anyway.

...

...

Oh and note that the note in the file says 'SUSE' not 'openSUSE', which makes me even more curious.

Well, both did the same thing, which I like. :-D

-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Wed, 19 Feb 2020 14:19:11 +0100 "Carlos E. R." wrote:

On 19/02/2020 12.18, Dave Howorth wrote:

...

On Tue, 18 Feb 2020 21:58:33 +0100 "Carlos E. R." <> wrote:

...

On 18/02/2020 21.28, Dave Howorth wrote:

...

On Tue, 18 Feb 2020 19:29:05 +0100 "Carlos E. R." <> wrote:

...

On 18/02/2020 18.11, Dave Howorth wrote:

...

On Tue, 18 Feb 2020 12:37:37 +0100 "Carlos E. R." <> wrote: > On 18/02/2020 12.26, Dave Howorth wrote: >> On Tue, 18 Feb 2020 12:08:59 +0100 Peter Suetterlin <> >> wrote: >>> Ianseeks wrote:

...

...

...

See the highlighted line below as proof:

...

...

...

When I look in /usr/lib/tmpfiles.d/tmp.conf I see:

# Clear tmp directories separately, to make them easier to override # SUSE policy: we don't clean those directories <================ q /tmp 1777 root root - q /var/tmp 1777 root root -

So I think the blame is quite clearly laid at SUSE's door. Can anybody tell me where this policy of SUSE's that contradicts FHS is (a) defined and (b) explained? Also how do I set the system to clear /tmp on reboot?

We insisted on this behaviour was wanted on the mail lists, the SuSE way.

For Dog's sake, WHY? Why would anybody want to keep a temporary file from before the system was booted? And if they did, why not put it in /var/tmp like they're supposed to?

Many reasons I don't remember :-)

For example, downloads happening there. Scripts that save files there. Not saying good or bad, they just do.

But downloads happening there are exactly the sort of thing that are SUPPOSED to be cleared out. Them not being cleared is the source of my original problem!

No till I had time to use them or copy them elsewhere or delete them manually. Meaning, six months. Just my choice, and happened to be trivial with openSUSE prior to systemd advent.

I'm sorry, but firefox gives you the choice. So just choose somewhere that's supposed to be kept instead of somewhere that's supposed to be cleared! And don't try to foist your peculiarity as a sensible reason for not clearing /tmp!

...

Name any scripts that do that? And expect them to be preserved. And if so, they should be bug-reported and after 8 years I'd hope they'd all been fixed.

Nay :-P

Example: "save_y2logs" saves a temporary file. I don't want it deleted fast, just eventually. Not when boot, because reboot may be unintentional.

save_y2logs accepts the name of the file you want to save in as an argument, so just do that. Or put a script around it to do it for you if you prefer, or hack the script or file a bugzilla, but don't ask for a peculiar behaviour of /tmp please.

Example: vmware saves *logs* to /tmp/vmware-root

Not according to https://kb.vmware.com/s/article/1021806 the products seem to save in subdirectories of /var/log as they should.

...

...

...

A URL to the appropriate mail thread archive would likely help me understand.

I would have a tremendous job seeking the archive for some hundreds of posts.

Indeed, but my task would be even greater.

...

Yet, some:

Date: Mar 2012 13:53:20 +0200 Cc: opensuse-factory@opensuse.org Subject: Re: [opensuse-factory] to tmp-on-tmpfs or not tmp-on-tmpfs

Thanks, but that's about the wrong subject. I don't want to know about /tmp on tmpfs and I know that does clear /tmp at boot so clearly systems using it apparently have no problems with downloads or rogue scripts :)

But it was about then that /tmp policy was discussed.

...

What I want to know about is clearing /tmp on a regular filesystem and why SUSE doesn't clear it on boot. Since it's stated policy, I'd expect the policy to be documented.

That I do not know. I know that we discussed it for months in the mail lists.

You can seek the old scripts, pre-systemd, and verify that deleting on boot was optional. The other option was delete by age (by default), age configurable. Then go back more and more years, and see the same script there. I can not run my virtual machines (vmware refuses to run here), so I can not check on version 5.2, but I'm 96% sure that it was the same.

So I don't know if there is an actual document about it, but I can tell you that going 20 years back SuSE had the same policy on /tmp deletion.

And what we got on the discussion on the mail list was keep the default of not deleting on boot, but we did not get a script to delete by age. It has been on my todo list forever, so I delete files by hand.

Without some better hints I'm not going to be able to find anything. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Dave Howorth wrote:

For Dog's sake, WHY? Why would anybody want to keep a temporary file from before the system was booted? And if they did, why not put it in /var/tmp like they're supposed to?

Because some systems only boot maybe once a year or less ? As for using /var/tmp/, applications need to be specifically directed to use it.

A URL to the appropriate mail thread archive would likely help me understand.

ISTR being one of those who preferred not having /tmp cleared out by default.

Oh and note that the note in the file says 'SUSE' not 'openSUSE', which makes me even more curious.

These days, in the distro, the difference is minimal. -- Per Jessen, Zürich (6.1°C) http://www.cloudsuisse.com/ - your owncloud, hosted in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 19/02/2020 05.54, Anton Aylward wrote:

On 18/02/2020 15:28, Dave Howorth wrote:

...

For Dog's sake, WHY? Why would anybody want to keep a temporary file from before the system was booted? And if they did, why not put it in /var/tmp like they're supposed to?

Good question.

If we are talking about a personal system, a workstation, not a server, that is, for example, booted each morning and shutdown when you leave for work after reading your mail, then rebooted in the even of a bit of 'perusal', and 'all day' at weekend or holidays .... a "Linux instead of Windows" PC machine ...

Example situation. You use firefox to view a pdf in a tab. Powerdown for the night, or because maintenance or whatever. Includes a save session. On session restore, the tab has lost the pdf. Why? Because the pdf was downloaded to /tmp, and it was erased. Or... run save_y2logs which takes time to run, saves to /tmp. Days later I get some information and want to check file. It is lost. The assumption that /tmp will be deleted on boot does not exist in many cases. It is rather "it will be deleted eventually". -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)

On 19/02/2020 12.45, Dave Howorth wrote:

On Wed, 19 Feb 2020 11:20:18 +0100 "Carlos E.R." wrote:

...

On 19/02/2020 05.54, Anton Aylward wrote:

...

On 18/02/2020 15:28, Dave Howorth wrote:

...

For Dog's sake, WHY? Why would anybody want to keep a temporary file from before the system was booted? And if they did, why not put it in /var/tmp like they're supposed to?

Good question.

If we are talking about a personal system, a workstation, not a server, that is, for example, booted each morning and shutdown when you leave for work after reading your mail, then rebooted in the even of a bit of 'perusal', and 'all day' at weekend or holidays .... a "Linux instead of Windows" PC machine ...

Example situation.

You use firefox to view a pdf in a tab. Powerdown for the night, or because maintenance or whatever. Includes a save session. On session restore, the tab has lost the pdf.

Why? Because the pdf was downloaded to /tmp, and it was erased.

Firefox doesn't download to /tmp, it downloads to wherever you tell it to. So choose somewhere else if you want to keep it!

I may have done it ages ago and it reverted on its own another year. I don't mind. /tmp is SSD in my case, /home is not. Notice it is not the "download" file function. It is the view pdf file, and it does not ask.

...

Or...

run save_y2logs which takes time to run, saves to /tmp. Days later I get some information and want to check file. It is lost.

Again, give save_y2logs a permanent location if that's what you want.

I like it there, temporarily :-) It will be deleted eventually. Just not on boot.

...

The assumption that /tmp will be deleted on boot does not exist in many cases.

I don't know what that means?

...

It is rather "it will be deleted eventually".

Well, that the programmers of whatever that used /tmp did not assume that it would be deleted always on the next boot. The FHS may chant mass if they like, but it is not law. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)

On 19/02/2020 15.41, Anton Aylward wrote:

On 19/02/2020 05:20, Carlos E.R. wrote:

...

Example situation.

You use firefox to view a pdf in a tab. Powerdown for the night, or because maintenance or whatever. Includes a save session. On session restore, the tab has lost the pdf.

Why? Because the pdf was downloaded to /tmp, and it was erased.

Good example of why 'clear on boot" or "clear on shutdown" is a no-go.

BUT ...

what about timeut? What about deleting files 30 days old? 60 days old? A suitable entry in /usr/lib/tmpfiles.d/tmp.conf

IIRC I failed to find what that suitable entry might be. And that age must be ensured to be older than the current boot, so it is not that trivial.

Oh, and I get get leftover junk like this -rw------- 1 anton anton 1.6K Feb 18 09:27 nsemail.eml -rw------- 1 anton anton 1.7K Feb 18 10:29 nsemail-1.eml -rw------- 1 anton anton 1.5K Feb 18 10:54 nsemail-2.eml -rw------- 1 anton anton 1.7K Feb 18 11:04 nsemail-3.eml -rw------- 1 anton anton 1.3K Feb 18 12:26 nsemail-4.eml -rw------- 1 anton anton 1.6K Feb 18 23:54 nsemail-5.eml -rw------- 1 anton anton 24K Feb 19 00:39 nsmail-1.tmp -rw------- 1 anton anton 19K Feb 19 00:40 nscpmsg-1.txt

which accumulates maybe by the hundreds a day! It has to be manually deleted. is there a way in tmpfiles to specify a file pattern to delete?

https://unix.stackexchange.com/questions/500197/using-systemd-tmpfiles-to-re...

Oh.

Oh.

Those files seem to come from Thunderbird and are the temporary edits of outgoing messages. Is this a security problem? Could i point TB to use a specific directory for that?

oh, wait, https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1853007

I must reread this. Not today. -- Cheers / Saludos, Carlos E. R. (from openSUSE 15.1 (Legolas))

On Tue, 18 Feb 2020 19:54:52 +0100 Per Jessen wrote:

Dave Howorth wrote:

...

On Tue, 18 Feb 2020 12:37:37 +0100 "Carlos E. R." wrote:

...

On 18/02/2020 12.26, Dave Howorth wrote:

...

On Tue, 18 Feb 2020 12:08:59 +0100 Peter Suetterlin wrote:

...

Ianseeks wrote:

...

I've got a pretty much stock set up and my tmp directory was full of months old stuff and the same went for the journals so it doesn't seem set up for automatic housekeeping out of the box.

I think tmp is indeed not cleaned (on purpose, IIRC).

https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s18.html

"Although data stored in /tmp may be deleted in a site-specific manner, **it is recommended that files and directories located in /tmp be deleted whenever the system is booted.**"

My /tmp gets very large as well particularly with stuff from firefox so I don't think openSUSE clears it at boot properly.

Intentionally so, I understand. The old setting, pre-systemd, was to delete aged files (I think there was a configuration setting to do at boot). After systemd, it is broken, because the recommended systemd thing is to have /tmp on ram, and we don't by default (intentionally, we users demanded this).

I don't understand what systemd has to do with it. FHS says:

/tmp is for temporary files that should be cleared at boot. /var/tmp is for temporary files that must NOT be cleared at boot.

TMK, we (openSUSE) or our apps don't follow that bit of the standard.

IIRC, at some point we did start clearing out /tmp, but that was quickly reverted.

...

When I look in /usr/lib/tmpfiles.d/tmp.conf I see:

# Clear tmp directories separately, to make them easier to override # SUSE policy: we don't clean those directories q /tmp 1777 root root - q /var/tmp 1777 root root -

So I think the blame is quite clearly laid at SUSE's door. Can anybody tell me where this policy of SUSE's that contradicts FHS is (a) defined and (b) explained?

I am sure we have quite a few things that violate the FHS. Most recently moving /etc/srvices to /usr (just an example). I have no idea where it might be "defined", but the explanation is straight forward, we want to leave any clearing of /tmp up to the user.

...

Also how do I set the system to clear /tmp on reboot?

The best starting place is probably "man tmpfiles.d". or you add own cronjob.

I'm afraid I found that page impenetrable, like other people I found asking when I googled. How would I use it? Or how would I set up a cronjob? Something needs to clear /tmp as the system is booted and before anything can create a file (or socket etc) in it. But at what point is that where /tmp exists but isn't used? Or can it just be recreated somehow? (it's a btrfs subvolume on my system - I know nothing about any possible mechanisms). How to get the right time in the boot sequence?

...

It annoys me to have to override default conf just to get back to how the system is supposed to work

There is plenty of that, Dave. The default never works for me, not even on plain office desktop systems. At the very least, the postfix and the syslog configs have to be adapted.

I haven't touched either. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Dave Howorth wrote:

...

...

Also how do I set the system to clear /tmp on reboot?

The best starting place is probably "man tmpfiles.d". or you add own cronjob.

I'm afraid I found that page impenetrable, like other people I found asking when I googled. How would I use it? Or how would I set up a cronjob?

This ought to do it: @reboot root find /tmp/ | xargs -r rm -Rf Or you keep /tmp on an in-memory filesystem.

Something needs to clear /tmp as the system is booted and before anything can create a file (or socket etc) in it. But at what point is that where /tmp exists but isn't used? Or can it just be recreated somehow? (it's a btrfs subvolume on my system - I know nothing about any possible mechanisms). How to get the right time in the boot sequence?

More to the point - why does it matter?

...

...

It annoys me to have to override default conf just to get back to how the system is supposed to work

There is plenty of that, Dave. The default never works for me, not even on plain office desktop systems. At the very least, the postfix and the syslog configs have to be adapted.

I haven't touched either.

Much depends on your (and my) definition of "how the system is supposed to work". That is why the default is only good enough for the most basic setup. -- Per Jessen, Zürich (6.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

Carlos E. R. wrote:

On 18/02/2020 23.17, Per Jessen wrote:

...

Dave Howorth wrote:

...

...

...

Also how do I set the system to clear /tmp on reboot?

The best starting place is probably "man tmpfiles.d". or you add own cronjob.

I'm afraid I found that page impenetrable, like other people I found asking when I googled. How would I use it? Or how would I set up a cronjob?

This ought to do it:

@reboot root find /tmp/ | xargs -r rm -Rf

By that time, something might already be using it.

In the init-sequence? I guess, maybe. So put in a mtime +X to only delete old stuff.

Just put it here:

Telcontar:~ # ls /etc/init.d/*local /etc/init.d/after.local /etc/init.d/boot.local One runs before the init, another runs after.

FWIW, on my TW test system, neither of those two existed. When I created them both, I could still only see 'after.local' with systemctl status ?? The sequence on a reboot: 11:57:28 - boot.local runs 11:57:37 - after.local runs 11:57:37 - boot.local runs 11:57:59 - after.local runs 11:58:01 - cron @ reboot runs Looks like those scripts are being run _twice_ ?

...

...

Something needs to clear /tmp as the system is booted and before anything can create a file (or socket etc) in it. But at what point is that where /tmp exists but isn't used? Or can it just be recreated somehow? (it's a btrfs subvolume on my system - I know nothing about any possible mechanisms). How to get the right time in the boot sequence?

More to the point - why does it matter?

Doing it at the correct instant? Because you may delete temporary files from a running process.

Like you suggested yourself, only delete old stuff. -- Per Jessen, Zürich (6.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

Carlos E. R. wrote:

...

The sequence on a reboot:

11:57:28 - boot.local runs 11:57:37 - after.local runs 11:57:37 - boot.local runs 11:57:59 - after.local runs 11:58:01 - cron @ reboot runs

Looks like those scripts are being run _twice_ ?

I don't know, new to me. How did you find out?

I just wrote a message to log using logger. 4 different pids as well. -- Per Jessen, Zürich (6.6°C) http://www.cloudsuisse.com/ - your owncloud, hosted in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Carlos E. R. wrote:

On 19/02/2020 15.12, Per Jessen wrote:

...

Carlos E. R. wrote:

...

...

The sequence on a reboot:

11:57:28 - boot.local runs 11:57:37 - after.local runs 11:57:37 - boot.local runs 11:57:59 - after.local runs 11:58:01 - cron @ reboot runs

Looks like those scripts are being run _twice_ ?

I don't know, new to me. How did you find out?

I just wrote a message to log using logger. 4 different pids as well.

Must be a bug, no?

I guess, but I don't personally care to file a bug and do the follow-up work. I have never had any use for either of those functions. I think they are a left over from previous times. If you want something run on boot-up, use cron::@reboot (mostly for users) or create a service unit. -- Per Jessen, Zürich (5.6°C) http://www.cloudsuisse.com/ - your owncloud, hosted in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Tue, 18 Feb 2020 23:17:35 +0100 Per Jessen wrote:

Dave Howorth wrote:

...

...

...

Also how do I set the system to clear /tmp on reboot?

The best starting place is probably "man tmpfiles.d". or you add own cronjob.

I'm afraid I found that page impenetrable, like other people I found asking when I googled. How would I use it? Or how would I set up a cronjob?

This ought to do it:

@reboot root find /tmp/ | xargs -r rm -Rf

OK I'll try that, thanks. I wasn't sure when @reboot got run.

Or you keep /tmp on an in-memory filesystem.

Well, no. I agree with the notion that /tmp should be on a disk/SSD rather than in RAM. If something wants temporary files in RAM, it's free to use /run

...

Something needs to clear /tmp as the system is booted and before anything can create a file (or socket etc) in it. But at what point is that where /tmp exists but isn't used? Or can it just be recreated somehow? (it's a btrfs subvolume on my system - I know nothing about any possible mechanisms). How to get the right time in the boot sequence?

More to the point - why does it matter?

Well, it obviously has to be late enough in the boot process that /tmp exists and is mounted, but it needs to be before any service has started and stored a *.pid or created a socket or whatever in /tmp. I'd thought that needed enough care that it would be documented somewhere but I haven't managed to find an assurance. Just lots of doubts about different versions of cron doing different things.

...

...

...

It annoys me to have to override default conf just to get back to how the system is supposed to work

There is plenty of that, Dave. The default never works for me, not even on plain office desktop systems. At the very least, the postfix and the syslog configs have to be adapted.

I haven't touched either.

Much depends on your (and my) definition of "how the system is supposed to work". That is why the default is only good enough for the most basic setup.

Fair enough. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 19/02/2020 12.09, Dave Howorth wrote:

On Tue, 18 Feb 2020 23:17:35 +0100 Per Jessen <> wrote:

...

Dave Howorth wrote:

...

...

...

Also how do I set the system to clear /tmp on reboot?

The best starting place is probably "man tmpfiles.d". or you add own cronjob.

I'm afraid I found that page impenetrable, like other people I found asking when I googled. How would I use it? Or how would I set up a cronjob?

This ought to do it:

@reboot root find /tmp/ | xargs -r rm -Rf

OK I'll try that, thanks. I wasn't sure when @reboot got run.

...

Or you keep /tmp on an in-memory filesystem.

Well, no. I agree with the notion that /tmp should be on a disk/SSD rather than in RAM. If something wants temporary files in RAM, it's free to use /run

...

...

Something needs to clear /tmp as the system is booted and before anything can create a file (or socket etc) in it. But at what point is that where /tmp exists but isn't used? Or can it just be recreated somehow? (it's a btrfs subvolume on my system - I know nothing about any possible mechanisms). How to get the right time in the boot sequence?

More to the point - why does it matter?

Well, it obviously has to be late enough in the boot process that /tmp exists and is mounted, but it needs to be before any service has started and stored a *.pid or created a socket or whatever in /tmp.

Then cron (@reboot) is too late. /etc/init.d/boot.local exists for those purposes. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)

On 19/02/2020 21.49, Dave Howorth wrote:

On Wed, 19 Feb 2020 14:35:07 +0100 "Carlos E. R." <> wrote:

...

On 19/02/2020 12.09, Dave Howorth wrote:

...

On Tue, 18 Feb 2020 23:17:35 +0100 Per Jessen <> wrote:

...

Dave Howorth wrote:

...

...

> Also how do I set the system to clear /tmp > on reboot?

The best starting place is probably "man tmpfiles.d". or you add own cronjob.

I'm afraid I found that page impenetrable, like other people I found asking when I googled. How would I use it? Or how would I set up a cronjob?

This ought to do it:

@reboot root find /tmp/ | xargs -r rm -Rf

OK I'll try that, thanks. I wasn't sure when @reboot got run.

...

Or you keep /tmp on an in-memory filesystem.

Well, no. I agree with the notion that /tmp should be on a disk/SSD rather than in RAM. If something wants temporary files in RAM, it's free to use /run

...

...

Something needs to clear /tmp as the system is booted and before anything can create a file (or socket etc) in it. But at what point is that where /tmp exists but isn't used? Or can it just be recreated somehow? (it's a btrfs subvolume on my system - I know nothing about any possible mechanisms). How to get the right time in the boot sequence?

More to the point - why does it matter?

Well, it obviously has to be late enough in the boot process that /tmp exists and is mounted, but it needs to be before any service has started and stored a *.pid or created a socket or whatever in /tmp.

Then cron (@reboot) is too late. /etc/init.d/boot.local exists for those purposes.

That's a sysVinit feature (and maybe hangover?) not a systemd one. So I'd much rather use the systemd equivalent, but as already stated I find the man page impenetrable.

WAS an init.d feature, which has been respected and documented. I do not know of any pure systemd way. So use the provided hook till the time you find the native systemd way if it exists. -- Cheers / Saludos, Carlos E. R. (from openSUSE 15.1 (Legolas))

On 20/02/2020 08.21, Per Jessen wrote:

Carlos E. R. wrote:

...

On 19/02/2020 21.49, Dave Howorth wrote:

...

...

...

Then cron (@reboot) is too late. /etc/init.d/boot.local exists for those purposes.

That's a sysVinit feature (and maybe hangover?) not a systemd one. So I'd much rather use the systemd equivalent, but as already stated I find the man page impenetrable.

WAS an init.d feature, which has been respected and documented. I do not know of any pure systemd way. So use the provided hook till the time you find the native systemd way if it exists.

You just create a service unit.

I don't think it is possible that early. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)

Per Jessen wrote:

Carlos E. R. wrote:

...

On 20/02/2020 08.21, Per Jessen wrote:

...

Carlos E. R. wrote:

...

On 19/02/2020 21.49, Dave Howorth wrote:

...

...

...

Then cron (@reboot) is too late. /etc/init.d/boot.local exists for those purposes.

That's a sysVinit feature (and maybe hangover?) not a systemd one. So I'd much rather use the systemd equivalent, but as already stated I find the man page impenetrable.

WAS an init.d feature, which has been respected and documented. I do not know of any pure systemd way. So use the provided hook till the time you find the native systemd way if it exists.

You just create a service unit.

I don't think it is possible that early.

It is. Something has to be the first. My comments in []:

Sorry, I forgot to add the service unit: # systemctl cat carlos.service # /etc/systemd/system/carlos.service [Unit] Description=blah Requires=local-fs.target After=local-fs.target [Service] Type=oneshot RemainAfterExit=yes ExecStart=/usr/bin/logger -i blahblah [Install] WantedBy=multi-user.target -- Per Jessen, Zürich (8.0°C) http://www.hostsuisse.com/ - virtual servers, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 20/02/2020 16.00, Anton Aylward wrote:

On 20/02/2020 02:21, Per Jessen wrote:

...

Carlos E. R. wrote:

...

On 19/02/2020 21.49, Dave Howorth wrote:

...

...

...

Then cron (@reboot) is too late. /etc/init.d/boot.local exists for those purposes.

That's a sysVinit feature (and maybe hangover?) not a systemd one. So I'd much rather use the systemd equivalent, but as already stated I find the man page impenetrable.

WAS an init.d feature, which has been respected and documented. I do not know of any pure systemd way. So use the provided hook till the time you find the native systemd way if it exists.

You just create a service unit.

+1

I don't know why so many people find this scary.

Well, editing /etc/init.d/boot.local is easier, and it is a supported method with no date for disappearance. -- Cheers / Saludos, Carlos E. R. (from openSUSE 15.1 (Legolas))

fwiw, boot.local is invoked immediately after reaching basic.target cat /usr/lib/systemd/system/rc-local.service # This file is part of systemd. # # systemd is free software; you can redistribute it and/or modify it # under the terms of the GNU Lesser General Public License as published by # the Free Software Foundation; either version 2.1 of the License, or # (at your option) any later version. # This unit gets pulled automatically into multi-user.target by # systemd-rc-local-generator if /etc/init.d/boot.local is executable. [Unit] Description=/etc/init.d/boot.local Compatibility ConditionFileIsExecutable=/etc/init.d/boot.local

...

After=basic.target

[Service] Type=forking ExecStart=/etc/init.d/boot.local start TimeoutSec=0 RemainAfterExit=yes GuessMainPID=no using after.local gives add'l flexibility to exec later, e.g. cat /etc/systemd/system/after-local.service [Unit]

...

After=syslog.target network-online.target basic.target

Description=/etc/init.d/after.local Compatibility ConditionFileIsExecutable=/etc/init.d/after.local

[Service] Type=oneshot ExecStart=/etc/init.d/after.local TimeoutSec=0 StandardOutput=tty RemainAfterExit=yes [Install] WantedBy=multi-user.target in either case, the service needs to be enabled/started systemctl status after-local rc-local ● after-local.service - /etc/init.d/after.local Compatibility Loaded: loaded (/etc/systemd/system/after-local.service; enabled; vendor preset: disabled) Active: active (exited) since Wed 2020-02-19 07:04:50 PST; 1 day 5h ago Main PID: 3661 (code=exited, status=0/SUCCESS) Tasks: 0 (limit: 9830) CGroup: /system.slice/after-local.service ● rc-local.service - /etc/init.d/boot.local Compatibility Loaded: loaded (/usr/lib/systemd/system/rc-local.service; enabled-runtime; vendor preset: disabled) Active: active (exited) since Wed 2020-02-19 07:04:42 PST; 1 day 5h ago Tasks: 0 (limit: 9830) CGroup: /system.slice/rc-local.service regardless of distro/release -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 20/02/2020 13:08, Carlos E. R. wrote:

On 20/02/2020 16.00, Anton Aylward wrote:

...

On 20/02/2020 02:21, Per Jessen wrote:

...

...

You just create a service unit.

+1

I don't know why so many people find this scary.

Well, editing /etc/init.d/boot.local is easier, and it is a supported method with no date for disappearance.

No and No. As far as reasons not to use service units go. No, functional programming isn't easier than declarative programming. Service units can do many things that the shell programming approach could not, (see the systemd.directives man page for some examples) and make the structure of the dependencies VERY clear. No, you are wrong to imply that the systemd approach is not displacing the the SysVinit approach. It has. Running # find /etc -name '*local*' returns many things on my Leap15.1 system but not boot.local In fact the archaic /etc/init.d/ has no files at all. oh, wait, sorry, there is /etc/init.d/systemd-journald which is ### BEGIN INIT INFO # Provides: syslog # Required-Start: $null # Required-Stop: $null # Default-Start: 2 3 5 # Default-Stop: # Short-Description: compat wrapper for journald # Description: compat wrapper for journald ### END INIT INFO If I want a boot.local I have to put it there manually, but since I'm running systemd I can just as easily manually put a service unit there instead. As the man page says: /etc/systemd/system is for the local configuration -- A: Yes. > 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

On 19/02/2020 06:09, Dave Howorth wrote:

Well, no. I agree with the notion that /tmp should be on a disk/SSD rather than in RAM. If something wants temporary files in RAM, it's free to use /run

If you are programming it yourself then yes, otherwise you're screwed and have to take what someone else decided for you, someone who know better than you do what you want and need without consulting you about the matter. Yes, I may want TB downloads to stay around, but there's this bug that it doesn't delete the edit file /tmp that I mentioned and I can't get to it use /tmp/thunderbird and let tempfules.d clean that out daily! BUG and its been around a long time! Of course the developers know better so it isn't a bug, is it, otherwise they would have fixed it years ago. And given you proper control over what to use as a temporary directory when using Thunderbird. -- A: Yes. > 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

On Tuesday, 18 February 2020 18:54:52 GMT Per Jessen wrote:

Dave Howorth wrote:

...

On Tue, 18 Feb 2020 12:37:37 +0100 "Carlos E. R." wrote:

...

On 18/02/2020 12.26, Dave Howorth wrote:

...

On Tue, 18 Feb 2020 12:08:59 +0100 Peter Suetterlin wrote:

...

Ianseeks wrote:

...

I've got a pretty much stock set up and my tmp directory was full of months old stuff and the same went for the journals so it doesn't seem set up for automatic housekeeping out of the box.

I think tmp is indeed not cleaned (on purpose, IIRC).

https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s18.html

"Although data stored in /tmp may be deleted in a site-specific manner, **it is recommended that files and directories located in /tmp be deleted whenever the system is booted.**"

My /tmp gets very large as well particularly with stuff from firefox so I don't think openSUSE clears it at boot properly.

Intentionally so, I understand. The old setting, pre-systemd, was to delete aged files (I think there was a configuration setting to do at boot). After systemd, it is broken, because the recommended systemd thing is to have /tmp on ram, and we don't by default (intentionally, we users demanded this).

I don't understand what systemd has to do with it. FHS says:

/tmp is for temporary files that should be cleared at boot. /var/tmp is for temporary files that must NOT be cleared at boot.

TMK, we (openSUSE) or our apps don't follow that bit of the standard.

IIRC, at some point we did start clearing out /tmp, but that was quickly reverted.

...

When I look in /usr/lib/tmpfiles.d/tmp.conf I see:

# Clear tmp directories separately, to make them easier to override # SUSE policy: we don't clean those directories q /tmp 1777 root root - q /var/tmp 1777 root root -

So I think the blame is quite clearly laid at SUSE's door. Can anybody tell me where this policy of SUSE's that contradicts FHS is (a) defined and (b) explained?

I am sure we have quite a few things that violate the FHS. Most recently moving /etc/srvices to /usr (just an example). I have no idea where it might be "defined", but the explanation is straight forward, we want to leave any clearing of /tmp up to the user.

I think leaving it to the user is fine for business configs then you can use the aging cleanup but for home users that do not have any idea about /tmp etc, i think it should be cleared on boot - maybe a config item somewhere to say "clear on boot Y/N" would get around the hard coded choice

...

Also how do I set the system to clear /tmp on reboot?

The best starting place is probably "man tmpfiles.d". or you add own cronjob.

...

It annoys me to have to override default conf just to get back to how the system is supposed to work

There is plenty of that, Dave. The default never works for me, not even on plain office desktop systems. At the very least, the postfix and the syslog configs have to be adapted.

-- opensuse:tumbleweed:20200214 Qt: 5.14.1 KDE Frameworks: 5.67.0 - KDE Plasma: 5.18.0 - kwin 5.18.0 kmail2 5.13.2 (19.12.2) - akonadiserver 5.13.2 (19.12.2) - Kernel: 5.5.2-1-default - xf86-video-nouveau: 1.0.15 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Dave Howorth wrote:

I don't understand what systemd has to do with it. FHS says:

/tmp is for temporary files that should be cleared at boot. /var/tmp is for temporary files that must NOT be cleared at boot.

This wording seems quite clear to me: It is MANDATORY not to clean /var/tmp It is OPTIONAL (though recommended) to clean /tmp So IMO the openSUSE way is probably uncommon, but not in contradiction to FHS... -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 18/02/2020 13.10, Ianseeks wrote:

On Tuesday, 18 February 2020 11:26:04 GMT Dave Howorth wrote:

...

On Tue, 18 Feb 2020 12:08:59 +0100 Peter Suetterlin wrote:

...

journal works just fine with default settings for me 184M at the moment.

Is that really the default? I've never touched the settings in this file and both of those are "#" out, the only ones set are "Storage=persistent", "ForwardToSyslog=no", "ForwardToWall=no"

No, the default is percent based. You can fix a limit: #SystemMaxUse=100M #RuntimeMaxUse=30M -- Cheers / Saludos, Carlos E. R. (from openSUSE 15.1 (Legolas))

Ianseeks wrote:

On Tuesday, 18 February 2020 10:01:09 GMT Per Jessen wrote:

...

Ianseeks wrote:

...

Hi

For ordinary lazy users like me who are not interested in or capable of system admin as a daily chore, should there not be the possibility of a section in Yast2 or Systemsettings where some standard user friendly housekeeping functions (e.g. flushing tmp folders, vacuuming journals etc) could be activated/configured to run at startup/shutdown rather than have to scour the net for solutions. For many like me, the computer should be doing more work with stuff that could be automated.

Agree completely. I think most if not all also does happen automagically ?

I've got a pretty much stock set up and my tmp directory was full of months old stuff and the same went for the journals so it doesn't seem set up for automatic housekeeping out of the box.

I feel pretty certain there is an automatic tmp-cleaner - yes, see systemctl status systemd-tmpfiles-cleaen journals - I really don't know, I use syslog-ng logrotate.

...

...

I've just hit the "system disk full" message when running "zypper", it would have been better if a "disk getting full" message was displayed at login so i could have dealt with it.

I'm not sure if this is one of the conditions being monitored, anywhere. That was my thought too,

Actually, in my old system I see something warning me that the filesystem is 95% full. It then asks if I'd like to open Konqueror. -- Per Jessen, Zürich (10.9°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Tue, 18 Feb 2020 13:45:24 +0100 Per Jessen wrote:

Ianseeks wrote:

...

On Tuesday, 18 February 2020 10:01:09 GMT Per Jessen wrote:

...

Ianseeks wrote:

...

Hi

For ordinary lazy users like me who are not interested in or capable of system admin as a daily chore, should there not be the possibility of a section in Yast2 or Systemsettings where some standard user friendly housekeeping functions (e.g. flushing tmp folders, vacuuming journals etc) could be activated/configured to run at startup/shutdown rather than have to scour the net for solutions. For many like me, the computer should be doing more work with stuff that could be automated.

Agree completely. I think most if not all also does happen automagically ?

I've got a pretty much stock set up and my tmp directory was full of months old stuff and the same went for the journals so it doesn't seem set up for automatic housekeeping out of the box.

I feel pretty certain there is an automatic tmp-cleaner - yes, see

systemctl status systemd-tmpfiles-cleaen

Hmm, what that shows me is: Feb 18 10:59:41 acer-suse systemd[1]: Starting Cleanup of Temporary Directories... Feb 18 10:59:41 acer-suse systemd-tmpfiles[26769]: [/usr/lib/tmpfiles.d/lirc.conf:1] Line references path below legacy directory /var/run/, updating /var/run/lirc → /run/lirc; please update the tmpfiles.d/ d> Feb 18 10:59:41 acer-suse systemd-tmpfiles[26769]: [/usr/lib/tmpfiles.d/net-snmp.conf:1] Line references path below legacy directory /var/run/, updating /var/run/net-snmp → /run/net-snmp; please update the t> Feb 18 10:59:41 acer-suse systemd-tmpfiles[26769]: [/usr/lib/tmpfiles.d/radvd.conf:1] Line references path below legacy directory /var/run/, updating /var/run/radvd → /run/radvd; please update the tmpfiles.d> Feb 18 10:59:41 acer-suse systemd-tmpfiles[26769]: [/usr/lib/tmpfiles.d/redis.conf:2] Line references path below legacy directory /var/run/, updating /var/run/redis/ → /run/redis/; please update the tmpfiles> Feb 18 10:59:41 acer-suse systemd-tmpfiles[26769]: [/usr/lib/tmpfiles.d/samba.conf:1] Line references path below legacy directory /var/run/, updating /var/run/samba → /run/samba; please update the tmpfiles.d> Feb 18 10:59:41 acer-suse systemd-tmpfiles[26769]: [/usr/lib/tmpfiles.d/svnserve.conf:1] Line references path below legacy directory /var/run/, updating /var/run/svnserve → /run/svnserve; please update the t> Feb 18 10:59:41 acer-suse systemd-tmpfiles[26769]: [/usr/lib/tmpfiles.d/tmp.conf:13] Duplicate line for path "/var/tmp", ignoring. Feb 18 10:59:41 acer-suse systemd-tmpfiles[26769]: [/usr/lib/tmpfiles.d/var.conf:21] Duplicate line for path "/var/lib", ignoring. Feb 18 10:59:41 acer-suse systemd-tmpfiles[26769]: [/usr/lib/tmpfiles.d/var.conf:23] Duplicate line for path "/var/spool", ignoring. Feb 18 10:59:42 acer-suse systemd[1]: Started Cleanup of Temporary Directories. Since I didn't know of that service, I don't think I've customised it, so I suppose these warnings represent errors in the configuration provided by openSUSE. Indeed there are lines in both var.conf and fs-var.conf, and in tmp.conf and fs-var.conf

journals - I really don't know, I use syslog-ng logrotate.

man journald.conf # for settings journalctl --vacuum-size=<whatever> # to discard old journals

...

...

...

I've just hit the "system disk full" message when running "zypper", it would have been better if a "disk getting full" message was displayed at login so i could have dealt with it.

I'm not sure if this is one of the conditions being monitored, anywhere. That was my thought too,

Actually, in my old system I see something warning me that the filesystem is 95% full. It then asks if I'd like to open Konqueror.

-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 18/02/2020 19.28, Per Jessen wrote:

Dave Howorth wrote:

...

...

journals - I really don't know, I use syslog-ng logrotate.

man journald.conf # for settings journalctl --vacuum-size=<whatever> # to discard old journals

Apart from running syslog-ng everywhere, we seem to manage with the default setting on all our systems, I don't recall ever having had reason to look at it.

Looking at /run/log/journal on a system that's been up for 28 days, I see about 8Mb used.

On a customer system I manage, uptime 119 days, I see 200M in use.

I could imagine space becoming an issue on much smaller systems, raspi size. I have a single Raspi - uptime 19 days - but it doesn't even have a /rub/log/journal directory.

On a production system with lots of activity, uptime 89 days, I see /run/log/journal taking up 608Mb.

Try on a mail or news server, and it grows huge, or it rotates. All the journal is about mail or news, the machine things get rotated out. If not, it gets huge. But the default is a temporary journal, this boot only. -- Cheers / Saludos, Carlos E. R. (from openSUSE 15.1 (Legolas))

On 18/02/2020 20.46, Dave Howorth wrote:

On Tue, 18 Feb 2020 19:33:56 +0100 "Carlos E. R." <> wrote:

...

On 18/02/2020 19.28, Per Jessen wrote:

...

Dave Howorth wrote:

...

...

On a production system with lots of activity, uptime 89 days, I see /run/log/journal taking up 608Mb.

Try on a mail or news server, and it grows huge, or it rotates. All the journal is about mail or news, the machine things get rotated out. If not, it gets huge.

But the default is a temporary journal, this boot only.

By default it writes in /run/log/journal unless /var/log/journal exists, in which case it writes there. I'd expect admins of servers to create /var/log/journal but apparently not all do.

Syslog is more reliable and customizable. -- Cheers / Saludos, Carlos E. R. (from openSUSE 15.1 (Legolas))

On 18/02/2020 21.47, Dave Howorth wrote:

On Tue, 18 Feb 2020 21:23:07 +0100 "Carlos E. R." wrote:

...

On 18/02/2020 20.46, Dave Howorth wrote:

...

On Tue, 18 Feb 2020 19:33:56 +0100 "Carlos E. R." <> wrote:

...

On 18/02/2020 19.28, Per Jessen wrote:

...

Dave Howorth wrote:

...

...

...

On a production system with lots of activity, uptime 89 days, I see /run/log/journal taking up 608Mb.

Try on a mail or news server, and it grows huge, or it rotates. All the journal is about mail or news, the machine things get rotated out. If not, it gets huge.

But the default is a temporary journal, this boot only.

By default it writes in /run/log/journal unless /var/log/journal exists, in which case it writes there. I'd expect admins of servers to create /var/log/journal but apparently not all do.

Syslog is more reliable and customizable.

How can it be more reliable when it gets its data from journald?

Yes and no (at least one daemon gets data earlier). But the problem is controlling the written data. There is no way in journal to remove entries that you do not need or store parts separately. There is no way to choose, say, "keep 5 years of mail logs, and 2 years of machine logs". And being text files, they are trivial to archive and read. Are you sure you will be able to read a 5 year old journal on a different machine? -- Cheers / Saludos, Carlos E. R. (from openSUSE 15.1 (Legolas))

On 19/02/2020 10.35, Ianseeks wrote:

On Tuesday, 18 February 2020 21:56:01 GMT Carlos E. R. wrote:

...

On 18/02/2020 21.47, Dave Howorth wrote:

...

On Tue, 18 Feb 2020 21:23:07 +0100 "Carlos E. R." <> wrote:

...

But the problem is controlling the written data. There is no way in journal to remove entries that you do not need or store parts separately. There is no way to choose, say, "keep 5 years of mail logs, and 2 years of machine logs". And being text files, they are trivial to archive and read. From a security stand point, should you allow editing of log files? I thought that was one way how people hid their intrusions

If that is the issue, syslog* also allows binary formats like database and surely signing. Then there is the method of sending the logs to an inaccessible machine. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)

On 19/02/2020 20.38, Lew Wolfgang wrote:

On 2/19/20 1:50 AM, Carlos E. R. wrote:

...

...

From a security stand point, should you allow editing of log files? I thought that was one way how people hid their intrusions

If that is the issue, syslog* also allows binary formats like database and surely signing.

Then there is the method of sending the logs to an inaccessible machine.

This reminds me of a requirement that two people are required to remove/alter security logs. I can't think of a way to do this using standard operating systems. Two root accounts, where both must be logged on to do anything? Anyone heard of such a thing?

Nope. New pam module? -- Cheers / Saludos, Carlos E. R. (from openSUSE 15.1 (Legolas))

On 02/19/2020 12:51 PM, Dave Howorth wrote:

On Wed, 19 Feb 2020 11:38:25 -0800 Lew Wolfgang wrote:

...

On 2/19/20 1:50 AM, Carlos E. R. wrote:

...

...

From a security stand point, should you allow editing of log files? I thought that was one way how people hid their intrusions If that is the issue, syslog* also allows binary formats like database and surely signing.

Then there is the method of sending the logs to an inaccessible machine. This reminds me of a requirement that two people are required to remove/alter security logs.  I can't think of a way to do this using standard operating systems. Two root accounts, where both must be logged on to do anything? Anyone heard of such a thing? Make two copies of the logs and store one copy where one person can alter it and the other copy where the other person can alter it. Then diff the copies before trusting either. Might be best to have three copies :)

That's an excellent idea!  syslog-ng could be used to send logs to two different log servers in real time. But another problem might be auditd, which doesn't use syslog to the best of my knowledge.  Maybe a script or two piping to "logger" to write to syslog? Regards, Lew -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 02/20/2020 01:48 AM, Carlos E. R. wrote:

On 20/02/2020 07.09, Lew Wolfgang wrote:

...

On 02/19/2020 12:51 PM, Dave Howorth wrote:

...

On Wed, 19 Feb 2020 11:38:25 -0800 Lew Wolfgang wrote:

...

On 2/19/20 1:50 AM, Carlos E. R. wrote:

...

...

 From a security stand point, should you allow editing of log files? I thought that was one way how people hid their intrusions If that is the issue, syslog* also allows binary formats like database and surely signing.

Then there is the method of sending the logs to an inaccessible machine. This reminds me of a requirement that two people are required to remove/alter security logs.  I can't think of a way to do this using standard operating systems. Two root accounts, where both must be logged on to do anything? Anyone heard of such a thing? Make two copies of the logs and store one copy where one person can alter it and the other copy where the other person can alter it. Then diff the copies before trusting either. Might be best to have three copies :)

That's an excellent idea!  syslog-ng could be used to send logs to two different log servers in real time.

But another problem might be auditd, which doesn't use syslog to the best of my knowledge.  Maybe a script or two piping to "logger" to write to syslog?

You mean apparmor? It does write somethings to syslog. I guess it is easier to parse a standalone audit log.

No, not apparmor.  I was  thinking of the Linux Auditing System: https://www.networkworld.com/article/2224092/linux-auditing-101.html But I think that link solved the problem.  It references a package called audispd which sends it's logs, normally stored in /var/log/audit to a remote server.  It shows up in zypper as audit-audispd-plugins. I'll have to take a look when I get a chance. Regards, Lew -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Fri, 28 Feb 2020 01:07:39 +0100 (CET) "Carlos E. R." wrote:

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

El 2020-02-20 a las 09:13 -0800, Lew Wolfgang escribió:

...

On 02/20/2020 01:48 AM, Carlos E. R. wrote:

...

On 20/02/2020 07.09, Lew Wolfgang wrote:

...

On 02/19/2020 12:51 PM, Dave Howorth wrote:

...

On Wed, 19 Feb 2020 11:38:25 -0800 Lew Wolfgang wrote:

...

On 2/19/20 1:50 AM, Carlos E. R. wrote: >>  From a security stand point, should you allow editing of log >> files? I thought that was one way how people hid their >> intrusions > If that is the issue, syslog* also allows binary formats like > database and surely signing. > > Then there is the method of sending the logs to an > inaccessible machine. This reminds me of a requirement that two people are required to remove/alter security logs.  I can't think of a way to do this using standard operating systems. Two root accounts, where both must be logged on to do anything? Anyone heard of such a thing? Make two copies of the logs and store one copy where one person can alter it and the other copy where the other person can alter it. Then diff the copies before trusting either. Might be best to have three copies :)

That's an excellent idea!  syslog-ng could be used to send logs to two different log servers in real time.

But another problem might be auditd, which doesn't use syslog to the best of my knowledge.  Maybe a script or two piping to "logger" to write to syslog?

You mean apparmor? It does write somethings to syslog. I guess it is easier to parse a standalone audit log.

No, not apparmor.  I was  thinking of the Linux Auditing System:

https://www.networkworld.com/article/2224092/linux-auditing-101.html

But /var/log/audit/audit.log is written by AA.

That may be but I don't have apparmor on my system and audit.log is getting written to, specifically by auditd.

...

But I think that link solved the problem.  It references a package called audispd which sends it's logs, normally stored in /var/log/audit to a remote server.  It shows up in zypper as audit-audispd-plugins. I'll have to take a look when I get a chance.

- -- Cheers Carlos E. R.

(from openSUSE 15.1 (Legolas))

-----BEGIN PGP SIGNATURE-----

iHoEARECADoWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCXlhZyxwccm9iaW4ubGlz dGFzQHRlbGVmb25pY2EubmV0AAoJELUzGBxtjUfVoSMAniRhtBCQgsuDacemnzns B+XfXxKGAKCXiktJJl6BpDkZUhYBBY0gFkFwOg== =Sjpg -----END PGP SIGNATURE-----

-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Sat, Feb 29, 2020 at 08:51:22AM -0800, Lew Wolfgang wrote:

On 02/27/2020 04:07 PM, Carlos E. R. wrote:

...

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

El 2020-02-20 a las 09:13 -0800, Lew Wolfgang escribió:

...

No, not apparmor.  I was  thinking of the Linux Auditing System:

https://www.networkworld.com/article/2224092/linux-auditing-101.html

But /var/log/audit/audit.log is written by AA.

I'm not sure that AA writes the audit.log.  The Audit Framework seems to be independent.

"TheLinux Audit framework https://github.com/linux-auditis a kernel feature (paired with userspace tools) that can log system calls. For example, opening a file, killing a process or creating a network connection. These audit logs can be used to monitor systems for suspicious activity."

Actually AppArmor uses the Linux audit framework log for its denial/approve events. Ciao, Marcus -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 29/02/2020 17.51, Lew Wolfgang wrote:

On 02/27/2020 04:07 PM, Carlos E. R. wrote:

...

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

El 2020-02-20 a las 09:13 -0800, Lew Wolfgang escribió:

...

No, not apparmor.  I was  thinking of the Linux Auditing System:

https://www.networkworld.com/article/2224092/linux-auditing-101.html

But /var/log/audit/audit.log is written by AA.

I'm not sure that AA writes the audit.log.  The Audit Framework seems to be independent.

It is confusing. Maybe I'm confusing the files. My current file there is not from AA.

"TheLinux Audit framework https://github.com/linux-auditis a kernel feature (paired with userspace tools) that can log system calls. For example, opening a file, killing a process or creating a network connection. These audit logs can be used to monitor systems for suspicious activity."

-- Cheers / Saludos, Carlos E. R. (from oS Leap 15.0 x86_64 (Minas Tirith))

On 01/03/2020 13.02, Anton Aylward wrote:

On 29/02/2020 11:51, Lew Wolfgang wrote:

...

I'm not sure that AA writes the audit.log.

I'm damn sure I don't write the audit log.

ROTFL! X'-) -- Cheers / Saludos, Carlos E. R. (from oS Leap 15.0 x86_64 (Minas Tirith))

Dave Howorth wrote:

...

...

Looking at /run/log/journal on a system that's been up for 28 days, I see about 8Mb used. On a customer system I manage, uptime 119 days, I see 200M in use.

I could imagine space becoming an issue on much smaller systems, raspi size. I have a single Raspi - uptime 19 days - but it doesn't even have a /rub/log/journal directory.

That's odd. Is there a /var/log/journal directory?

Yep, about 1.5Gb. More than I would have thought.

By default it writes in /run/log/journal unless /var/log/journal exists, in which case it writes there. I'd expect admins of servers to create /var/log/journal but apparently not all do.

We never do. I am also pretty certain I didn't create one on the raspi. -- Per Jessen, Zürich (7.0°C) http://www.cloudsuisse.com/ - your owncloud, hosted in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 18/02/2020 23.08, Per Jessen wrote:

Carlos E. R. wrote:

...

On 18/02/2020 19.28, Per Jessen wrote:

...

On a production system with lots of activity, uptime 89 days, I see /run/log/journal taking up 608Mb.

Try on a mail or news server, and it grows huge, or it rotates.

The above is a mailserver. It processes about 50000 messages per day.

I think the journal should be larger, or it has rotated. You can find out if the journal still holds the boot sequence. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)

On 19/02/2020 11.24, Per Jessen wrote:

Carlos E. R. wrote:

...

On 18/02/2020 23.08, Per Jessen wrote:

...

Carlos E. R. wrote:

...

On 18/02/2020 19.28, Per Jessen wrote:

...

On a production system with lots of activity, uptime 89 days, I see /run/log/journal taking up 608Mb.

Try on a mail or news server, and it grows huge, or it rotates.

The above is a mailserver. It processes about 50000 messages per day.

I think the journal should be larger, or it has rotated. You can find out if the journal still holds the boot sequence.

I think that is unlikely, from 89 days ago?

There can be thousand of mail related lines filling the log. I generate 3 megabytes per month in syslog, compressed, of those, and this is not a server. (and 4 of news) xz compresses a lot.

journalctl -b

first line (of 649773) is "-- Logs begin at Mon 2020-02-17 11:45:06 CET".

Anyway, I just wanted to say that the default settings (all commented out in journal.conf) seem to work well.

The original defaults produced gigabytes in my machines. I had to change them. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)

On Tuesday, 18 February 2020 14:27:04 GMT Anton Aylward wrote:

On 18/02/2020 04:08, Ianseeks wrote:

...

For ordinary lazy users like me who are not interested in or capable of system admin as a daily chore, should there not be the possibility of a section in Yast2 or Systemsettings where some standard user friendly housekeeping functions (e.g. flushing tmp folders, vacuuming journals etc) could be activated/configured to run at startup/shutdown rather than have to scour the net for solutions. For many like me, the computer should be doing more work with stuff that could be automated.

Have you looked at LOGROTATE(8) ?

There are a number of such systemd triggered functions that do housekeeping.

it is easy enough for a user to add login and logout scripts but yes, that depends on the shell being used. You can probably do better that use if you research what is capable with PAM.

For example mounting a file system (tmpfs) at login.

Thanks for all the info. I was looking for ways opensuse to hide all this (out of the box) from the non-IT users so they have a very high level question to answer rather than have to try and find out all the nuts and bolts of the system at this level.

> Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon?

-- opensuse:tumbleweed:20200214 Qt: 5.14.1 KDE Frameworks: 5.67.0 - KDE Plasma: 5.18.0 - kwin 5.18.0 kmail2 5.13.2 (19.12.2) - akonadiserver 5.13.2 (19.12.2) - Kernel: 5.5.2-1-default - xf86-video-nouveau: 1.0.15 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org