On 2016-09-19 10:43, sdm wrote:

On 09/18/2016 03:27 PM, Carlos E. R. wrote:

...

Yes, you should.

Set limits. For example:

SystemMaxUse=100M RuntimeMaxUse=30M

On my TW box when looking in journald.conf, #Storage=auto is commented out by default like so. From the journald.conf man page: | Storage=|

Controls where to store journal data. One of "|volatile|", "|persistent|", "|auto|" and "|none|". If "|volatile|", journal log data will be stored only in memory, i.e. below the |/run/log/journal| hierarchy (which is created if needed). If "|persistent|", data will be stored preferably on disk, i.e. below the |/var/log/journal| hierarchy (which is created if needed), with a fallback to |/run/log/journal| (which is created if needed), during early boot and if the disk is not writable. "|auto|" is similar to "|persistent|" but the directory |/var/log/journal| is not created if needed, so that its existence controls where log data goes. "|none|" turns off all storage, all log data received will be dropped. Forwarding to other targets, such as the console, the kernel log buffer, or a syslog socket will still work however. Defaults to "|auto|".

Since by default it's set to "auto" yet that is commented out, it looks like the logs are going into /run/log/journal which is the fallback directory for "persistent" as /var/log/journal doesn't exist on my TW box. So the default setting for TW appears to be volatile, meaning the logs disappear if you reboot the system. Is this correct? Leap was the same way last I checked, so if a user is having their journal file baloon in size the must have at one point changed the defaults in journald.conf (I'm guessing). I don't know if 13.1 and 13.2 have the same defaults for the journal as 42.1 & TW.

The problem is that /run is a tmpfs, stored in RAM. So, if you have a journal of 2 GB in /run/log/journal you do have a problem, because 2 GB of RAM are wasted. You have two solutions out of it: dump to persistent log in /var/log/, or limit the size of the log as I told you and you can see above in the quotes. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

On 2016-09-19 12:41, Per Jessen wrote:

Carlos E. R. wrote:

...

The problem is that /run is a tmpfs, stored in RAM. So, if you have a journal of 2 GB in /run/log/journal you do have a problem, because 2 GB of RAM are wasted.

Isn't it swapped out anyway? (just wondering).

Unclear. I do not know how to find out how much is swapped, if any. And if swapped, just query the log and goes back to ram. I limited my journal mem usage, because I prefer having that memory available to applications, and instead have the logs in syslog. The problem with journal, or one problem, is that you can not purge it by filter. Ie, say, erase from the journal all nntp entries, or all mail entries, and have them all dumped to file instead (ie, syslog). That's the typical reason the journal grows so big, that you have some type of event that fills it. Think mail server, news server. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

On 2016-09-19 14:05, Per Jessen wrote:

Carlos E. R. wrote:

...

On 2016-09-19 12:41, Per Jessen wrote:

...

Carlos E. R. wrote:

...

The problem is that /run is a tmpfs, stored in RAM. So, if you have a journal of 2 GB in /run/log/journal you do have a problem, because 2 GB of RAM are wasted.

Isn't it swapped out anyway? (just wondering).

Unclear. I do not know how to find out how much is swapped, if any.

According to https://www.kernel.org/doc/Documentation/filesystems/tmpfs.txt

"tmpfs lives completely in the page cache and on swap,"

Page cache is RAM.

...

And if swapped, just query the log and goes back to ram.

Yes, but still doesn't "waste" any RAM.

"Using" RAM for the logs is wasting it, IMO. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

On 2016-09-19 14:12, Richard Brown wrote:

On 19 September 2016 at 10:43, sdm <> wrote:

...

Since by default it's set to "auto" yet that is commented out, it looks like the logs are going into /run/log/journal which is the fallback directory for "persistent" as /var/log/journal doesn't exist on my TW box. So the default setting for TW appears to be volatile, meaning the logs disappear if you reboot the system. Is this correct? Leap was the same way last I checked, so if a user is having their journal file baloon in size the must have at one point changed the defaults in journald.conf (I'm guessing). I don't know if 13.1 and 13.2 have the same defaults for the journal as 42.1 & TW.

/var/log/journal exists on my TW boxes

But the OP did not say he is using TW. That was 'sdm', another poster.

And is persistant storage on my system

My question for the OP though is on what kind of system is a 2GB log a problem?

He must have a small disk, or a small root partition.

Why is the journal being blamed? a 2GB /var/log/messages or any other 2GB file in /var/log would have the same negative impact

Well, the journal is blamed because (apparently) he has journal and not syslog ;-) That is the default, anyway.

At least journald can be configured to autoclean upafter itself, or manually cleaned using the journalctl --vacuum-size or --vacuum-time commands

Yes, but you can define size limits and this will happen automatically when needed.

The title of this thread could just as easily be "my root filesystem is too small"

Yep. That too. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

On 2016-09-19 14:40, Dutch Ingraham wrote:

On Mon, Sep 19, 2016 at 02:12:18PM +0200, Richard Brown wrote:

...

My question for the OP though is on what kind of system is a 2GB log a problem?

I'm a little confused. My question for you is: on what kind of system is 2 GIGAbytes of logs necessary or desirable?

For example, on my daily driver, a Fedora system that uses the journal, and on which I have taken no explicit action to limit the size of any log, my entire /var/log directory amounts to 241 megabytes. On a 3 year-old Gentoo system without the journal, and on which I have taken no action to limit the size of any file, the entire /var/log directory is 79 megabytes.

I assume that those distributions have "logrotate" enabled, same as openSUSE does, and for many years. That's why traditional syslog size is limited. The mechanism has been well adjusted over the years. The defaults for the journal, though, allow it to grow big in some circumstances. There are adjustments, but different, and IMO, less grained. They need years for the adjustments to develop properly :-) -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

Richard Brown wrote:

My question for the OP though is on what kind of system is a 2GB log a problem?

He didn't say it had filled all partitions on his disk. The question you should be asking is what size partition is using up 2GB space a problem. 2GB would be > 25% of my 'var' partion (currently using 2.5G out of 7.8G). So 2GB wouldn't be a problem if it was trimmed. However, if the journal behavior is to fill until full and only trim then, that could be problematic on any file-system. My boot partition is "only" 908M, but then it wasn't designed to hold logfiles.

The title of this thread could just as easily be "my root filesystem is too small"

My logs are set to trim @ 4M, but they are separate logs/function. A log that has grown to 2GB would be indication of abnormal behavior on my system. A 2GB catch-all log would also be a binary-blob, unuseful to monitor day-to-day problems. Right now, my largest log is my lastlog @ 19M, which covers logins going back to aug-24 -- which was when I think I fixed it: lindaw pts/4 athenae Mon Sep 19 07:45 still logged in root tty1 Thu Sep 15 19:54 - 07:45 (3+11:51) ... lindaw pts/0 athenae Fri Aug 26 16:38 - 01:09 (08:31) reboot system boot 4.7.1-Isht-Van Fri Aug 26 16:35 - 22:47 (15+06:11) ... wtmp begins Wed Aug 24 10:57:47 2016 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 09/19/2016 01:20 PM, Linda Walsh wrote:

However, if the journal behavior is to fill until full and only trim then, that could be problematic on any file-system.

It shouldn't fill up unless the user ran a server without a reboot, when the default limits for journald.conf on Leap 42.1 are commented out: SystemMaxUse=100M RuntimeMaxUse=30M That is why I was asking if George did an upgrade from 13.2, where as I previously wrote, that journald.conf file may have been carried over from 13.2, which appears to have the "persistent" default set and not commentedout. It appears users on different systems, clean install or not, are getting different behaviours and different defaults, and different results. For instance, Richard says the logs are not volatile on a clean Leap 42.1 box. For me they were. Everytime I rebooted Leap 42.1, the logs were trashed. And there's no disputing that. That is what happened, end of story. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 09/19/2016 08:12 PM, Richard Brown wrote:

On 19 September 2016 at 10:43, sdm wrote:

...

On my TW box when looking in journald.conf, #Storage=auto is commented out by default like so. From the journald.conf man page: | Storage=|

Controls where to store journal data. One of "|volatile|", "|persistent|", "|auto|" and "|none|". If "|volatile|", journal log data will be stored only in memory, i.e. below the |/run/log/journal| hierarchy (which is created if needed). If "|persistent|", data will be stored preferably on disk, i.e. below the |/var/log/journal| hierarchy (which is created if needed), with a fallback to |/run/log/journal| (which is created if needed), during early boot and if the disk is not writable. "|auto|" is similar to "|persistent|" but the directory |/var/log/journal| is not created if needed, so that its existence controls where log data goes. "|none|" turns off all storage, all log data received will be dropped. Forwarding to other targets, such as the console, the kernel log buffer, or a syslog socket will still work however. Defaults to "|auto|".

Since by default it's set to "auto" yet that is commented out, it looks like the logs are going into /run/log/journal which is the fallback directory for "persistent" as /var/log/journal doesn't exist on my TW box. So the default setting for TW appears to be volatile, meaning the logs disappear if you reboot the system. Is this correct? Leap was the same way last I checked, so if a user is having their journal file baloon in size the must have at one point changed the defaults in journald.conf (I'm guessing). I don't know if 13.1 and 13.2 have the same defaults for the journal as 42.1 & TW.

/var/log/journal exists on my TW boxes

And is persistant storage on my system

My question for the OP though is on what kind of system is a 2GB log a problem?

Why is the journal being blamed? a 2GB /var/log/messages or any other 2GB file in /var/log would have the same negative impact

At least journald can be configured to autoclean upafter itself, or manually cleaned using the journalctl --vacuum-size or --vacuum-time commands

The title of this thread could just as easily be "my root filesystem is too small"

Yes, that is a good point. My root file system is only 20GB, and I have been thinking about making it bigger. I need to take some time to do that, and will have to partition some other drives differently than I currently have them partitioned. However, as Carlos was saying earlier, having it that big apparently ends up using quite a bit of RAM un-necessarily. I have always been told that 20GB should be plenty big for a root file system. It seems that the journal was the main component. I set the limit to 300M, quite a bit bigger than the example recommends, and it gave me enough room to run my kernel update. The confusing thing now is that my journal file is quite a bit smaller - it says 345M at the moment - but when I made that change and rebooted, I cleared about a total of 4GB of use off my root system. Before I limited the size, when I ran du -d -1 -h -x on the root system, it had a total of 19G used. Now it has a total of 15G used. -- George Box: 42.1 | KDE Plasma 5 | AMD Phenom IIX4 | 64 | 32GB Laptop #1: 42.1 | Plasma 5.4.7, Qt 5.7.0 | Core i7-4710HQ | 64 | 16GB Laptop #2: 42.1 | KDE Plasma 5 | Core i5 | 64 | 8GB -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Le 20/09/2016 à 08:55, Per Jessen a écrit :

George from the tribe wrote:

...

Yes, that is a good point. My root file system is only 20GB, and I

On my Leap421, a typical office system, I have 40Gb for root, of which 6Gb is in use after a default install. On my Leap422, a smallish office system, I have only 10Gb for root, of which 5.3Gb is in use after a default install. I would have thought 20Gb should be fine, but it obviously depends on what you install. (I am assuming a separate partition for /home).

and of the file system tha default BTRFS may need up to 100 Gb with smapshots, for ext4 20 Gb is enough (42.1, dunnon for 42.2) jdd -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

George from the tribe composed on 2016-09-20 14:07 (UTC+0800):

Richard Brown wrote:

...

The title of this thread could just as easily be "my root filesystem is too small"

Yes, that is a good point. My root file system is only 20GB, and I have been thinking about making it bigger. I need to take some time to do that, and will have to partition some other drives differently than I currently have them partitioned.

I often used to wonder (before btrfs became default / filesystem), why recommended / size is as large as it is. Mine (ext4): /dev/md4 18011336 6802504 10270856 40% / On this my 24/7 dekstop/LAN server with KDE3 as the only non-essential DE, I have only /tmp, /home, /srv and /usr/local as separate standard directories located on separate filesystems. /var/log/journal* is a quite a bit of that total, 1122344 blocks. journald.conf seems to be just as it came from its rpm in June. My 64 bit test installations are mostly on 5.6G partitions with only /home, /srv and /usr/local separated.

However, as Carlos was saying earlier, having it that big apparently ends up using quite a bit of RAM un-necessarily.

A big / filesystem with a lot of unneeded packages installed takes a lot of extra time and bandwidth to install, update, backup, restore, and rpm/zypp database search. Impact on RAM I can't see. Of 16G installed, typically well under half is committed including disk cache. Right now with 6 days' uptime, 51.8% is in "use", of which 28% is disk cache.

I have always been told that 20GB should be plenty big for a root file system. It seems that the journal was the main component. I set the limit to 300M, quite a bit bigger than the example recommends, and it gave me enough room to run my kernel update.

The confusing thing now is that my journal file is quite a bit smaller - it says 345M at the moment - but when I made that change and rebooted, I cleared about a total of 4GB of use off my root system. Before I limited the size, when I ran du -d -1 -h -x on the root system, it had a total of 19G used. Now it has a total of 15G used.

# du -d 1 -h -x / | sort 1.1G /lib 1.6G /var 138M /boot 16K /lost+found 18M /lib64 22M /etc 3.2G /usr 386M /opt 4.0K /media 4.0K /mnt 4.0K /selinux 4.7M /bin 4.9M /sbin 6.5G / 95M /root # du -s -x / 6757360 / -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2016-09-20 08:07, George from the tribe wrote:

However, as Carlos was saying earlier, having it that big apparently ends up using quite a bit of RAM un-necessarily.

No, that is not what I said, or what I meant. The journal is initially stored only on RAM, or to be precise, in a filesystem that exists only in RAM and Swap, under /run/log/journal/. That is my case. When you have the /var/log/journal/ directory, the journal is stored there exclusively. That is your case. No RAM.

I have always been told that 20GB should be plenty big for a root file system.

Depends on what you install :-) And also if it is btrfs. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

On 2016-09-19 14:17, Per Jessen wrote:

sdm wrote:

...

Since by default it's set to "auto" yet that is commented out, it looks like the logs are going into /run/log/journal which is the fallback directory for "persistent" as /var/log/journal doesn't exist on my TW box. So the default setting for TW appears to be volatile, meaning the logs disappear if you reboot the system. Is this correct? Leap was the same way last I checked,

Yes, neither Leap421 nor 422 have a /var/log/journal in the default install.

...

so if a user is having their journal file baloon in size the must have at one point changed the defaults in journald.conf (I'm guessing).

I guess one could install Leap by upgrading from 13.x ?

Just by creating the empty directory /var/log/journal/, it is used and you get persistent journal. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

On 2016-09-19 19:23, Per Jessen wrote:

Carlos E. R. wrote:

...

Just by creating the empty directory /var/log/journal/, it is used and you get persistent journal.

Yes, I am aware of that, but surely someone who did that would also be aware, so no need to ask here.

I think there is an rpm that creates the directory, too. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

On 2016-09-19 21:48, Richard Brown wrote:

On 19 September 2016 at 20:10, Carlos E. R. wrote:

...

On 2016-09-19 19:23, Per Jessen wrote:

...

Carlos E. R. wrote:

...

...

Just by creating the empty directory /var/log/journal/, it is used and you get persistent journal.

Yes, I am aware of that, but surely someone who did that would also be aware, so no need to ask here.

I think there is an rpm that creates the directory, too.

/var/log/journal is owned by the systemd-logger package on each and every one of my Tumbleweed and Leap machines

The Leap machine was a fresh install of Leap 42.1 All but one of the Tumbleweed machines was a fresh install, the remaining one being an upgrade since god knows when

All of them have an /etc/systemd/journal.conf that is fully commented out

All of them do not have volatile logs

Yes, that's correct. With the default setting of "storage=auto", and an rpm that creates the /var/log/journal/, you get a persistent journal. Neat. It may be that some people do not have the package systemd-logger installed, though. Thus the differences. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

sdm wrote:

...

Since by default it's set to "auto" yet that is commented out, it looks like the logs are going into /run/log/journal which is the fallback directory for "persistent" as /var/log/journal doesn't exist on my TW box. So the default setting for TW appears to be volatile, meaning the logs disappear if you reboot the system. Is this correct? Leap was the same way last I checked, Yes, neither Leap421 nor 422 have a /var/log/journal in the default install. My Leap 42.1 does have /var/log/journal, and it was a clean install, including a freshly formatted partition. I certainly did not create the

Per Jessen wrote: directory, though I did cause /var/log to be created (I always put that on its own partition, a practice I picked up long ago to keep log files from using up space needed for other things -- back then I had more important things to do than to learn how to tweak log file sizes/retention etc ;) ) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Per Jessen wrote:

Darryl Gregorash wrote:

...

...

sdm wrote:

...

Since by default it's set to "auto" yet that is commented out, it looks like the logs are going into /run/log/journal which is the fallback directory for "persistent" as /var/log/journal doesn't exist on my TW box. So the default setting for TW appears to be volatile, meaning the logs disappear if you reboot the system. Is this correct? Leap was the same way last I checked, Yes, neither Leap421 nor 422 have a /var/log/journal in the default install. My Leap 42.1 does have /var/log/journal, and it was a clean install, including a freshly formatted partition. I certainly did not create

Per Jessen wrote: the directory, though I did cause /var/log to be created (I always put that on its own partition, a practice I picked up long ago to keep log files from using up space needed for other things -- back then I had more important things to do than to learn how to tweak log file sizes/retention etc ;) )

Interesting. I have two vanilla Leap42x+KDE systems, one of each, and neither has a /var/log/journal.

I wonder if "rpm -qf /var/log/journal" will say someting useful. -- Per Jessen, Zürich (15.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

Peter Ragosch wrote:

Am Mon, 19 Sep 2016 17:28:52 +0200 schrieb Per Jessen :

...

rpm -qf /var/log/journal

On Leap 42.1, dist-upgrade from 13.2,:

raven:~ # rpm -qf /var/log/journal file /var/log/journal is not owned by any package

Yeah, that's what I suspected.

raven:~ # cat /etc/./systemd/journald.conf # /etc/systemd/journald.conf # Generated by kcmsystemd control module v.0.7.0.

On my Leap421, that file only contains comments and is from systemd-210-95.1 -- Per Jessen, Zürich (14.8°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 09/19/2016 10:42 AM, sdm wrote:

By the way I don't know by verticle bars "|" were inserted in that email, that isn't the way I typed it. I have to check my tbird settings... -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Carlos E. R. wrote:

...

according to per:

...

Interesting. I have two vanilla Leap42x+KDE systems, one of each, and neither has a /var/log/journal.

If I remember correctly, there is an rpm that creates the persistent journal.

systemd-logger. There might be others too I suppose. -- Per Jessen, Zürich (11.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

George from the tribe wrote:

I am wondering what package would have required me to install systemd-logger? I didn't do it intentionally. I don't know if it is better or not. Now that I have limited the file size, it seems to be running more smoothly.

I suspect systemd-logger is the default unless you opt to install a syslog daemon. {rsyslog,syslog-ng} -- Per Jessen, Zürich (13.3°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

* Carlos E. R. [09-20-16 06:43]:

On 2016-09-20 09:59, Per Jessen wrote:

...

George from the tribe wrote:

...

I am wondering what package would have required me to install systemd-logger? I didn't do it intentionally. I don't know if it is better or not. Now that I have limited the file size, it seems to be running more smoothly.

I suspect systemd-logger is the default unless you opt to install a syslog daemon. {rsyslog,syslog-ng}

Yes, it should.

It is a good thing to keep persistent logs, and they should be either the systemd journal, as is the default now, or syslog, as was the default some time ago.

2 GB of logs is quite big. It means that there is something that talks a lot.

But you need to remember that the journal is not one log but many and it's size contains all those. Get the sum of all the individual logs journal contains and 2 GB is not so much. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535 @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 09/20/2016 03:41 AM, Carlos E. R. wrote:

On 2016-09-20 09:59, Per Jessen wrote:

...

George from the tribe wrote:

...

I am wondering what package would have required me to install systemd-logger? I didn't do it intentionally. I don't know if it is better or not. Now that I have limited the file size, it seems to be running more smoothly. I suspect systemd-logger is the default unless you opt to install a syslog daemon. {rsyslog,syslog-ng} Yes, it should.

It is a good thing to keep persistent logs, and they should be either the systemd journal, as is the default now, or syslog, as was the default some time ago.

2 GB of logs is quite big. It means that there is something that talks a lot.

The systemd-logger package on TW comes in at only 1.0 KiB total size. So this this looks to be a script in the form of an RPM that adds the /var/log/journal directory if it doesn't exist, and after installing, the package manager will change the ownership of the directory if it already existed but didn't belong to: # rpm -qf /var/log/journal systemd-logger-228-14.1.x86_64 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2016-09-21 02:32, George from the tribe wrote:

On 09/20/2016 06:41 PM, Carlos E. R. wrote:

...

2 GB of logs is quite big. It means that there is something that talks a lot.

I think there was something going on in my system that I have fixed now, but it will be hard to know if that is why my logs were so big now that I have limited the file size.

Well, the way to know is not to make guesses, but to read the logs. It is usually simple to have a look at the text of the log and notice if something is printed repeatedly a lot. It can be normal activity. For instance, if you handle mail or news traffic, it gets logged. It can be errors in the disk, systems complaining. With syslog I find it easier to know and adjust. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlfh2VgACgkQja8UbcUWM1zXgAD/fsZkVMci5R9pjd8uRf+gpc4c H14VyeahBoArTvyMNA0A/1yorHmGXojrEU+L/v+NDo0repivZSAN3K8J2m9xwWhZ =v4oC -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Tue 20 Sep 2016 06:43:50 PM CDT, sdm wrote: <snip>

This is the 2nd or third time this thread has broken in Thunderbird. They are starting to get to be emails scattered all over. Is there some reason why this particular thread would be breaking?

Hi AFAIK, it's normally related to the References header... I use gmane (nntp) no broken thread(s) here. -- Cheers Malcolm °¿° LFCS, SUSE Knowledge Partner (Linux Counter #276890) openSUSE Leap 42.1|GNOME 3.16.2|4.1.31-30-default up 7 days 0:02, 5 users, load average: 0.28, 0.22, 0.14 CPU AMD Athlon(tm) II X4 635 @ 2.90GHz | GPU Nvidia GeForce 8800 GT -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2016-09-21 03:43, sdm wrote:

On 09/20/2016 05:50 PM, Carlos E. R. wrote:

This is the 2nd or third time this thread has broken in Thunderbird. They are starting to get to be emails scattered all over. Is there some reason why this particular thread would be breaking?

It is not breaking at all in my Thunderbird. Either you have a local problem or something is removing/modifying headers in the transit to you. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlfh7VwACgkQja8UbcUWM1yOSgD+Jhq9W2hDhvK0LijkwCtUYETL u6z9UqlvCoyOI1GzUJ0A/jCXaMTaln8JiGywXawlGhzNhuVVRe5VVIb65FAQFEBG =zLbz -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2016-09-21 04:37, sdm wrote:

On 09/20/2016 07:15 PM, Carlos E. R. wrote:

It is not breaking at all in my Thunderbird.

Either you have a local problem or something is removing/modifying headers in the transit to you.

Okay, thanks, I am over a VPN right now so maybe that is why.

I don't see a reason for an VPN to replace headers in mail. Unless for anonymizing :-? What does enigmail in thunderbird say about my email GPG signature, does it verify? If it doesn't, it is a sign that something altered the contents. Another reason for breakage could be that some of the posts in the thread didn't arrive at your side. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlfh9HYACgkQja8UbcUWM1zwbgD+Ln6S4LJicBPOP9Zgeb/0q+2+ 8ty/BEsi3lU7cFBrWtgA/jKULOicZ1lB3Ew9XcjLH5+XmSPAEWIt+LPXuUOV6sZs =nuRl -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2016-09-21 05:19, sdm wrote:

On 09/20/2016 07:46 PM, Carlos E. R. wrote:

...

...

...

On 09/20/2016 07:15 PM, Carlos E. R. wrote:

I got the direct copy 20 minutes before than the mail list copy of this email. Thus I replied in private first. The problem is local to your system: :-? direct copy: Received: by mail2.openmailbox.org (Postfix, from userid 1001) id 01D9E1032D1; Wed, 21 Sep 2016 04:59:42 +0200 (CEST) Date: Tue, 20 Sep 2016 19:59:33 -0700 mail list copy: Received: by mail.openmailbox.org (Postfix, from userid 20002) id 9B30F202C30; Wed, 21 Sep 2016 05:19:50 +0200 (CEST) Date: Tue, 20 Sep 2016 20:19:44 -0700

...

...

...

I don't see a reason for an VPN to replace headers in mail. Unless for anonymizing :-?

Because it's over UDP and there can be packet loss, it was just a guess..

Yes, a changed byte on the references or msgid header can do it. But even if the transport is udp, the "cargo" is tcp. That layer would ask for a repeat of the package. Just guessing.

What does enigmail in thunderbird say about my email GPG signature, does it verify? If it doesn't, it is a sign that something altered the contents.

...

I don't know, I don't have that plugin.

I thought so.

Another reason for breakage could be that some of the posts in the thread didn't arrive at your side.

...

They all appear to be arriving if I check the openSUSEmail archive for a post I want to get back to, I never saw one that I didn't already receive although I suppose it's possible, just unlikely. I remember a past thread about other users having thread breakage as well.

I seem to remember that, but not the conclusion. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

On 2016-09-21 14:23, sdm wrote:

...

I think what could be happening is I'm deleting messages from the list that I've read already, but I'm not always reading them in order. So they aren't always being deleted in the order they came in. Could that affect the thread breakage?

Of course it does! You should not delete, but move to an archive. Later or automatically you purge old emails from the archive. Or filter the mail as it comes from the inbox to different folders per mail lists. Then archive or delete mails that are older than, say, two months. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2016-09-21 16:55, Patrick Shanahan wrote:

* Carlos E. R. <> [09-21-16 08:44]:

Mail threading is maintained by the mail headers (your post so far):

References:

...

and has *absolutely* nothing to do with deleting mail within your system.

Yes, it has has, because if you delete the ancestor there is nothing to thread to. Of course the rest of the people see the complete thread, but he doesn't. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlfiubIACgkQja8UbcUWM1xiWgD+MsBH5adsQRShKlvJdLgUehCD dhPZSEJ8Qf7E0MOlTgsA/0IPzHv3r6RMNX6nZazHVOtWu7v5yFSECAPqj2S/0+wv =vX18 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2016-09-20 02:01, Darryl Gregorash wrote:

Do any of you guys create /var/log at install time? If not, perhaps there is some sort of check: "if /var/log exists, then create /var/log/journal" -- just guessing, of course.

Telcontar:~ # rpm -qf /var/log filesystem-13.1-3.1.2.x86_64 Telcontar:~ # That directory is mandatory on Linux :-) -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

On 09/20/2016 01:36 PM, Per Jessen wrote:

Darryl Gregorash wrote:

...

Per Jessen wrote:

Yes, that is useful. In your installation, you leave it to the default systemd-logger (which has a persistent journal). I always install syslog-ng, so I never get /var/log/journal. Well, at least that's cleared up.

What is a "persistent" journal, as opposed to some other kind of journal? -- George Box: 42.1 | KDE Plasma 5 | AMD Phenom IIX4 | 64 | 32GB Laptop #1: 42.1 | Plasma 5.4.7, Qt 5.7.0 | Core i7-4710HQ | 64 | 16GB Laptop #2: 42.1 | KDE Plasma 5 | Core i5 | 64 | 8GB -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 09/19/2016 05:17 AM, Per Jessen wrote:

Yes, neither Leap421 nor 422 have a /var/log/journal in the default install. I checked on my Leap 422 box and /var/log/journal is indeed there, on a fresh install from a USB key. So if you are not seeing it then for unknown reasons the installer is not always creating that directory. I checked journald.conf on Leap 422 just now and everything is commented out, as I suspected. "auto" is commented out for the record. So it's volatile. That could make sense for a desktop user in some cases (maybe with a 256 MB hard drive), and a person running a server would know to change the default in most cases. But I have seen new(er) openSUSE Linux users executing journalctl to investigate after a panic/lockup, only to find everything that could have been relevant was dumped. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 09/19/2016 02:15 PM, Carlos E. R. wrote:

On 2016-09-19 20:15, sdm wrote:

...

On 09/19/2016 05:17 AM, Per Jessen wrote:

...

Yes, neither Leap421 nor 422 have a /var/log/journal in the default install. I checked on my Leap 422 box and /var/log/journal is indeed there, on a fresh install from a USB key. So if you are not seeing it then for unknown reasons the installer is not always creating that directory. I checked journald.conf on Leap 422 just now and everything is commented out, as I suspected. "auto" is commented out for the record. So it's volatile. No. The it is "auto", the default. If the default were "volatile" the config file would say:

#Storage=volatile

as documented.

Auto is the default but it's commented out. That is why I'm saying the behaviour isn't the same as if auto were commented in. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 09/19/2016 02:48 PM, Chris Murphy wrote: <---snip---> On 09/19/2016 02:15 PM, Carlos E. R. wrote:

No. The it is "auto", the default. If the default were "volatile" the config file would say:

#Storage=volatile

as documented.

Okay, thanks for clarification. I just checked on Leap 42.1 and the /var/log/journal directory was created on install and logs *were* persistent. Either the behaviour was different for me on a different box where I last ran Leap 42.1, or I am remembering details from TW as I switch between the two a lot. I can verify that on my TW box, /var/log/journal *did not* exist and I never touched anything or deleted it. I just created /var/log/journal, and now the journal is persistent and it's no longer being written to /run/log/journal. I will install openSUSE-Leap-42.2-DVD-x86_64-Build0188-Media.iso on the test box to see what I find, but on the 422 beta which was on the test machine earlier that I tested, those logs were not persistent. I rebooted the machine multiple times and checked. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 09/19/2016 08:17 PM, Per Jessen wrote:

sdm wrote:

Yes, neither Leap421 nor 422 have a /var/log/journal in the default install.

Are you sure about that? I did not upgrade from 13.2 - I ran a clean installation on this root partition. I never manually created the /var/log/journal directory. I don't know if it was created during the install or afterwards on some upgrade, but I know I didn't purposely do anything to create the /var/log/journal directory. I have made very few system type changes to anything, with the exception of setting up java, because mostly I just use default settings on everything. Well, I also have my root partition running in a RAID 1 configuration. I guess one other thing I did was install a newer version of plasma5 and qt, but that shouldn't have anything to do with this, I think. -- George Box: 42.1 | KDE Plasma 5 | AMD Phenom IIX4 | 64 | 32GB Laptop #1: 42.1 | Plasma 5.4.7, Qt 5.7.0 | Core i7-4710HQ | 64 | 16GB Laptop #2: 42.1 | KDE Plasma 5 | Core i5 | 64 | 8GB -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 09/20/2016 02:21 PM, Per Jessen wrote:

How big is your the partition then? As some have pointed out, 2Gb is not a lot (these days), but if the partition is very small, it could lead to problems.

My root is 20GB. I just noticed when I ran a du check that only 15GB are being used. However, the other day when I started this thread and had the large journal file, a du check said my root partition was filled up to 19GB. I added the limitation on the journal size to 300M, which reduced the file size in that directory to 345M, down from 2G, and now my root partition use is down to 15G. Wierd. I didn't make a copy of my du check the other day, so I don't have any way to go back and see what else was removed from my root partition. -- George Box: 42.1 | KDE Plasma 5 | AMD Phenom IIX4 | 64 | 32GB Laptop #1: 42.1 | Plasma 5.4.7, Qt 5.7.0 | Core i7-4710HQ | 64 | 16GB Laptop #2: 42.1 | KDE Plasma 5 | Core i5 | 64 | 8GB -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 09/20/2016 06:44 PM, Carlos E. R. wrote:

On 2016-09-20 09:23, George from the tribe wrote:

...

My root is 20GB. I just noticed when I ran a du check that only 15GB are being used. However, the other day when I started this thread and had the large journal file, a du check said my root partition was filled up to 19GB. I added the limitation on the journal size to 300M, which reduced the file size in that directory to 345M, down from 2G, and now my root partition use is down to 15G. Wierd. I didn't make a copy of my du check the other day, so I don't have any way to go back and see what else was removed from my root partition.

Possibly some space was used by the failed update. Things were downloaded and waiting.

Oh, yes, that makes sense. -- George Box: 42.1 | KDE Plasma 5 | AMD Phenom IIX4 | 64 | 32GB Laptop #1: 42.1 | Plasma 5.4.7, Qt 5.7.0 | Core i7-4710HQ | 64 | 16GB Laptop #2: 42.1 | KDE Plasma 5 | Core i5 | 64 | 8GB -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Carlos E. R. wrote:

...

Can anyone help? Should I just go into the journald.conf and adjust the parameter to limit the file size? Or is there something else I need to do?

Yes, you should.

Set limits. For example:

From what sdm posted, 'auto' is commented out in the config to note

According to what he posted in the man page, the default should be auto. that auto is the default in the software without any comments being active. I.e. look at the large squid.conf sometime. All of the options are in the conf, but none are commented in as they are simply documenting the default that is built into the software.

From the docs George quoted, the journal should already be set to autotrim -- where it should auto clean itself when the disk is getting near full. It sorta sounds like it didn't do that intelligently -- i.e. he was having disk-full conditions and the log wasn't autotrimming.

Carlos, if what you meant by:

SystemMaxUse=100M RuntimeMaxUse=30M

was that going with the default, e.g.- to only trim when disk space was running out on the log device, was giving it too much space, then I'd agree. Remember though, that the original journal design was designed on a SSD where letting the disk fill, then cleaning it off "shouldn't" hurt future access times. Seems like "auto" is deceptive, since it sounds like it should take care of itself. However, taking care of itself is using all available space until it *needs* to trim. Irk. Given that behavior, maybe suse should provide some other intelligent default (and no -- memory isn't intelligent, it just vaporizes each boot -- and if you are having boot problems, killing off all previous logs each boot isn't very helpful, no? -l -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 09/19/2016 08:44 AM, Linda Walsh wrote:

From the docs George quoted, the journal should already be set to autotrim -- where it should auto clean itself when the disk is getting near full. It sorta sounds like it didn't do that intelligently -- i.e. he was having disk-full conditions and the log wasn't autotrimming.

The defaults are volatile logs on a clean 42.1 Leap install, because "auto" is should be commented out (can someone verify, on a clean 42.1 install?) and the storage limits commented out by default, which make the journal behave practically like "volatile" as I wrote in the above email. So, George, did you do an upgrade from 13.1 or 13.2? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 09/19/2016 12:54 PM, Chris Murphy wrote:

On Mon, Sep 19, 2016 at 1:47 PM, sdm wrote:

...

On 09/19/2016 08:44 AM, Linda Walsh wrote:

...

From the docs George quoted, the journal should already be set to autotrim -- where it should auto clean itself when the disk is getting near full. It sorta sounds like it didn't do that intelligently -- i.e. he was having disk-full conditions and the log wasn't autotrimming.

The defaults are volatile logs on a clean 42.1 Leap install, because "auto" is should be commented out (can someone verify, on a clean 42.1 install?) and the storage limits commented out by default, which make the journal behave practically like "volatile" as I wrote in the above email. So, George, did you do an upgrade from 13.1 or 13.2? All systemd configuration files show the defaults commented out, including /etc/systemd/journald.conf.

# Entries in this file show the compile time defaults.

So if you have an entry: #Storage=auto

That means it looks for /var/log/journal. If it exists already, then the journal will be stored persistently in that location. If it doesn't exist, it will be stored in /run/log/journal/ which is volatile.

Not on Leap 422. *If* /var/log/journal exists, those journal files are wiped with each reboot, and Leap 42.1 behaved the same exact way for me, although I don't rememember right now if /var/log/journal existed on my past Leap 42.1 box. I wouldn't be surprised if after installing Leap 42.1, and the /var/log/journal directory existed, the behaviour would be exactly the same as Leap 422. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 09/19/2016 02:12 PM, Carlos E. R. wrote:

On 2016-09-19 22:01, sdm wrote:

...

On 09/19/2016 12:54 PM, Chris Murphy wrote:

...

...

# Entries in this file show the compile time defaults.

So if you have an entry: #Storage=auto

That means it looks for /var/log/journal. If it exists already, then the journal will be stored persistently in that location. If it doesn't exist, it will be stored in /run/log/journal/ which is volatile.

Not on Leap 422. *If* /var/log/journal exists, those journal files are wiped with each reboot, and Leap 42.1 behaved the same exact way for me, although I don't rememember right now if /var/log/journal existed on my past Leap 42.1 box. I wouldn't be surprised if after installing Leap 42.1, and the /var/log/journal directory existed, the behaviour would be exactly the same as Leap 422.

If what you say is true, it is a bug you must report, because it is contrary to the documentation.

/var/log/journal/* are the persistent logs and are not deleted on boot.

/run/log/journal/* are the volatile logs, deleted on each boot. /run/ is a tmpfs.

But remember, the default for Leap 422 is that "auto" is commented out just like TW. You are right, if the /var/log/journal directory exists, then the systemd journal should write to that directory if "auto" is commented in. But as Richard said, in his journald.conf file everything is commented out, which is the same as my Leap 422 and TW boxes. I am checking Leap 42.1 when I can, later today, to once again verify that logs by default aren't persistent. The man page doesn't state what the behaviour should be if "auto" is commented out, which appears to be an OpenSUSE default across TW, Leap 422, and according to other posters, 421. Right now, it's appearing that on some systems, I believe Per's 2 Leap 42.1 boxes as well, when "auto" is commented out and the /var/log/journal/ directory exists, logs are not persistent. And that would make sense, wouldn't it? You need to comment in "auto" if you want it to do what it's supposed to do. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Mon, Sep 19, 2016 at 3:24 PM, sdm wrote:

But remember, the default for Leap 422 is that "auto" is commented out just like TW.

cat /etc/systemd/journald.conf *** # Entries in this file show the compile time defaults. *** Those comments are the defaults compiled in. Therefore #Storage=auto Storage=auto Are identical. The commented settings are there to let the user know what the compiled in defaults are. To change the behavior, you should put in your own setting above or below the commented one, that way you have a way of knowing what the default is should you wish to revert.

The man page doesn't state what the behaviour should be if "auto" is commented out,

Yes it does.

Right now, it's appearing that on some systems, I believe Per's 2 Leap 42.1 boxes as well, when "auto" is commented out and the /var/log/journal/ directory exists, logs are not persistent. And that would make sense, wouldn't it?

It makes exactly zero sense. Sorry.

You need to comment in "auto" if you want it to do what it's supposed to do.

No. Auto is *compiled* in as the default. If you don't want that you need to create an uncommented Storage= with a value other than auto. -- Chris Murphy -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 09/19/2016 05:24 PM, sdm wrote:

On 09/19/2016 02:12 PM, Carlos E. R. wrote:

...

On 2016-09-19 22:01, sdm wrote:

...

On 09/19/2016 12:54 PM, Chris Murphy wrote:

...

...

# Entries in this file show the compile time defaults.

So if you have an entry: #Storage=auto

That means it looks for /var/log/journal. If it exists already, then the journal will be stored persistently in that location. If it doesn't exist, it will be stored in /run/log/journal/ which is volatile.

Not on Leap 422. *If* /var/log/journal exists, those journal files are wiped with each reboot, and Leap 42.1 behaved the same exact way for me, although I don't rememember right now if /var/log/journal existed on my past Leap 42.1 box. I wouldn't be surprised if after installing Leap 42.1, and the /var/log/journal directory existed, the behaviour would be exactly the same as Leap 422.

If what you say is true, it is a bug you must report, because it is contrary to the documentation.

/var/log/journal/* are the persistent logs and are not deleted on boot.

/run/log/journal/* are the volatile logs, deleted on each boot. /run/ is a tmpfs.

But remember, the default for Leap 422 is that "auto" is commented out just like TW. You are right, if the /var/log/journal directory exists,

If "auto" is the default it is the default (used) whether it is commented or uncommented. -- Ken linux since 1994 S.u.S.E./openSUSE since 1996 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Mon, Sep 19, 2016 at 2:01 PM, sdm wrote:

On 09/19/2016 12:54 PM, Chris Murphy wrote:

...

On Mon, Sep 19, 2016 at 1:47 PM, sdm wrote:

...

On 09/19/2016 08:44 AM, Linda Walsh wrote:

...

From the docs George quoted, the journal should already be set to autotrim -- where it should auto clean itself when the disk is getting near full. It sorta sounds like it didn't do that intelligently -- i.e. he was having disk-full conditions and the log wasn't autotrimming.

The defaults are volatile logs on a clean 42.1 Leap install, because "auto" is should be commented out (can someone verify, on a clean 42.1 install?) and the storage limits commented out by default, which make the journal behave practically like "volatile" as I wrote in the above email. So, George, did you do an upgrade from 13.1 or 13.2?

All systemd configuration files show the defaults commented out, including /etc/systemd/journald.conf.

# Entries in this file show the compile time defaults.

So if you have an entry: #Storage=auto

That means it looks for /var/log/journal. If it exists already, then the journal will be stored persistently in that location. If it doesn't exist, it will be stored in /run/log/journal/ which is volatile.

Not on Leap 422. *If* /var/log/journal exists, those journal files are wiped with each reboot, and Leap 42.1 behaved the same exact way for me, although I don't rememember right now if /var/log/journal existed on my past Leap 42.1 box. I wouldn't be surprised if after installing Leap 42.1, and the /var/log/journal directory existed, the behaviour would be exactly the same as Leap 422.

I just did a defaultinstallation of openSUSE-Leap-42.2-DVD-x86_64-Build0164-Media.iso in a virt-manager VM. And I did several reboots. - /var/log/journal exists, I assume it's created by something that sets up the fs structure, could be the installer or a package that just creates a bunch of directories to make sure they exist $ rpm -qa | grep logger systemd-logger-228-8.1.x86_64 $ sudo journalctl --list-boots -2 cb919764f6034901a5ca588992aecafe Mon 2016-09-19 17:20:48 EDT—Mon 2016-09-19 17:26:15 EDT -1 ce9c562b531a428c825cbd40d7656ccf Mon 2016-09-19 17:26:31 EDT—Mon 2016-09-19 17:27:42 EDT 0 fb40d5665c4b42e1abbf46106e37f606 Mon 2016-09-19 17:27:52 EDT—Mon 2016-09-19 17:29:22 EDT $ sudo journalctl -b-1 shows the log of the previous boot, so clearly it's persistent $ sudo journalctl -b | grep journald Sep 19 17:27:52 linux-ae34 systemd-journald[105]: Runtime journal (/run/log/journal/) is currently using 8.0M. Sep 19 17:27:52 linux-ae34 systemd-journald[105]: Journal started Sep 19 17:27:54 linux-ae34 systemd-journald[105]: Journal stopped Sep 19 17:27:54 linux-ae34 systemd-journald[444]: Runtime journal (/run/log/journal/) is currently using 8.0M. Sep 19 17:27:54 linux-ae34 systemd-journald[105]: Received SIGTERM from PID 1 (systemd). Sep 19 17:27:54 linux-ae34 systemd-journald[444]: Journal started Sep 19 17:27:55 linux-ae34 systemd-journald[444]: System journal (/var/log/journal/) is currently using 16.0M. Sep 19 17:27:55 linux-ae34 systemd-journald[444]: Time spent on flushing to /var is 19.289ms for 763 entries. It's clearly being flushed to disk, the journal is persistent. $ sudo journalctl -b -- Logs begin at Mon 2016-09-19 17:20:48 EDT, end at Mon 2016-09-19 17:34:31 EDT. -- Sep 19 17:27:52 linux-ae34 systemd-journald[105]: Runtime journal (/run/log/journal/) is currently using 8.0M. Maximum allowed usage is set to 150.3M. Leaving at least 225.5M free (of currently available 1.4G of space). Enforced usage limit is thus 150.3M, of which 142.3M are still available. [...snip...] Sep 19 17:27:55 linux-ae34 systemd-journald[444]: System journal (/var/log/journal/) is currently using 16.0M. Maximum allowed usage is set to 4.0G. Leaving at least 4.0G free (of currently available 35.6G of space). Enforced usage limit is thus 4.0G, of which 3.9G are still available. Sep 19 17:27:55 linux-ae34 systemd-journald[444]: Time spent on flushing to /var is 19.289ms for 763 entries. Sep 19 17:27:55 linux-ae34 systemd[1]: Started Flush Journal to Persistent Storage. Again there are two journals, the initial volatile one during startup, as soon as rootfs is rw the journal gets flushed to persistent storage on /var/log/journal. $ sudo journalctl --disk-usage Archived and active journals take up 16.2M on disk So the gotcha here might be this from 'man journald.conf' SystemMaxUse= and RuntimeMaxUse= control how much disk space the journal may use up at most. SystemKeepFree= and RuntimeKeepFree= control how much disk space systemd-journald shall leave free for other uses. systemd-journald will respect both limits and use the smaller of the two values. The first pair defaults to 10% and the second to 15% of the size of the respective file system, but each value is capped to 4G. If the file system is nearly full and either SystemKeepFree= or RuntimeKeepFree= are violated when systemd-journald is started, the limit will be raised to the percentage that is actually free. This means that if there was enough free space before and journal files were created, and subsequently something else causes the file system to fill up, journald will stop using more space, but it will not be removing existing files to reduce the footprint again, either. And as we know the something else can cause it to fill up, which are snapshots. Hypothetically this should get better with quotas better informing snapper what to free up, but this needs testing to see what the interactions are. -- Chris Murphy -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 09/20/2016 03:31 PM, George from the tribe wrote:

On 09/20/2016 03:47 AM, sdm wrote:

...

On 09/19/2016 08:44 AM, Linda Walsh wrote:

...

From the docs George quoted, the journal should already be set to autotrim -- where it should auto clean itself when the disk is getting near full. It sorta sounds like it didn't do that intelligently -- i.e. he was having disk-full conditions and the log wasn't autotrimming.

The defaults are volatile logs on a clean 42.1 Leap install, because "auto" is should be commented out (can someone verify, on a clean 42.1 install?) and the storage limits commented out by default, which make the journal behave practically like "volatile" as I wrote in the above email. So, George, did you do an upgrade from 13.1 or 13.2?

No, it wasn't an upgrade. I have 13.2 on a separate partition, but I ran a clean install of 42.1 on this partition. It was over the top of an old 13.1 installation on the same partition, but that shouldn't matter since it was a clean install, and the installation media formatted the partition (I assume) when it installed 42.1.

Here is my journald.conf file: # cat systemd/journald.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 journald.conf(5) for details [Journal] #Storage=auto #Compress=yes #Seal=yes #SplitMode=login #SyncIntervalSec=5m #RateLimitInterval=30s #RateLimitBurst=1000 SystemMaxUse=300M #SystemKeepFree= #SystemMaxFileSize= RuntimeMaxUse=50M #RuntimeKeepFree= #RuntimeMaxFileSize= #MaxRetentionSec= #MaxFileSec=1month #ForwardToSyslog=yes #ForwardToKMsg=no #ForwardToConsole=no #TTYPath=/dev/tty10 #MaxLevelStore=debug #MaxLevelSyslog=debug #MaxLevelKMsg=notice #MaxLevelConsole=info So you see that my Storage=auto line is commented out. The only lines I changed are the ones that are not commented out. -- George Box: 42.1 | KDE Plasma 5 | AMD Phenom IIX4 | 64 | 32GB Laptop #1: 42.1 | Plasma 5.4.7, Qt 5.7.0 | Core i7-4710HQ | 64 | 16GB Laptop #2: 42.1 | KDE Plasma 5 | Core i5 | 64 | 8GB -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 09/20/2016 06:49 PM, Carlos E. R. wrote:

On 2016-09-20 09:34, George from the tribe wrote:

...

So you see that my Storage=auto line is commented out. The only lines I changed are the ones that are not commented out.

As explained several times in the thread, the commented vars are a reminder to the admin of what are the defaults. "Storage=auto" *is* the default.

Ok, good to know. -- George Box: 42.1 | KDE Plasma 5 | AMD Phenom IIX4 | 64 | 32GB Laptop #1: 42.1 | Plasma 5.4.7, Qt 5.7.0 | Core i7-4710HQ | 64 | 16GB Laptop #2: 42.1 | KDE Plasma 5 | Core i5 | 64 | 8GB -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org