-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2017-03-05 11:56, Stefan Seyfried wrote:
Am 04.03.2017 um 22:59 schrieb Carlos E. R.:
On 2017-03-04 22:16, Stefan Seyfried wrote:
And you'll lose logs. Because some things are only in the journal, others are only in syslog.
I don't know about that, either. I think it would be a bug. I suspect that entries sometimes have different order. Missing entries I have no proof. Maybe some that are related to systemd debug.
I have to dig out the service requests and related bugzillas, but in the end it was "forwarding to syslog failed for $NUMBER messages" in journal, and nothing in syslog. The "only in syslog" thing might have been when I was still using syslog-ng, I'm not 100% sure about that.
Ah. Dunno. Maybe they were fast coming messages, and I don't have that many to replicate. Maybe a script writing numbered entries fast.
That would be a feature. Saves typing "--lines=0" with "systemctl status" all the time.
LOL.
Well, that's one thing I find useful, seeing some logs entries related to the failure to start.
Well, but it makes "systemctl foobar status" take lots of time (tens of seconds) when running on rotating rust, because of the superior performance and design of the journal database.
Ahhhh! Understood. Uchh!
But our SLES Support contract would be moot probably :-)
I don't know about that.
You could limit the size of the journal files. That's what I do on other computers. After all, the mail and nntp log fills the journal with useless stuff, so the journal is about useless to me. On this laptop I'm trying no journal at all.
Why save 4 GB of current journal logs? Save a few hundred megs.
It's the default configuration. Something about "n percent of available memory, max 4GB". And on those machines, 4GB is clearly much less than one percent of available memory ;)
Well, you can limit it: SystemMaxUse=100M RuntimeMaxUse=30M Does the contract say that you can not edit settings at all? Just write sensible values.
Anyway, copying 40GB of logfiles off the machine takes maybe 5, max 10 minutes. Dumping 4GB of journal data takes 8+ hours. (The bug btw is bsc#997615 and it was fixed by doing "journalctl -b| head -n xxx" because journalctl performance apparently could not be fixed).
Yeah. :-( They tested it on SSD.
Mind, this configuration works with rsyslog, but not with syslog-ng if I remember correctly the one. The later takes the log entries watching the files, so it gets nothing.
Yes, that's another issue, forcing people to switch to rsyslog (which I personally don't oppose, but still choice would be nice).
But it is the fault of syslog-ng. They are doing it wrong. (effectively syslog-ng seems to be doing a "journalctl --follow") - -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREIAAYFAli8FE0ACgkQja8UbcUWM1y0AAD9EY3cErcT4F3e13BUdXnKBrDK gvdUGZdkrFZD57FO/Q4A/2LuVxQJi1nBXKt8Eqif2bcVgzHuTRWh3Rg3chsqEWgP =YDs6 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org