[opensuse] Housekeeping functions
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. 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? regards Ian -- 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
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'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? 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. 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. jdd -- http://dodin.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
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 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. -- Cheers / Saludos, Carlos E. R. (from openSUSE 15.1 (Legolas))
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 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. -- Cheers / Saludos, Carlos E. R. (from openSUSE 15.1 (Legolas))
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
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...) -- 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 18/02/2020 07:04, 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
Yes, that is why I consider the "One File System (to rules them all)" approach to be wrong headed. It is also why I consider BtrFS and snapshotting to be ill conceived for the sort of system you are describing,
ordinary lazy users like me who are not interested in or capable of system admin as a daily chore
Not only are there going to be 'home users' like yourself running Linux on a PC, but there are ISP that provide various levels of 'service accounts', that include virtual machines and shell accounts. Hopefully the ISP sysadmins to the daily/hourly admin there! But in doing so they are teaching any user who decides to try Linux at home bad habits, that of not doing daily admin. Well lets be realistic. How many of us here do daily admin? How many of us here have lots-a-lotsa shell script and cron entries to do the daily admin? There are good reasons to have partitions, to lock or lock out usage. Your example is a good one. Why is it the exhaustion of "/" that is the issue? Are you in "one file system" mode? Do you have a separate "/home" partition or is it just a subnet on the "one file system to rule them all" of the BtrFS that has taken over your disk? What about a "/tmp" FS? Yes there are risks with partitioning, you can fill those up too. But since I have a separate /home and a separate /usr/share a zypper that updates the manuals might fill the /usr/share but that won't affect my user space. Bill Murray (yes, THAT William M Murray!) once called my approach "deferred design". I hate the idea of imposing constraints when you don't know what the future demands will be, of 'pre provisioning. It is why I hate the file systems that preserve the 1970s model of having separate inode space and data space such as Ext4 and prefer ReiserFS and XFS. It is why I dislike partitioning and use LVM and can resize a partition (grow AND shrink) that has ReiserFS on it while the system is running an application that uses that partition and file system, without shutting down. I've been 'gainfully employed' as a sysadmin a number of times in my life and quit apart from hating it 'cos it never paid enough, I was obsessionally good at it because I hated it so much I created lots of scripts and 'automation' toe relieve me of the work and documented things obsessively. There's an inherent difference between Linux and Windows: with Linux we script things; with windows you buy 3rd party tools to do things. -- 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 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 Tuesday, 18 February 2020 19:22:01 GMT David C. Rankin wrote:
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?
I think it should be down to the individual display manager as they may all fail in different ways when "/" is full
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...
-- 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 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 18/02/2020 05:38, Ianseeks wrote:
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 thought there was a function that aged out the /tmp FS. Of course you could creates a RAMFS that evaporates on logout asnd set the environment variable TMP to point to it. I don't know if all programms will honour that, though. Let's see, what do I have mounted: tmpfs on /run/user/anton type tmpfs (rw,nosuid,nodev,relatime,size=800292k,mode=700,uid=anton,gid=anton) # ls /run/user/anton KSMserver__0 dbus-1 gnupg kdeinit5__0 klauncherKvmFcX.1.slave-socket systemd bus dconf gvfs keyring pulse Good heavens! Of course you system may use userID instead of username. -- 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
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 ? A status page in YaST sounds like a neat idea, OTOH it might be overkill when the average user does not want ot know?
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. -- Per Jessen, Zürich (7.8°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
Per Jessen wrote:
Ianseeks wrote:
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.
It might be useful if zupper checked this before a 'dup'. It *is* however very difficult, especially for a btrfs system. I just did a DUP that I had delayed for quite some time (well, 2 weeks or so). Free space before dup: ~13GB. Needed Download: 2.5GB. Claimed additional space needed: 170MB. Available space after install: 2GB. So in principle you'd have to make sure that the *full* installed size for all packages that are going to be installed is available before starting. I assume the difference count (those 170MB above) are computed from the 'installed size' metainfo? If so it might be helpful (to some at least) if zypper would also report the total to-be-installed size before starting. I at least would definitely appreciate it :) -- 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
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). 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 -- 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 <pit@astro.su.se> 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 12.26, Dave Howorth wrote:
On Tue, 18 Feb 2020 12:08:59 +0100 Peter Suetterlin <pit@astro.su.se> 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). -- Cheers / Saludos, Carlos E. R. (from openSUSE 15.1 (Legolas))
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
Anton Aylward wrote:
I don't recall. Do programs honour the setting of the environment variable TMP?
Many do, yes. I think some may also look at TMPDIR and TEMP. SOme also have their own temp setting. -- Per Jessen, Zürich (8.2°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 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 18/02/2020 16.29, Anton Aylward wrote:
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?
I did not say anything about that variable; I odn't know if it is honoured or not (I assume it is). What I said is that the systemd assumption is that you create a ramdisk mounted on /tmp, which of course gets "deleted" on poweroff. -- Cheers / Saludos, Carlos E. R. (from openSUSE 15.1 (Legolas))
On Tue, 18 Feb 2020 12:37:37 +0100 "Carlos E. R." <robin.listas@telefonica.net> wrote:
On 18/02/2020 12.26, Dave Howorth wrote:
On Tue, 18 Feb 2020 12:08:59 +0100 Peter Suetterlin <pit@astro.su.se> 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
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. -- 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
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 18/02/2020 18.11, Dave Howorth wrote:
On Tue, 18 Feb 2020 12:37:37 +0100 "Carlos E. R." <robin.listas@telefonica.net> wrote:
On 18/02/2020 12.26, Dave Howorth wrote:
On Tue, 18 Feb 2020 12:08:59 +0100 Peter Suetterlin <pit@astro.su.se> 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.
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. -- Cheers / Saludos, Carlos E. R. (from openSUSE 15.1 (Legolas))
On Tue, 18 Feb 2020 19:29:05 +0100 "Carlos E. R." <robin.listas@gmx.es> wrote:
On 18/02/2020 18.11, Dave Howorth wrote:
On Tue, 18 Feb 2020 12:37:37 +0100 "Carlos E. R." <robin.listas@telefonica.net> wrote:
On 18/02/2020 12.26, Dave Howorth wrote:
On Tue, 18 Feb 2020 12:08:59 +0100 Peter Suetterlin <pit@astro.su.se> 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 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.
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. 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 There was a blog: http://jaegerandi.blogspot.de/2012/03/tmp-as-tmpfs-for-opensuse.html Now it asks for password.
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 -- Cheers / Saludos, Carlos E. R. (from openSUSE 15.1 (Legolas))
On Tue, 18 Feb 2020 21:58:33 +0100 "Carlos E. R." <robin.listas@telefonica.net> 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 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.
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. Example: vmware saves *logs* to /tmp/vmware-root
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. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
On Wed, 19 Feb 2020 14:19:11 +0100 "Carlos E. R." <robin.listas@telefonica.net> 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
On 19/02/2020 21.38, Dave Howorth wrote:
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.
It does on download, not on view.
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!
Oh, I don't need to. openSUSE doesn't clear /tmp on boot, so nothing to do.
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.
We asked and got it :-D
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.
I can see the logs in my /tmp directory... Maybe not all, but it is a fact I have logs there.
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.
I'm sorry, but that's the information I have. Anyway, according to the interpretation of FHS by Peter Suetterlin deleting /tmp at boot is optional (but reccomended), not mandatory. -- Cheers / Saludos, Carlos E. R. (from openSUSE 15.1 (Legolas))
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 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 ... -- /"\ \ / 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 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 Wed, 19 Feb 2020 11:20:18 +0100 "Carlos E.R." <robin.listas@gmx.es> 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!
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.
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".
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 19/02/2020 12.45, Dave Howorth wrote:
On Wed, 19 Feb 2020 11:20:18 +0100 "Carlos E.R." <robin.listas@gmx.es> 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 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 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. 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 -- 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 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))
Dave Howorth wrote:
On Tue, 18 Feb 2020 12:37:37 +0100 "Carlos E. R." <robin.listas@telefonica.net> wrote:
On 18/02/2020 12.26, Dave Howorth wrote:
On Tue, 18 Feb 2020 12:08:59 +0100 Peter Suetterlin <pit@astro.su.se> 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.
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. -- Per Jessen, Zürich (6.2°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 Tue, 18 Feb 2020 19:54:52 +0100 Per Jessen <per@computer.org> wrote:
Dave Howorth wrote:
On Tue, 18 Feb 2020 12:37:37 +0100 "Carlos E. R." <robin.listas@telefonica.net> wrote:
On 18/02/2020 12.26, Dave Howorth wrote:
On Tue, 18 Feb 2020 12:08:59 +0100 Peter Suetterlin <pit@astro.su.se> 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
On 18/02/2020 21.45, Dave Howorth wrote:
On Tue, 18 Feb 2020 19:54:52 +0100 Per Jessen <per@computer.org> 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?
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?
Just grab the old scripts from prior to systemd implementation. Me, I might run a find and delete anything created prior to the current boot time. But run it before any session starts (there is a hook in /etc/init.d/ just ready), because some applications create permanent directories there. -- Cheers / Saludos, Carlos E. R. (from openSUSE 15.1 (Legolas))
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
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. 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. I would place there a find to delete 6 month old files - unless typical uptime is 6 months, then I would choose a longer time or include the typical uptime as a value somehow.
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?
Doing it at the correct instant? Because you may delete temporary files from a running process. Deleting it at all on every boot? I do not see why.
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.
right. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
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
On 19/02/2020 12.05, Per Jessen wrote:
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.
Possible, yes.
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.
But if created, they are used. When I
created them both, I could still only see 'after.local' with systemctl status ??
boot.local runs before any service, so it is not listed. Perhaps.
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 would use an "echo date" inside the scripts. If confirmed, it is a bug. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
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
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? -- Cheers / Saludos, Carlos E. R. (from openSUSE 15.1 (Legolas))
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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2020-02-19 a las 12:05 +0100, Per Jessen escribió:
Carlos E. R. wrote:
On 18/02/2020 23.17, Per Jessen wrote:
Dave Howorth wrote:
...
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_ ?
I created both scripts in this laptop: cer@Legolas:~> cat /etc/init.d/boot.local #!/bin/bash LOGGER=/usr/bin/logger FACILIDAD=user.info TAG=boot-local DATE=`date --iso=ns` $LOGGER -t $TAG -p $FACILIDAD "Inside boot.local ($DATE)" echo "Inside boot.local - $DATE" >> /tmp/logtest.log cer@Legolas:~> I also have a service that runs as early as possible: cer@Legolas:~> cat /etc/systemd/system/boot-marker.service [Unit] Description=Write boot markers in /var/log/messages Before=syslog.service [Service] Type=oneshot RemainAfterExit=true ExecStart=-/root/ThingsNeededForBoot/write-boot-marker start ExecStop=-/root/ThingsNeededForBoot/write-boot-marker stop [Install] WantedBy=multi-user.target cer@Legolas:~> And that script does: Legolas:~ # cat /root/ThingsNeededForBoot/write-boot-marker #!/bin/sh #Used from /etc/systemd/system/boot-marker.service . /root/ThingsNeededForBoot/MyScriptDefinitions case "$1" in start ) # syslog is not working DATE=`date --iso=ns` UNAME=`uname -a` echo >> $REGISTROdeSESIONES echo "$DATE - Booting the system now ================================================================================ $UNAME" | tee -a /var/log/warn -a $REGISTROdeSESIONES >> /var/log/messages ;; stop ) DATE=`date --iso=ns` UPTIME=`uptime` echo "$DATE - Halting the system now =========================================== uptime: $UPTIME" | tee -a /var/log/warn -a $REGISTROdeSESIONES >> /var/log/messages ;; esac # install using: # systemctl enable /etc/systemd/system/boot-marker.service Legolas:~ # Well, I get these times (/tmp/logtest.log): Inside boot.local - 2020-02-28T00:03:20,565128087+01:00 Inside after.local - 2020-02-28T00:03:29,360611962+01:00 Or in the /var/log/messages files: 2020-02-28T00:03:20,549439862+01:00 - Booting the system now ================================================================================ Linux Legolas 4.12.14-lp151.28.36-default #1 SMP Fri Dec 6 13:50:27 UTC 2019 (8f4a495) x86_64 x86_64 x86_64 GNU/Linux <1.6> 2020-02-28 00:03:21 Legolas boot-local - - - Inside boot.local (2020-02-28T00:03:20,565128087+01:00) <1.6> 2020-02-28 00:03:29 Legolas after-local - - - Inside after.local (2020-02-28T00:03:29,360611962+01:00) So the service script runs 2 centiseconds before boot.local :-) Then 9 seconds later, after.local runs. (and they only run once here) It seems syslog prints the lines about half a second later. I can increase the precission of syslog timestamps and try again. - -- Cheers Carlos E. R. (from openSUSE 15.1 (Legolas)) -----BEGIN PGP SIGNATURE----- iHoEARECADoWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCXlhY2Rwccm9iaW4ubGlz dGFzQHRlbGVmb25pY2EubmV0AAoJELUzGBxtjUfVxyoAoI4nhW3wifrV20kIN+rI zpyDUCqfAJ9ajeOjRxcBdFdNGhaJIdSSznjdFA== =OLXJ -----END PGP SIGNATURE-----
On Tue, 18 Feb 2020 23:17:35 +0100 Per Jessen <per@computer.org> 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
Dave Howorth wrote:
On Tue, 18 Feb 2020 23:17:35 +0100 Per Jessen <per@computer.org> wrote:
Dave Howorth wrote:
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.
As Carlos mentioned, it is probably wise to add '-mtime +N' to only delete older stuff, e.g. a week old. That also gets you around the issue of when it is run. @reboot jobs are run as soon as cronie is started. @reboot root find /tmp/ -mtime +7 | xargs -r rm -Rf OTOH, if you rarely boot, setting up the systemd temp cleaner is probably a better idea. -- Per Jessen, Zürich (5.6°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 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 Wed, 19 Feb 2020 14:35:07 +0100 "Carlos E. R." <robin.listas@telefonica.net> 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. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
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))
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. -- Per Jessen, Zürich (4.2°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 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)
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 []: 2020-02-20T11:15:04.466397+01:00 office24 root[409]: blah.boot [boot.local] 2020-02-20T11:15:04.468679+01:00 office24 systemd[1]: Starting blah... [service unit] 2020-02-20T11:15:04.468733+01:00 office24 root[530]: blah.after [after.local] 2020-02-20T11:15:04.468793+01:00 office24 root[532]: blahblah [service unit] 2020-02-20T11:15:04.468863+01:00 office24 root[560]: blah.boot [boot.local] 2020-02-20T11:15:04.471635+01:00 office24 systemd[1]: Started blah. [service unit done]. -- Per Jessen, Zürich (12.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
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 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. Yes it is "declarative" programming rather than "procedural" programming, but so what? well, OK, I'm also comfortable with the declarative forms of such things as RubyOnRails ... -- 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 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))
* Carlos E. R. <robin.listas@telefonica.net> [02-20-20 13:09]:
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.
I don't believe the "boot.local", "after..." "..." are now functional. At least not in Tw. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
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
Patrick Shanahan wrote:
* Carlos E. R. <robin.listas@telefonica.net> [02-20-20 13:09]:
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.
I don't believe the "boot.local", "after..." "..." are now functional. At least not in Tw.
They are fine in TW - that's where I did my testing. They don't exist in /etc/init.d to begin with, that's all. -- Per Jessen, Zürich (4.1°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 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Content-ID: <alpine.LSU.2.21.2002280027420.2988@Legolas.valinor> El 2020-02-20 a las 15:56 -0500, Anton Aylward escribió:
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.
Well, see "PGNet Dev". It is an integral part of systemd.
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.
Who cares! :-P - -- Cheers Carlos E. R. (from openSUSE 15.1 (Legolas)) -----BEGIN PGP SIGNATURE----- iHoEARECADoWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCXlhQpRwccm9iaW4ubGlz dGFzQHRlbGVmb25pY2EubmV0AAoJELUzGBxtjUfVKQIAnirG7GPyp+b4zqARklAJ tjIVkvmmAJ9WZsdcouU4K1rI1LOjkznKqJ51bQ== =IVB6 -----END PGP SIGNATURE-----
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 Wed, 19 Feb 2020 14:34:38 -0500 Anton Aylward <opensuse@antonaylward.com> wrote:
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.
Err, they do don't they? https://askubuntu.com/questions/19984/how-do-you-change-thunderbird-temporar... As you may remember (AYMR?) I use claws instead of the dross that is TB. ;P -- 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." <robin.listas@telefonica.net> wrote:
On 18/02/2020 12.26, Dave Howorth wrote:
On Tue, 18 Feb 2020 12:08:59 +0100 Peter Suetterlin <pit@astro.su.se> 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
On 19/02/2020 10.31, Ianseeks wrote:
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:
...
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
And here is where I say that the pre-systemd job did that. It had the choice. Me plain user always said "no". Just in case. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
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 Tuesday, 18 February 2020 11:26:04 GMT Dave Howorth wrote:
On Tue, 18 Feb 2020 12:08:59 +0100 Peter Suetterlin <pit@astro.su.se> 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.**" I would have thought that should really be enforced and perhaps a housekeeping setting in Yast/systemsettings to change it.
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.
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" -- 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.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 <pit@astro.su.se> 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))
On Tuesday, 18 February 2020 12:16:24 GMT Carlos E. R. wrote:
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 <pit@astro.su.se> 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
ok, thanks. just searched that out as 10% of underlying file system. I thought he was referencing a setting the conf -- 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
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 18/02/2020 13.45, Per Jessen wrote:
Ianseeks wrote:
On Tuesday, 18 February 2020 10:01:09 GMT Per Jessen 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 feel pretty certain there is an automatic tmp-cleaner - yes, see
systemctl status systemd-tmpfiles-clean
Those defined in /usr/lib/tmpfiles.d/ cer@Legolas:~> cat /usr/lib/tmpfiles.d/tmp.conf # 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. # See tmpfiles.d(5) for details # 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 - cer@Legolas:~> So, they are not cleaned. -- Cheers / Saludos, Carlos E. R. (from openSUSE 15.1 (Legolas))
On Tue, 18 Feb 2020 13:45:24 +0100 Per Jessen <per@computer.org> 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
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. -- Per Jessen, Zürich (6.7°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 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 Tue, 18 Feb 2020 19:33:56 +0100 "Carlos E. R." <robin.listas@gmx.es> wrote:
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.
Yes, ditto.
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?
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. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
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 Tue, 18 Feb 2020 21:23:07 +0100 "Carlos E. R." <robin.listas@telefonica.net> 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? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 18/02/2020 21.47, Dave Howorth wrote:
On Tue, 18 Feb 2020 21:23:07 +0100 "Carlos E. R." <robin.listas@telefonica.net> 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 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." <robin.listas@telefonica.net> 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. From a security stand point, should you allow editing of log files? I thought that was one way how people hid their intrusions
Are you sure you will be able to read a 5 year old journal on a different machine?
-- 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 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 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? Regards, Lew -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
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 Wed, 19 Feb 2020 11:38:25 -0800 Lew Wolfgang <wolfgang@sweet-haven.com> 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 :)
Regards, Lew
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 02/19/2020 12:51 PM, Dave Howorth wrote:
On Wed, 19 Feb 2020 11:38:25 -0800 Lew Wolfgang <wolfgang@sweet-haven.com> 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 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 <wolfgang@sweet-haven.com> 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. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
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 <wolfgang@sweet-haven.com> 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
-----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 <wolfgang@sweet-haven.com> 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.
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-----
On Fri, 28 Feb 2020 01:07:39 +0100 (CET) "Carlos E. R." <robin.listas@telefonica.net> 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 <wolfgang@sweet-haven.com> 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 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-audit>is 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." Regards, Lew -- 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-audit>is 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.52, Marcus Meissner wrote:
On Sat, Feb 29, 2020 at 08:51:22AM -0800, Lew Wolfgang wrote:
On 02/27/2020 04:07 PM, Carlos E. R. wrote:
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-audit>is 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.
Ah! Now I understand. Thanks. So if audit is not running, that log seems to come entirely from AA, which is why I was confused. -- Cheers / Saludos, Carlos E. R. (from oS Leap 15.0 x86_64 (Minas Tirith))
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-audit>is 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 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. -- 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 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))
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?
IBM RACF will help you, no problem. -- Per Jessen, Zürich (5.1°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
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
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. -- Per Jessen, Zürich (6.9°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 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)
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? 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. -- Per Jessen, Zürich (7.3°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 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 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. -- 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 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
On 18/02/2020 10:55, Ianseeks wrote:
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.
And admirable desire, ne we would all wish for. The problem is that Linux is not a 'one size fits a;;' or a system where "parents know best". If you want a no-maintenance' system go with the most basic 'closed box'. Even home grade Windows ha got to the point where it takes some techncial know how. I'm told that Apple still has systems that don't need (much) user know-how, but that too may be changing. Heck, users ARE more sophisticated now. In 1975 I do 't think users could have managed a mouse! When did the multi-button mouse first become available? (My mouse has 8 buttons and a 2-d scroll wheel) -- 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
participants (15)
-
Anton Aylward -
Carlos E. R. -
Carlos E. R. -
Carlos E.R.
-
Dave Howorth -
David C. Rankin -
Ianseeks -
jdd＠dodin.org -
Lew Wolfgang -
Marcus Meissner -
Michael Hamilton -
Patrick Shanahan -
Per Jessen -
Peter Suetterlin -
PGNet Dev