[systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance

[Reindl Harald]

Am 22.09.2014 um 13:45 schrieb Jóhann B. Guðmundsson:
> On 09/22/2014 11:40 AM, Reindl Harald wrote:
>> Am 22.09.2014 um 13:28 schrieb Jóhann B. Guðmundsson:
>>> On 09/22/2014 09:23 AM, Reindl Harald wrote:
>>>> Am 22.09.2014 um 01:48 schrieb Jóhann B. Guðmundsson:
>>>>> The reason for increased log entries in the journal is that more things
>>>>> are happening now since this is what happening when a job is run.
>>>> that don't change the fact that a user not acting as
>>>> systemd-developer and not debugging his system don't
>>>> need that flood
>>> I guess we have different meaning of message flood
>> again: we talk about rsyslog, like it or not
> 
> Then file a bug report against rsyslog and provide a patch which fixes 
> the default log filtering in Fedora to your expectation but leave 
> systemd out of it.

wow - in any other case the systemd developers saying that
they don't workround things because problems has to be
solved at the root-cause - practice what you preach and
make the log-verbosility configureable!

* rsyslog is *not* responsible for the message flood produced by systemd
* systemd is the one producing it without prefixes

produce 80000 loglines noise on a small infrastructure is insane
that's the same all other services produce together

is it really that hard to accept that this level of informations
is only helpful for debugging, produces overhead if it could
be filtered away and anyways has the bad impact that journald
in rsyslog envoironments has the whole day to do with rotate

[Journal]
Storage=volatile
Compress=yes
RateLimitInterval=10s

frankly i have seen more or less idle machines where journald is
one of the top ressource consumers

>> what you filter below is what i have in /var/log/cron and /var/log/secure
>> but the other messages spit to the log are a lot more
>>
>> here you have a simple calculation
>> https://bugzilla.redhat.com/show_bug.cgi?id=1072368#c8
>>
>> why don't you look at https://bugzilla.redhat.com/show_bug.cgi?id=1072368
>> and the workaround "loginctl enable-linger" leads to another bugreport
>> open for months: https://bugzilla.redhat.com/show_bug.cgi?id=1088619#c54
>>
>> so what we have now is log flooding or hanging shutdowns
>> why don't upstream just what users would help and reduce logging
>> in a non-debug mode to a minimum so one can see without filter
>> if something unusal happens on a system?
>>
>> if the developers would accept the need of their users then likely the users
>> would also be more positive, just don't explain me how to maintain my servers
>>
>> i am fine with distribute-command.sh "cat /var/log/messages" all they
>> years because the general log is silent until something bad happens
>>
>> you can't do that if systemd floods it for 30 machines
>>
>>> # journalctl -f
>>> Sep 22 11:13:01 localhost.localdomain systemd[1]: Starting Session 59 of user johannbg.
>>> Sep 22 11:13:01 localhost.localdomain systemd[1]: Started Session 59 of user johannbg.
>>> Sep 22 11:13:01 localhost.localdomain CROND[7336]: (johannbg) CMD (/bin/systemd-cat -t "CROND" /bin/echo "Systemd
>>> journal cron job log test every minute" )
>>> Sep 22 11:13:01 localhost.localdomain CROND[7336]: Systemd journal cron job log test every minute
>>>
>>> Hey let's filter this even further
>>>
>>> # journalctl -f SYSLOG_IDENTIFIER=CROND
>>> -- Logs begin at Thu 2013-10-24 11:47:22 GMT. --
>>> Sep 22 11:14:01 localhost.localdomain CROND[7401]: (johannbg) CMD (/bin/systemd-cat -t "CROND" /bin/echo "Systemd
>>> journal cron job log test every minute" )
>>> Sep 22 11:14:01 localhost.localdomain CROND[7401]: Systemd journal cron job log test every minute
>>>
>>> Anything regarding an text file and local and or remote logging using either rsyslog or syslog-ng is and it's
>>> default is not relevant to us and usually set by distribution maintainers.
>>>
>>> For remote logging I would assume administrator would create an cron filter which has the syslog identifier crond
>>> or CROND, the syslog facility 9 and an priority 6 and send that to the remote server
>>>
>>> So if systemd output is too much in any text file <-- file a bug against rsyslog or syslog-ng depending on which
>>> the distribution and have *them* fix their default filtering

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freedesktop.org/archives/systemd-devel/attachments/20140922/e817ef2c/attachment.sig>