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

[Reindl Harald]

Am 22.09.2014 um 14:44 schrieb Jóhann B. Guðmundsson:
> >> > 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!
>  
>  Serves no purpose whatsoever doing that.
> >
> > * rsyslog is *not* responsible for the message flood produced by systemd
>  
>  No but it is responsible for the filtering <-- of log messages.
>  
> > * systemd is the one producing it without prefixes 
it is ridiculous to have the need of filtering

>  This is simply untrue as "journalctl -o export" will show
> you. 
where is it in the message?
the process is "systemd"

how to distinct between user sessions and systemn boot?
":programname" don't work and ":msg, startswith" don't work

Mar 18 23:01:01 rawhide systemd[577]: Stopped target Default.
Mar 18 23:01:01 rawhide systemd[577]: Stopping Basic System.
Mar 18 23:01:01 rawhide systemd[577]: Stopped target Basic System.
Mar 18 23:01:01 rawhide systemd[577]: Stopping Paths.
...................

>  I suggest you stop blaming systemd for your own administrative
> incompetence  
i suggest you get rid of that arrogance and some other developers
too because it's the reason for the subject and proves that you
*do not* care about users as long you have not the same opinion

you are the one demanding a friendly tone from me, well, than
practice what you preach or stop whining if someone calls you
names the next time

who do you think you are to assess others incompetence?

>  and broken implementation of rsyslog and syslog-ng in Fedora 
>  (I tried to get it fixed before we defaulted to journal YES IT 
>  WAS BROKEN BEFORE AND STILL IS but was not allowed to do so 
>  thank those Red Hatters in the governing body's of Fedora 
>  ( FESCO/FPC ) for it's brokeness)  
just don't create messages the majority of users don't want and need
to see until debugging and even systemd needs to realize that the
world is not turning around it

>  and write an rsyslog template suited for your environment which 
>  will filter things to your liking and expectation or better yet
>  complain to those FESCO/FPC members since they need to learn a 
>  hard lesson of accepting responsibility for their own actions 
>  in the distribution 
who do you think you are?

that arrogance and pure ignorance is the reason for subject and
related websites as well as for users from time to time not
complaining as nice as you would like it

hence fedora devel CC'ed
__________________________________________________________________________

here the relevant links you decided to strip out and replace
with your arrogant abuse as you always do if someone has a
differnt opinion but demand from others not act the same way

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

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

[Jóhann B. Guðmundsson]

On 09/22/2014 12:58 PM, Reindl Harald wrote:
>  i suggest you get rid of that arrogance and some other developers
>  too because it's the reason for the subject and proves that you
>  *do not*  care about users as long you have not the same opinion
>
>  you are the one demanding a friendly tone from me, well, than
>  practice what you preach or stop whining if someone calls you
>  names the next time
>
>  who do you think you are to assess others incompetence? 
I think I'm the one based on your own actions as in after you cant even 
take your time to a read upstream rsyslog documentation then insert a 
single line of filtering in rsyslog, similar or equivalent of

":programname, isequal, "systemd" -/var/log/systemd.log"

to filter out systemd message from /var/log/message or fine tune the 
filtering through the use of rsyslog templates and submit that as a 
patch against rsyslog in Fedora so the distribution can improve it's 
default filtering in rsyslog based on your input but instead choose to 
file gazillion bug reports against systemd which has nothing to do with 
the text file filtering in the distribution,  clutter the comment 
sections with useless output in those bug reports "to prove your point 
over and over again" and call the lead developer of the project an idiot 
in one of those reports then show up upstream cursing and demanding 
fixes saying that systemd message cant be filtering even thou I pointed 
to "journalctl -o export" which shows all the messages fields each log 
contains including all the syslog entries which should provide an 
capable administrator pleathora of ideas how to filter message in 
conjunction with rsyslog powerful filtering capabilities and all that 
rant for something that is not our to fix in the firstplace.

1. https://bugzilla.redhat.com/show_bug.cgi?id=1072368#c4

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

[Reindl Harald]

Am 22.09.2014 um 15:55 schrieb Jóhann B. Guðmundsson:
>  On 09/22/2014 12:58 PM, Reindl Harald wrote:
> > i suggest you get rid of that arrogance and some other developers
> > too because it's the reason for the subject and proves that you
> > *do not* care about users as long you have not the same opinion
> >
> > you are the one demanding a friendly tone from me, well, than
> > practice what you preach or stop whining if someone calls you
> > names the next time
> >
> > who do you think you are to assess others incompetence?
>  
>  I think I'm the one based on your own actions as in after you cant even take your
> time to a read upstream rsyslog
>  documentation then insert a single line of filtering in rsyslog, similar or equivalent
> of
>  
>  ":programname, isequal, "systemd"                       
> -/var/log/systemd.log" 
no you refuse to understand that *nobody* wants to split
out *all* systemd logs because just the excessive *user
session* logging and that this messages should not exist
at all in a non-debugging environment

you also refuse to understand that the intention in
production environments using a *centralized* SQL
logging is do *drop that messages* but hardly to
drop anything from systemd

so the next time before you take "incompetence"
in your mouth try to understand the context or
ask yourself on which side it exists

>  clutter the comment sections with useless output in those bug
>  reports "to prove your point over and over again" and call the 
>  lead developer of the project an idiot 
cause and effect - what reaction did he expect by
follow a link to a for weeks existing bugreport and
as only action close it with "NOBUG" a minute later

>  in one of those reports  then show up upstream cursing and demanding
> fixes
>  saying that systemd message cant be filtering even thou I pointed  to "journalctl
>  -o export" which shows all the messages fields each log contains including all the
>  syslog entries which should provide an capable administrator pleathora of ideas 
>  how to filter message in conjunction with rsyslog powerful filtering capabilities 
>  and all that rant for something that is not our to fix in the firstplace. 
surely - you have no need to produce that flood in the first instance
and if you as systemd-developer want that informations then enable
deugging but stop to decide what every user needs to have in his logs
or actively to filter

realize that the world don't turn around systemd developers and
just stop your arrogance and ignorance - you will wonder how
friendly the same people become complaining all the time if
upstream stops to handle users like someone who disturbs

>  1. https://bugzilla.redhat.com/show_bug.cgi?id=1072368#c4

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

[Sérgio Basto]

On Seg, 2014-09-22 at 16:08 +0200, Reindl Harald wrote:
>  no you refuse to understand that *nobody* wants to split
>  out *all* systemd logs because just the excessive *user
>  session* logging and that this messages should not exist
>  at all in a non-debugging environment 
IIUC , this messages doesn't exist in a non-debugging environment since
ends of Apr [1], or I shut up this messages somehow , I don't
remember ...


[1] 
cat /var/log/secure-2014* | grep systemd | tail -n1
Apr 26 00:50:01 segulix systemd: pam_unix(systemd-user:session): session
opened for user root by (uid=0)



-- 
Sérgio M. B.

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

[Reindl Harald]

Am 22.09.2014 um 16:48 schrieb Sérgio Basto:
>  On Seg, 2014-09-22 at 16:08 +0200, Reindl Harald wrote:
> > no you refuse to understand that *nobody* wants to split
> > out *all* systemd logs because just the excessive *user
> > session* logging and that this messages should not exist
> > at all in a non-debugging environment
>  
>  IIUC , this messages doesn't exist in a non-debugging environment since
>  ends of Apr [1], or I shut up this messages somehow , I don't
>  remember ... 
* i shut up them with "loginctl enable-linger"
* that's a workaround
* doing so in F20 to prevent forget with F21 leads to
  another bug: https://bugzilla.redhat.com/show_bug.cgi?id=1088619#c54

it is even *possible* that it was changed but if so it shows
several problems:

* nobody knows, people already built workarounds
* it takes too long for any reaction on such issues
  so that people can't or won't wait for a response
  and try to find bugreports because lost hope that
  things become better in a reasonable time
* the reaction close with "NOTABUG" after weeks of ignore is wrong

frankly that was once introduced even in F19 backports and
quickly fixed while also point to "loginctl enable-linger"
which is *really* a dirty workaround leading the user sessions
are started at boot before the first cronjob fires up which
wastes ressources at boot

only that it was fixed in a short because that backport was
not targeted for F19 shows how easy it could be changed if
upstream would care about downstream in any way

look at the response from Johann directed to downstream in general,
Fedora and FeSCO in special and the repeatet responses "we are upstream
and this and that are downstream problems we don't care" shows how
terrible wrong things are going

a upstream of a *critical core componentent* with a "i don't care
about downstream" attitude is only one thing: dangerous

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

[Sérgio Basto]

On Seg, 2014-09-22 at 17:00 +0200, Reindl Harald wrote: 
>  
>  Am 22.09.2014 um 16:48 schrieb Sérgio Basto:
>  > On Seg, 2014-09-22 at 16:08 +0200, Reindl Harald wrote:
>  >> no you refuse to understand that *nobody* wants to split
>  >> out *all* systemd logs because just the excessive *user
>  >> session* logging and that this messages should not exist
>  >> at all in a non-debugging environment
>  > 
>  > IIUC , this messages doesn't exist in a non-debugging environment since
>  > ends of Apr [1], or I shut up this messages somehow , I don't
>  > remember ...
>  
>  * i shut up them with "loginctl enable-linger"
>  * that's a workaround
>  * doing so in F20 to prevent forget with F21 leads to
>    another bug: https://bugzilla.redhat.com/show_bug.cgi?id=1088619#c54 
This message is from 2014-08-30 and is to fix shutdown, loginctl
disable-linger $USER, seems not reenable messages flood, if that what
you mean .

But please calm down , this is not a very big deal ..  

>  it is even *possible* that it was changed but if so it shows
>  several problems:
>  
>  * nobody knows, people already built workarounds
>  * it takes too long for any reaction on such issues
>    so that people can't or won't wait for a response
>    and try to find bugreports because lost hope that
>    things become better in a reasonable time
>  * the reaction close with "NOTABUG" after weeks of ignore is wrong
>  
>  frankly that was once introduced even in F19 backports and
>  quickly fixed while also point to "loginctl enable-linger"
>  which is *really* a dirty workaround leading the user sessions
>  are started at boot before the first cronjob fires up which
>  wastes ressources at boot
>  
>  only that it was fixed in a short because that backport was
>  not targeted for F19 shows how easy it could be changed if
>  upstream would care about downstream in any way
>  
>  look at the response from Johann directed to downstream in general,
>  Fedora and FeSCO in special and the repeatet responses "we are upstream
>  and this and that are downstream problems we don't care" shows how
>  terrible wrong things are going
>  
>  a upstream of a *critical core componentent* with a "i don't care
>  about downstream" attitude is only one thing: dangerous
>  
>   
-- 
Sérgio M. B.

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

[Reindl Harald]

Am 22.09.2014 um 17:18 schrieb Sérgio Basto:
>  On Seg, 2014-09-22 at 17:00 +0200, Reindl Harald wrote: 
> >
> > Am 22.09.2014 um 16:48 schrieb Sérgio Basto:
> >> On Seg, 2014-09-22 at 16:08 +0200, Reindl Harald wrote:
> >>> no you refuse to understand that *nobody* wants to split
> >>> out *all* systemd logs because just the excessive *user
> >>> session* logging and that this messages should not exist
> >>> at all in a non-debugging environment
> >>
> >> IIUC , this messages doesn't exist in a non-debugging environment since
> >> ends of Apr [1], or I shut up this messages somehow , I don't
> >> remember ...
> >
> > * i shut up them with "loginctl enable-linger"
> > * that's a workaround
> > * doing so in F20 to prevent forget with F21 leads to
> >   another bug: https://bugzilla.redhat.com/show_bug.cgi?id=1088619#c54
>  
>  This message is from 2014-08-30 and is to fix shutdown, loginctl
>  disable-linger $USER, seems not reenable messages flood, if that what
>  you mean .
>  
>  But please calm down , this is not a very big deal ..   
how it is handeled is a very big deal

* close bugreports without any further discussion
  after ignore them for weeks and pointed to on
  this mailing-list a minute later
* call downstream distributions inclduing Fesco names
* call enduser incompetent because they don't want to
  fix the systems behavior every time systemd decides
  to change it

the genreal attitude "that are downstream problems"
or "that are user problems" and "we are upstream" is
a very big deal for a core component

> > it is even *possible* that it was changed but if so it shows
> > several problems:
> >
> > * nobody knows, people already built workarounds
> > * it takes too long for any reaction on such issues
> >   so that people can't or won't wait for a response
> >   and try to find bugreports because lost hope that
> >   things become better in a reasonable time
> > * the reaction close with "NOTABUG" after weeks of ignore is wrong
> >
> > frankly that was once introduced even in F19 backports and
> > quickly fixed while also point to "loginctl enable-linger"
> > which is *really* a dirty workaround leading the user sessions
> > are started at boot before the first cronjob fires up which
> > wastes ressources at boot
> >
> > only that it was fixed in a short because that backport was
> > not targeted for F19 shows how easy it could be changed if
> > upstream would care about downstream in any way
> >
> > look at the response from Johann directed to downstream in general,
> > Fedora and FeSCO in special and the repeatet responses "we are upstream
> > and this and that are downstream problems we don't care" shows how
> > terrible wrong things are going
> >
> > a upstream of a *critical core componentent* with a "i don't care
> > about downstream" attitude is only one thing: dangerous

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

[Miloslav Trmač]

(stripping systemd-devel)

----- Original Message -----
>  Am 22.09.2014 um 14:44 schrieb Jóhann B. Guðmundsson:
>  > This is simply untrue as "journalctl -o export" will show you.
>  
>  where is it in the message?
>  the process is "systemd"
>  
>  how to distinct between user sessions and systemn boot?
>  ":programname" don't work and ":msg, startswith" don't work
>  
>  Mar 18 23:01:01 rawhide systemd[577]: Stopped target Default.
>  Mar 18 23:01:01 rawhide systemd[577]: Stopping Basic System.
>  Mar 18 23:01:01 rawhide systemd[577]: Stopped target Basic System.
>  Mar 18 23:01:01 rawhide systemd[577]: Stopping Paths. 
In Fedora’s default configuration, in addition to the traditional rsyslog fields, all
journal fields are available in rsyslog.  Would filtering for $_PID being, or not being,
1, help?
    Mirek

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

[Reindl Harald]

Am 22.09.2014 um 16:25 schrieb Miloslav Trmač:
>  (stripping systemd-devel)
>  
>  ----- Original Message -----
> > Am 22.09.2014 um 14:44 schrieb Jóhann B. Guðmundsson:
> >> This is simply untrue as "journalctl -o export" will show you.
> >
> > where is it in the message?
> > the process is "systemd"
> >
> > how to distinct between user sessions and systemn boot?
> > ":programname" don't work and ":msg, startswith" don't
> work
> >
> > Mar 18 23:01:01 rawhide systemd[577]: Stopped target Default.
> > Mar 18 23:01:01 rawhide systemd[577]: Stopping Basic System.
> > Mar 18 23:01:01 rawhide systemd[577]: Stopped target Basic System.
> > Mar 18 23:01:01 rawhide systemd[577]: Stopping Paths.
>  
>  In Fedora’s default configuration, in addition to the traditional rsyslog fields, 
>  all journal fields are available in rsyslog.  Would filtering for $_PID being, 
>  or not being, 1, help? 
possibly yes but i am still concerned that it is the wrong way
to add each year new rules to filter and drop a growing amount
of messages which should not exist in a non-debugging environment

* they produce load twcie (generate and filter)
* they lead to rotate the in memory journal more often
* nobody knows what a later release adds which falls in "systemd but not PID1"
  and would also be stripped
* the real solution has to be adressed upstream: reduce verbose level on
  a normal installation and create the noise only in debug levels

i really don't get why other software for decades knows different
log levels (informational, only warn, only critical errors) and
just systemd needs to go they way of "produce anything always"

that's hardly the attitude demanding long year users of Linux
systems to be all time friendly and nice when you day for day
give them the feeling of no care

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

[Jóhann B. Guðmundsson]

On 09/22/2014 02:25 PM, Miloslav Trmač wrote:
>  (stripping systemd-devel)
>
>  ----- Original Message -----
> > >Am 22.09.2014 um 14:44 schrieb Jóhann B. Guðmundsson:
> >> > >This is simply untrue as "journalctl -o export" will show
> you.
> > >
> > >where is it in the message?
> > >the process is "systemd"
> > >
> > >how to distinct between user sessions and systemn boot?
> > >":programname" don't work and ":msg, startswith"
> don't work
> > >
> > >Mar 18 23:01:01 rawhide systemd[577]: Stopped target Default.
> > >Mar 18 23:01:01 rawhide systemd[577]: Stopping Basic System.
> > >Mar 18 23:01:01 rawhide systemd[577]: Stopped target Basic System.
> > >Mar 18 23:01:01 rawhide systemd[577]: Stopping Paths.
>  In Fedora’s default configuration, in addition to the traditional rsyslog fields, all
> journal fields are available in rsyslog.  Would filtering for $_PID being, or not being,
> 1, help? 

For the journal you always keep all log history in it's original state 
since you never know what the users and administrator prefers ( some 
like all messages other just want error or critical and there might two 
or more administrators administrating the machine etc ) hence you should 
always use the powerful built in filtering capability in the journal to 
provide you with the exact output when you need it as opposed to be 
fiddling with syslog priority or finding and grepping through text files 
located somewhere on the filesystem and have to worry about log rotation 
( which implimentation is also broken for components in Fedora ).

For example if you want to see just error messages in the journal you 
use "journalctl -p 3" or "journalctl  -b -p 3" if you want it only
from 
last boot ( add boot id if you want to from specific boot ) or you add 
"journalctl  -b -p 3 -u httpd.service" if you want only the error 
messages for the apache daemon so fourth or so on.

If I was continuing to contribute to Fedora and I was continuing with my 
efforts cleaning up the log implementation in Fedora I would ( still ) 
be recommending that each service/daemon would provide it's own 
rsyslog.d and syslog-ng configuration files which would be packed and 
supplied in a separately log sub-package for a component ( and that 
sub-package depend on either rsyslog or syslog-ng and or had a virtual 
dependency ).

I would recommend that rsyslog and syslog-ng would ship with it's 
default configuration tailored for secure remote logging for centralized 
logging server ( for audit compliance, etc ) and have local file logging 
disabled by default.

I would also recommend that none of the WG's ship rsyslog by default ( 
since the administrator would have to configure rsyslog or syslog-ng to 
point to the centralized logging server so he can just as well install 
it the same time ).

But you go ahead and do what you think is best since I was not allowed 
to do this ( this and other related daemon/service components would not 
have been an issue for me since I had to go through all the components 
for the cleanup process I had in place so this would not have been such 
an added load for me to do at the same time ).

I suggest at the same time someone decided to fix this, he fixes the 
log-rotation implementation in the project in the process ( if I can 
recall correctly it was only implemented for 50 to 100 component out of 
600 )

JBG

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

[Miloslav Trmač]

----- Original Message -----
>  For example if you want to see just error messages in the journal
> you
>  use "journalctl -p 3" or "journalctl  -b -p 3" if you want it only
> from
>  last boot ( add boot id if you want to from specific boot ) or you add
>  "journalctl  -b -p 3 -u httpd.service" if you want only the error
>  messages for the apache daemon so fourth or so on. 
Harald was saying that this is one of the things he wants to do but can’t because both the
messages he wants and doesn’t want to record have the same priority.

I haven’t been able to find any obvious difference between cron-related and gdm-related
session open/close messages, but I have only given it about 5 minutes.  Can you actually
propose a working filter that would distinguish between these?
    Mirek

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

[Reindl Harald]

Am 22.09.2014 um 18:35 schrieb Miloslav Trmač:
>  ----- Original Message -----
> > For example if you want to see just error messages in the journal you
> > use "journalctl -p 3" or "journalctl  -b -p 3" if you want it
> only from
> > last boot ( add boot id if you want to from specific boot ) or you add
> > "journalctl  -b -p 3 -u httpd.service" if you want only the error
> > messages for the apache daemon so fourth or so on.
>  
>  Harald was saying that this is one of the things he wants to do but 
>  can’t because both the messages he wants and doesn’t want to record 
>  have the same priority. 
no - the point is that i don't use "journalctl" for a ton of
reasons which are too off-topic and *many* people don't and
will not also in the future

it is a big mistake upstream to ignore anything but journalctl

the general issue is "For the journal you always keep all log history"
which is the wrong way to go - for sure most users and administrators
don't prefer have aynthing logged as default, at least not all the
time and the few which want it that way are one reason more to make
it configureable in a sane way in "journalctl.conf"

* ship it with whatever defaults
* add the directive to control it commented with the possible options
* you are done, everybody is happy because there is one switch to adjust needs

but log all to journal and then try to filter it away somewhere
is pervert and wasting of ressources which can be used in a
better way and if it is only the CPU going in power safe mode
because nothing to do the whole night

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

[Jóhann B. Guðmundsson]

On 09/22/2014 04:35 PM, Miloslav Trmač wrote:
> > >For example if you want to see just error messages in the
> journal you
> > >use "journalctl -p 3" or "journalctl  -b -p 3" if you want it
> only from
> > >last boot ( add boot id if you want to from specific boot ) or you add
> > >"journalctl  -b -p 3 -u httpd.service" if you want only the error
> > >messages for the apache daemon so fourth or so on.
>  Harald was saying that this is one of the things he wants to do but can’t because both
> the messages he wants and doesn’t want to record have the same priority. 
You know as well as I do that we will not alter the priority label on 
messages sent from the program based on administrators inability to come 
up with filters in rsyslog. o_O

And for the record Harald is not using systemd journal he's using 
rsyslog and he's complaining about unnecessary entries in 
/var/log/messages which he could simply filter out all systemd related 
messages out of /var/log/messages and into it's own file by adding this 
entry to rsyslog.conf which you would not have to explain to a capable 
administrators because he would have already consulted upstream 
documentation how to achieve that.

":programname, isequal, "systemd" -/var/log/systemd.log"

or by more advanced rsyslog filter, which just filter the info message 
from the systemd daemon to the log file systemd

"if $programname == 'systemd' and $syslogseverity <= '6' 
/var/log/systemd.log"

And you can do a glorified mixing and matching if you so much like..

if ( $program contains "foobar" ) and ( $severity contains "err" )
then 
/var/log/foobar.log

etc etc etc consult upstream documentation for further example...

In systemd journal this is not a problem...

By default systemd will show the end user 3 log entries for each cron 
job that is run.

Two for the starting/startup of the session the user that is running the 
job, to show if that succeeded or not and one for the actual cron job 
being run

In this sample I'm telling the test cron job to echo the output into the 
journal and associated it with the syslog identifier CROND while doing 
so hence I have four entries.

# 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

Now if I dont want to see the systemd user session output I simply 
filter it further by telling the journal only to give me the syslog 
identifier for crond

# 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

Two line just what I want no fuzz no muzz, no chasing after log files, 
come up with complex filters and more time to the lazy admin I am and 
drink my beer...

JBG

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

[Reindl Harald]

Am 22.09.2014 um 19:37 schrieb Jóhann B. Guðmundsson:
>  
>  On 09/22/2014 04:35 PM, Miloslav Trmač wrote:
> >> >For example if you want to see just error messages in the journal you
> >> >use "journalctl -p 3" or "journalctl  -b -p 3" if you
> want it only from
> >> >last boot ( add boot id if you want to from specific boot ) or you add
> >> >"journalctl  -b -p 3 -u httpd.service" if you want only the error
> >> >messages for the apache daemon so fourth or so on.
> > Harald was saying that this is one of the things he wants to do but can’t because
> both the messages he wants and
> > doesn’t want to record have the same priority.
>  
>  You know as well as I do that we will not alter the priority label on messages sent from
> the program based on
>  administrators inability to come up with filters in rsyslog. o_O
>  
>  And for the record Harald is not using systemd journal he's using rsyslog and
> he's complaining about unnecessary
>  entries in /var/log/messages which he could simply filter out all systemd related
> messages out of /var/log/messages
>  and into it's own file by adding this entry to rsyslog.conf which you would not have
> to explain to a capable
>  administrators because he would have already consulted upstream documentation how to
> achieve that.
>  
>  ":programname, isequal, "systemd" -/var/log/systemd.log" 
i already explained why this is a bad idea

>  or by more advanced rsyslog filter, which just filter the info
> message from the systemd daemon to the log file systemd
>  
>  "if $programname == 'systemd' and $syslogseverity <= '6'
> /var/log/systemd.log" 
and who told you that this also don't flter out relevant messages?


on a non-debugging system that entries should not be
created at all - done properly and not blow debug
infos on non debug machines and there is nothing
which needs to be filtered

>  And you can do a glorified mixing and matching if you so much like..
>  
>  if ( $program contains "foobar" ) and ( $severity contains "err" )
> then /var/log/foobar.log
>  
>  etc etc etc consult upstream documentation for further example... 
fix it at the root cause
don't create a ton of entries for each starting cronjob

* nobody but systemd-developers needs them as default
* crond worked before some systemd developers learnd to speak

>  In systemd journal this is not a problem... 
it is a problem, independent how often you pretend the opposite

* only if it grows endlessly
* on rsyslog systems it limits the ability of "systemctl status" to show
  recent logs from the daemon because it get rotatet or you need to
  waste ressources multiple times
* on embedded devices it will always be a problem

>  By default systemd will show the end user 3 log entries for each cron
> job that is run. 
and by only log started / finished with a clear prefix until
there was an error it could show the whole day

wait - that info is logged by crond itself already

>  Two for the starting/startup of the session the user that is running
> the job, to show if that succeeded or not and
>  one for the actual cron job being run
>  
>  In this sample I'm telling the test cron job to echo the output into the journal and
> associated it with the syslog
>  identifier CROND while doing so hence I have four entries.
>  
>  # 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
>  
>  Now if I dont want to see the systemd user session output I simply filter it further by
> telling the journal only to
>  give me the syslog identifier for crond 
boah i am talking about the crap below forcing you to enbale
linger to get rid of triggering another systemd bug on
several machines leading to hang at shutdown for some
minutes - nice on production servers!

Mar  4 12:57:34 rawhide systemd[1]: Stopping User Manager for UID 0...
Mar  4 12:57:34 rawhide systemd[1482]: Stopping Default.
Mar  4 12:57:34 rawhide systemd[1482]: Stopped target Default.
Mar  4 12:57:34 rawhide systemd[1482]: Stopping Basic System.
Mar  4 12:57:34 rawhide systemd[1482]: Stopped target Basic System.
Mar  4 12:57:34 rawhide systemd[1482]: Stopping Paths.
Mar  4 12:57:34 rawhide systemd[1482]: Stopped target Paths.
Mar  4 12:57:34 rawhide systemd[1482]: Stopping Timers.
Mar  4 12:57:34 rawhide systemd[1482]: Stopped target Timers.
Mar  4 12:57:34 rawhide systemd[1482]: Stopping Sockets.
Mar  4 12:57:34 rawhide systemd[1482]: Stopped target Sockets.
Mar  4 12:57:34 rawhide systemd[1482]: Starting Shutdown.
Mar  4 12:57:34 rawhide systemd[1482]: Reached target Shutdown.
Mar  4 12:57:34 rawhide systemd[1482]: Starting Exit the Session...
Mar  4 12:57:34 rawhide systemd[1482]: Received SIGRTMIN+24 from PID 1551 (kill).
Mar  4 12:57:34 rawhide systemd[1]: Stopped User Manager for UID 0.
Mar  4 12:57:34 rawhide systemd[1]: Stopping user-0.slice.
Mar  4 12:57:34 rawhide systemd[1]: Removed slice user-0.slice.
Mar  4 13:01:01 rawhide systemd[1]: Starting user-0.slice.
Mar  4 13:01:01 rawhide systemd[1]: Created slice user-0.slice.
Mar  4 13:01:01 rawhide systemd[1]: Starting User Manager for UID 0...
Mar  4 13:01:01 rawhide systemd[1559]: Starting Paths.
Mar  4 13:01:01 rawhide systemd[1559]: Reached target Paths.
Mar  4 13:01:01 rawhide systemd[1559]: Starting Timers.
Mar  4 13:01:01 rawhide systemd[1559]: Reached target Timers.
Mar  4 13:01:01 rawhide systemd[1559]: Starting Sockets.
Mar  4 13:01:01 rawhide systemd[1559]: Reached target Sockets.
Mar  4 13:01:01 rawhide systemd[1559]: Starting Basic System.
Mar  4 13:01:01 rawhide systemd[1559]: Reached target Basic System.
Mar  4 13:01:01 rawhide systemd[1559]: Starting Default.
Mar  4 13:01:01 rawhide systemd[1559]: Reached target Default.
Mar  4 13:01:01 rawhide systemd[1559]: Startup finished in 9ms.
Mar  4 13:01:01 rawhide systemd[1]: Started User Manager for UID 0.
Mar  4 13:01:01 rawhide systemd[1]: Stopping User Manager for UID 0...
Mar  4 13:01:01 rawhide systemd[1559]: Stopping Default.
Mar  4 13:01:01 rawhide systemd[1559]: Stopped target Default.
Mar  4 13:01:01 rawhide systemd[1559]: Stopping Basic System.
Mar  4 13:01:01 rawhide systemd[1559]: Stopped target Basic

>  # 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
>  
>  Two line just what I want no fuzz no muzz, no chasing after log files, come up with
> complex filters and more time
>  to the lazy admin I am and drink my beer... 
if you would only click on the links somebody provides before
abuse users, Fedora and Fesco as you did with your first reply
on the systemd-list which was the reason for cross-posting

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

[Reindl Harald]

Am 22.09.2014 um 19:51 schrieb Reindl Harald:
>  Am 22.09.2014 um 19:37 schrieb Jóhann B. Guðmundsson:
> >
> > On 09/22/2014 04:35 PM, Miloslav Trmač wrote:
> >>>> For example if you want to see just error messages in the journal you
> >>>> use "journalctl -p 3" or "journalctl  -b -p 3" if you
> want it only from
> >>>> last boot ( add boot id if you want to from specific boot ) or you add
> >>>> "journalctl  -b -p 3 -u httpd.service" if you want only the
> error
> >>>> messages for the apache daemon so fourth or so on.
> >> Harald was saying that this is one of the things he wants to do but can’t because
> both the messages he wants and
> >> doesn’t want to record have the same priority.
> >
> > You know as well as I do that we will not alter the priority label on messages sent
> from the program based on
> > administrators inability to come up with filters in rsyslog. o_O
> >
> > And for the record Harald is not using systemd journal he's using rsyslog and
> he's complaining about unnecessary
> > entries in /var/log/messages which he could simply filter out all systemd related
> messages out of /var/log/messages
> > and into it's own file by adding this entry to rsyslog.conf which you would not
> have to explain to a capable
> > administrators because he would have already consulted upstream documentation how to
> achieve that.
> >
> > ":programname, isequal, "systemd" -/var/log/systemd.log"
>  
>  i already explained why this is a bad idea
>  
> > or by more advanced rsyslog filter, which just filter the info message from the
> systemd daemon to the log file systemd
> >
> > "if $programname == 'systemd' and $syslogseverity <= '6'
> /var/log/systemd.log"
>  
>  and who told you that this also don't flter out relevant messages? 
to be precise the "capable administrator" wrote way too much such
rules in the past just because systemd, but that ones laking
a simple "user-session" in the message to define clear what
should go to a own file

the same time ignorant and abusive people like you call
other incompetent could be used to just make the messages
clear, a part of that over the time growing amount of
messages notify about the same what crond anyways do
can be filtered - the rest not really

 # Log systemd-logind to /var/log/secure
:programname, isequal, "systemd-logind"             -/var/log/secure
:programname, isequal, "systemd-logind" stop
:msg, contains, "Starting Session" stop
:msg, contains, "Started Session" stop
:msg, contains, "Stopping Session" stop
:msg, contains, "Stopped Session" stop

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

[Jóhann B. Guðmundsson]

On 09/22/2014 06:17 PM, Reindl Harald wrote:
>  # Log systemd-logind to /var/log/secure
>  :programname, isequal, "systemd-logind"             -/var/log/secure
>  :programname, isequal, "systemd-logind" stop
>  :msg, contains, "Starting Session" stop
>  :msg, contains, "Started Session" stop
>  :msg, contains, "Stopping Session" stop
>  :msg, contains, "Stopped Session" stop
>  
And the problem that was stuck between your chair and your keyboard 
exist no more so congratulation finally being able to consult upstream 
--> rsyslog <-- documentation after being spoon feed several examples on 
how this could be accomplished.

Hopefully you will live happily ever after after this great achievement 
in your life and can share this new found experience with the rsyslog 
maintainer here in Fedora so he can provide better out of the box 
default filter suited especially for *your* filtering needs.

Now be a good sport and close all those bugs that you filed against 
systemd in bz.rh or don't reopen them if Lennart or someone else does...

And next time, try to refrain yourself from calling the lead developer 
of the project an idiot and you might find yourself in a situation where 
you are met with a more willingness, more welcoming and more positive 
attitude in helping you solve whatever problem you are faced with at 
that time. I might even go ahead and provide you with the exact solution 
next time.

JBG

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

[Reindl Harald]

Am 22.09.2014 um 21:00 schrieb Jóhann B. Guðmundsson:
>  On 09/22/2014 06:17 PM, Reindl Harald wrote:
> > # Log systemd-logind to /var/log/secure
> > :programname, isequal, "systemd-logind"             -/var/log/secure
> > :programname, isequal, "systemd-logind" stop
> > :msg, contains, "Starting Session" stop
> > :msg, contains, "Started Session" stop
> > :msg, contains, "Stopping Session" stop
> > :msg, contains, "Stopped Session" stop
> >
>  
>  And the problem that was stuck between your chair and your keyboard exist no more so
> congratulation finally being
>  able to consult upstream --> rsyslog <-- documentation after being spoon feed
> several examples on how this could be
>  accomplished 
please refrain from responses if you don't understand what people
are talking about - the above *do not have any effect on the crap
below* except two lines out of a lot

i only posted that above to heal you from your arrogance about
read rsyslog and that a decent admin knows rsyslog filters

NOTHING OF THE FLLOD BELOW CAN BE CATCHED THAT WAY
https://bugzilla.redhat.com/show_bug.cgi?id=1072368

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

[Reindl Harald]

Am 22.09.2014 um 21:05 schrieb Reindl Harald:
>  Am 22.09.2014 um 21:00 schrieb Jóhann B. Guðmundsson:
> > On 09/22/2014 06:17 PM, Reindl Harald wrote:
> >> # Log systemd-logind to /var/log/secure
> >> :programname, isequal, "systemd-logind"             -/var/log/secure
> >> :programname, isequal, "systemd-logind" stop
> >> :msg, contains, "Starting Session" stop
> >> :msg, contains, "Started Session" stop
> >> :msg, contains, "Stopping Session" stop
> >> :msg, contains, "Stopped Session" stop
> >>
> >
> > And the problem that was stuck between your chair and your keyboard exist no more so
> congratulation finally being
> > able to consult upstream --> rsyslog <-- documentation after being spoon feed
> several examples on how this could be
> > accomplished
>  
>  please refrain from responses if you don't understand what people
>  are talking about - the above *do not have any effect on the crap
>  below* except two lines out of a lot
>  
>  i only posted that above to heal you from your arrogance about
>  read rsyslog and that a decent admin knows rsyslog filters
>  
>  NOTHING OF THE FLLOD BELOW CAN BE CATCHED THAT WAY
>  https://bugzilla.redhat.com/show_bug.cgi?id=1072368
________________________________________

and the next time don't remove the relevant part *before* what
you quote or at least read it before strip, not that nobody
can read the whole post but your quoting style is abusive

BTW. you still refuse to understand that produce that lot
of messages *is wrong* in *non-debugging* mode

-------- Weitergeleitete Nachricht --------
Betreff: Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and
resistance
Datum: Mon, 22 Sep 2014 20:17:38 +0200
Von: Reindl Harald <h.reindl(a)thelounge.net&gt;
Antwort an: Development discussions related to Fedora
<devel(a)lists.fedoraproject.org&gt;
An: devel(a)lists.fedoraproject.org

Am 22.09.2014 um 19:51 schrieb Reindl Harald:
>  Am 22.09.2014 um 19:37 schrieb Jóhann B. Guðmundsson:
> > You know as well as I do that we will not alter the priority label on messages sent
> from the program based on
> > administrators inability to come up with filters in rsyslog. 
to be precise the "capable administrator" wrote way too much such
rules in the past just because systemd, but that ones laking
a simple "user-session" in the message to define clear what
should go to a own file

the same time ignorant and abusive people like you call
other incompetent could be used to just make the messages
clear, a part of that over the time growing amount of
messages notify about the same what crond anyways do
can be filtered - the rest not really

 # Log systemd-logind to /var/log/secure
:programname, isequal, "systemd-logind"             -/var/log/secure
:programname, isequal, "systemd-logind" stop
:msg, contains, "Starting Session" stop
:msg, contains, "Started Session" stop
:msg, contains, "Stopping Session" stop
:msg, contains, "Stopped Session" stop
____________________________________________________________________

the crap below is *not* filterable and it would be *easy*
to start any of this entries with "systemd-user" for
upstream


Mar 15 08:01:01 rawhide systemd[1378]: Stopping Default.
Mar 15 08:01:01 rawhide systemd[1378]: Stopped target Default.
Mar 15 08:01:01 rawhide systemd[1378]: Stopping Basic System.
Mar 15 08:01:01 rawhide systemd[1378]: Stopped target Basic System.
Mar 15 08:01:01 rawhide systemd[1378]: Stopping Paths.
Mar 15 08:01:01 rawhide systemd[1378]: Stopped target Paths.
Mar 15 08:01:01 rawhide systemd[1378]: Stopping Timers.
Mar 15 08:01:01 rawhide systemd[1378]: Stopped target Timers.
Mar 15 08:01:01 rawhide systemd[1378]: Stopping Sockets.
Mar 15 08:01:01 rawhide systemd[1378]: Stopped target Sockets.
Mar 15 08:01:01 rawhide systemd[1378]: Starting Shutdown.
Mar 15 08:01:01 rawhide systemd[1378]: Reached target Shutdown.
Mar 15 08:01:01 rawhide systemd[1378]: Starting Exit the Session...
Mar 15 08:01:01 rawhide systemd[1378]: Received SIGRTMIN+24 from PID 1407 (kill).
Mar 15 08:01:01 rawhide systemd[1]: Stopped User Manager for UID 0.
Mar 15 08:01:01 rawhide systemd[1]: Stopping user-0.slice.
Mar 15 08:01:01 rawhide systemd[1]: Removed slice user-0.slice.
Mar 15 09:01:01 rawhide systemd[1]: Starting user-0.slice.
Mar 15 09:01:01 rawhide systemd[1]: Created slice user-0.slice.
Mar 15 09:01:01 rawhide systemd[1]: Starting User Manager for UID 0...
Mar 15 09:01:01 rawhide systemd[1416]: Starting Paths.
Mar 15 09:01:01 rawhide systemd[1416]: Reached target Paths.
Mar 15 09:01:01 rawhide systemd[1416]: Starting Timers.
Mar 15 09:01:01 rawhide systemd[1416]: Reached target Timers.
Mar 15 09:01:01 rawhide systemd[1416]: Starting Sockets.
Mar 15 09:01:01 rawhide systemd[1416]: Reached target Sockets.
Mar 15 09:01:01 rawhide systemd[1416]: Starting Basic System.
Mar 15 09:01:01 rawhide systemd[1416]: Reached target Basic System.
Mar 15 09:01:01 rawhide systemd[1416]: Starting Default.
Mar 15 09:01:01 rawhide systemd[1416]: Reached target Default.
Mar 15 09:01:01 rawhide systemd[1416]: Startup finished in 9ms.
Mar 15 09:01:01 rawhide systemd[1]: Started User Manager for UID 0.
Mar 15 09:01:01 rawhide systemd[1]: Stopping User Manager for UID 0...
Mar 15 09:01:01 rawhide systemd[1416]: Stopping Default.
Mar 15 09:01:01 rawhide systemd[1416]: Stopped target Default.
Mar 15 09:01:01 rawhide systemd[1416]: Stopping Basic System.
Mar 15 09:01:01 rawhide systemd[1416]: Stopped target Basic System.
Mar 15 09:01:01 rawhide systemd[1416]: Stopping Paths.
Mar 15 09:01:01 rawhide systemd[1416]: Stopped target Paths.
Mar 15 09:01:01 rawhide systemd[1416]: Stopping Timers.
Mar 15 09:01:01 rawhide systemd[1416]: Stopped target Timers.
Mar 15 09:01:01 rawhide systemd[1416]: Stopping Sockets.
Mar 15 09:01:01 rawhide systemd[1416]: Stopped target Sockets.
Mar 15 09:01:01 rawhide systemd[1416]: Starting Shutdown.
Mar 15 09:01:01 rawhide systemd[1416]: Reached target Shutdown.
Mar 15 09:01:01 rawhide systemd[1416]: Starting Exit the Session...
Mar 15 09:01:01 rawhide systemd[1416]: Received SIGRTMIN+24 from PID 1445 (kill).
Mar 15 09:01:01 rawhide systemd[1]: Stopped User Manager for UID 0.
Mar 15 09:01:01 rawhide systemd[1]: Stopping user-0.slice.
Mar 15 09:01:01 rawhide systemd[1]: Removed slice user-0.slice.
Mar 15 10:01:01 rawhide systemd[1]: Starting user-0.slice.
Mar 15 10:01:01 rawhide systemd[1]: Created slice user-0.slice.
Mar 15 10:01:01 rawhide systemd[1]: Starting User Manager for UID 0...
Mar 15 10:01:01 rawhide systemd[1454]: Starting Paths.
Mar 15 10:01:01 rawhide systemd[1454]: Reached target Paths.
Mar 15 10:01:01 rawhide systemd[1454]: Starting Timers.
Mar 15 10:01:01 rawhide systemd[1454]: Reached target Timers.
Mar 15 10:01:01 rawhide systemd[1454]: Starting Sockets.
Mar 15 10:01:01 rawhide systemd[1454]: Reached target Sockets.
Mar 15 10:01:01 rawhide systemd[1454]: Starting Basic System.
Mar 15 10:01:01 rawhide systemd[1454]: Reached target Basic System.
Mar 15 10:01:01 rawhide systemd[1454]: Starting Default.
Mar 15 10:01:01 rawhide systemd[1454]: Reached target Default.
Mar 15 10:01:01 rawhide systemd[1454]: Startup finished in 11ms.
Mar 15 10:01:01 rawhide systemd[1]: Started User Manager for UID 0.
Mar 15 10:01:01 rawhide systemd[1]: Stopping User Manager for UID 0...
Mar 15 10:01:01 rawhide systemd[1454]: Stopping Default.
Mar 15 10:01:01 rawhide systemd[1454]: Stopped target Default.
Mar 15 10:01:01 rawhide systemd[1454]: Stopping Basic System.
Mar 15 10:01:01 rawhide systemd[1454]: Stopped target Basic System.
Mar 15 10:01:01 rawhide systemd[1454]: Stopping Paths.
Mar 15 10:01:01 rawhide systemd[1454]: Stopped target Paths.
Mar 15 10:01:01 rawhide systemd[1454]: Stopping Timers.
Mar 15 10:01:01 rawhide systemd[1454]: Stopped target Timers.
Mar 15 10:01:01 rawhide systemd[1454]: Stopping Sockets.
Mar 15 10:01:01 rawhide systemd[1454]: Stopped target Sockets.
Mar 15 10:01:01 rawhide systemd[1454]: Starting Shutdown.
Mar 15 10:01:01 rawhide systemd[1454]: Reached target Shutdown.
Mar 15 10:01:01 rawhide systemd[1454]: Starting Exit the Session...
Mar 15 10:01:01 rawhide systemd[1454]: Received SIGRTMIN+24 from PID 1483 (kill).
Mar 15 10:01:01 rawhide systemd[1]: Stopped User Manager for UID 0.
Mar 15 10:01:01 rawhide systemd[1]: Stopping user-0.slice.
Mar 15 10:01:01 rawhide systemd[1]: Removed slice user-0.slice.
Mar 15 11:01:01 rawhide systemd[1]: Starting user-0.slice.
Mar 15 11:01:01 rawhide systemd[1]: Created slice user-0.slice.
Mar 15 11:01:01 rawhide systemd[1]: Starting User Manager for UID 0...
Mar 15 11:01:01 rawhide systemd[1491]: Starting Paths.
Mar 15 11:01:01 rawhide systemd[1491]: Reached target Paths.
Mar 15 11:01:01 rawhide systemd[1491]: Starting Timers.
Mar 15 11:01:01 rawhide systemd[1491]: Reached target Timers.
Mar 15 11:01:01 rawhide systemd[1491]: Starting Sockets.
Mar 15 11:01:01 rawhide systemd[1491]: Reached target Sockets.
Mar 15 11:01:01 rawhide systemd[1491]: Starting Basic System.
Mar 15 11:01:01 rawhide systemd[1491]: Reached target Basic System.
Mar 15 11:01:01 rawhide systemd[1491]: Starting Default.
Mar 15 11:01:01 rawhide systemd[1491]: Reached target Default.
Mar 15 11:01:01 rawhide systemd[1491]: Startup finished in 10ms.
Mar 15 11:01:01 rawhide systemd[1]: Started User Manager for UID 0.
Mar 15 11:01:01 rawhide systemd[1]: Stopping User Manager for UID 0...
Mar 15 11:01:01 rawhide systemd[1491]: Stopping Default.
Mar 15 11:01:01 rawhide systemd[1491]: Stopped target Default.
Mar 15 11:01:01 rawhide systemd[1491]: Stopping Basic System.
Mar 15 11:01:01 rawhide systemd[1491]: Stopped target Basic System.
Mar 15 11:01:01 rawhide systemd[1491]: Stopping Paths.
Mar 15 11:01:01 rawhide systemd[1491]: Stopped target Paths.
Mar 15 11:01:01 rawhide systemd[1491]: Stopping Timers.
Mar 15 11:01:01 rawhide systemd[1491]: Stopped target Timers.
Mar 15 11:01:01 rawhide systemd[1491]: Stopping Sockets.
Mar 15 11:01:01 rawhide systemd[1491]: Stopped target Sockets.
Mar 15 11:01:01 rawhide systemd[1491]: Starting Shutdown.
Mar 15 11:01:01 rawhide systemd[1491]: Reached target Shutdown.
Mar 15 11:01:01 rawhide systemd[1491]: Starting Exit the Session...
Mar 15 11:01:01 rawhide systemd[1491]: Received SIGRTMIN+24 from PID 1520 (kill).
Mar 15 11:01:01 rawhide systemd[1]: Stopped User Manager for UID 0.
Mar 15 11:01:01 rawhide systemd[1]: Stopping user-0.slice.
Mar 15 11:01:01 rawhide systemd[1]: Removed slice user-0.slice.
Mar 15 12:01:01 rawhide systemd[1]: Starting user-0.slice.
Mar 15 12:01:01 rawhide systemd[1]: Created slice user-0.slice.
Mar 15 12:01:01 rawhide systemd[1]: Starting User Manager for UID 0...
Mar 15 12:01:01 rawhide systemd[1528]: Starting Paths.
Mar 15 12:01:01 rawhide systemd[1528]: Reached target Paths.
Mar 15 12:01:01 rawhide systemd[1528]: Starting Timers.
Mar 15 12:01:01 rawhide systemd[1528]: Reached target Timers.
Mar 15 12:01:01 rawhide systemd[1528]: Starting Sockets.
Mar 15 12:01:01 rawhide systemd[1528]: Reached target Sockets.
Mar 15 12:01:01 rawhide systemd[1528]: Starting Basic System.
Mar 15 12:01:01 rawhide systemd[1528]: Reached target Basic System.
Mar 15 12:01:01 rawhide systemd[1528]: Starting Default.
Mar 15 12:01:01 rawhide systemd[1528]: Reached target Default.
Mar 15 12:01:01 rawhide systemd[1528]: Startup finished in 10ms.
Mar 15 12:01:01 rawhide systemd[1]: Started User Manager for UID 0.
Mar 15 12:01:01 rawhide systemd[1]: Stopping User Manager for UID 0...
Mar 15 12:01:01 rawhide systemd[1528]: Stopping Default.
Mar 15 12:01:01 rawhide systemd[1528]: Stopped target Default.
Mar 15 12:01:01 rawhide systemd[1528]: Stopping Basic System.
Mar 15 12:01:01 rawhide systemd[1528]: Stopped target Basic System.
Mar 15 12:01:01 rawhide systemd[1528]: Stopping Paths.
Mar 15 12:01:01 rawhide systemd[1528]: Stopped target Paths.
Mar 15 12:01:01 rawhide systemd[1528]: Stopping Timers.
Mar 15 12:01:01 rawhide systemd[1528]: Stopped target Timers.
Mar 15 12:01:01 rawhide systemd[1528]: Stopping Sockets.
Mar 15 12:01:01 rawhide systemd[1528]: Stopped target Sockets.
Mar 15 12:01:01 rawhide systemd[1528]: Starting Shutdown.
Mar 15 12:01:01 rawhide systemd[1528]: Reached target Shutdown.
Mar 15 12:01:01 rawhide systemd[1528]: Starting Exit the Session...
Mar 15 12:01:01 rawhide systemd[1528]: Received SIGRTMIN+24 from PID 1557 (kill).
Mar 15 12:01:01 rawhide systemd[1]: Stopped User Manager for UID 0.
Mar 15 12:01:01 rawhide systemd[1]: Stopping user-0.slice.
Mar 15 12:01:01 rawhide systemd[1]: Removed slice user-0.slice.
Mar 15 12:38:56 rawhide systemd[1]: Starting user-0.slice.
Mar 15 12:38:56 rawhide systemd[1]: Created slice user-0.slice.
Mar 15 12:38:56 rawhide systemd[1]: Starting User Manager for UID 0...
Mar 15 12:38:56 rawhide systemd[1582]: Starting Paths.
Mar 15 12:38:56 rawhide systemd[1582]: Reached target Paths.
Mar 15 12:38:56 rawhide systemd[1582]: Starting Timers.
Mar 15 12:38:56 rawhide systemd[1582]: Reached target Timers.
Mar 15 12:38:56 rawhide systemd[1582]: Starting Sockets.
Mar 15 12:38:56 rawhide systemd[1582]: Reached target Sockets.
Mar 15 12:38:56 rawhide systemd[1582]: Starting Basic System.
Mar 15 12:38:56 rawhide systemd[1582]: Reached target Basic System.
Mar 15 12:38:56 rawhide systemd[1582]: Starting Default.
Mar 15 12:38:56 rawhide systemd[1582]: Reached target Default.
Mar 15 12:38:56 rawhide systemd[1582]: Startup finished in 9ms.
Mar 15 12:38:56 rawhide systemd[1]: Started User Manager for UID 0.

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

[Matthew Miller]

Seriously, both of you: this back and forth (and particularly the personal
squabbling!) do not help us with Fedora development, which is what this list
is for. If there's a problem somewhere here which we can address, let's talk
about technical problems and solutions. Or if there are upstream issues,
please take them upstream.

If you feel like someone else on the list is responding in a
non-constructive way,  you don't "win" by doubling down on that. You're
not
going to convince the other party, and the fighting doesn't convince anyone
else either.

You win by taking the high road: 
<https://www.youtube.com/watch?v=NHWjlCaIrQo>


-- 
Matthew Miller
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader

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

[DJ Delorie]

>  For the journal you always keep all log history in it's original
>  state 
On low-bandwidth systems, like laptops or diskless nodes, it's a
performance hit to generate the log entry in the first place.  It's
really important to be able to configure the system to *generate* a
minimal amount of communications.  Being able to filter the results
later is a separate issue.

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

[Haïkel]

Please avoid cross-posting in the middle of a thread without contextualization.

Regards,
H.

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

[Jóhann B. Guðmundsson]

On 09/22/2014 04:53 PM, DJ Delorie wrote:
> > For the journal you always keep all log history in it's
> original
> > state
>  On low-bandwidth systems, like laptops or diskless nodes, it's a
>  performance hit to generate the log entry in the first place.  It's
>  really important to be able to configure the system to *generate* a
>  minimal amount of communications.  Being able to filter the results
>  later is a separate issue. 

See man journald.conf for "tweakage" in that regard

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

[Przemek Klosowski]

On 09/22/2014 12:53 PM, DJ Delorie wrote:
> > For the journal you always keep all log history in it's
> original
> > state
>  On low-bandwidth systems, like laptops or diskless nodes, it's a
>  performance hit to generate the log entry in the first place.  It's
>  really important to be able to configure the system to *generate* a
>  minimal amount of communications.  Being able to filter the results
>  later is a separate issue. 
That's a very good point: many systems do not fall
into the 'infinite 
disk' desktop-like category. Case in point: embedded systems like 
Beaglebone, Rasberry Pi, etc.: their entire disk is 2GB of flash 
storage. Logging is still useful for them but needs to be very flexible 
and minimal.

We could say that Fedora just isn't interested in them, but that would 
be a mistake. There's nothing technological that precludes Fedora from 
running them (they often run Debian), and the spirit of discipline and 
efficiency that such small systems require would be a good  thing even 
for the desktop.

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

[Jóhann B. Guðmundsson]

On 09/23/2014 04:15 PM, Przemek Klosowski wrote:
>  On 09/22/2014 12:53 PM, DJ Delorie wrote:
> >> For the journal you always keep all log history in it's original
> >> state
> > On low-bandwidth systems, like laptops or diskless nodes, it's a
> > performance hit to generate the log entry in the first place.  It's
> > really important to be able to configure the system to *generate* a
> > minimal amount of communications.  Being able to filter the results
> > later is a separate issue.
>  That's a very good point: many systems do not fall into the 'infinite 
>  disk' desktop-like category. Case in point: embedded systems like 
>  Beaglebone, Rasberry Pi, etc.: their entire disk is 2GB of flash 
>  storage. Logging is still useful for them but needs to be very 
>  flexible and minimal. 
There seems to be some common misconception that systemd is not being in 
use by the embedded crowd or does not adhere to their needs but the 
embedded system you are mentioning there are already using systemd and 
journal along with few more and their journal ( journald.conf ) settings 
usually boil down to something like this and serves their need...

[Journal]
Storage=none
SystemMaxUse=10M
MaxLevelStore=info
MaxLevelSyslog=info

JBG

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

[Reindl Harald]

Am 23.09.2014 um 19:41 schrieb Jóhann B. Guðmundsson:
>  On 09/23/2014 04:15 PM, Przemek Klosowski wrote:
> > On 09/22/2014 12:53 PM, DJ Delorie wrote:
> >>> For the journal you always keep all log history in it's original
> >>> state
> >> On low-bandwidth systems, like laptops or diskless nodes, it's a
> >> performance hit to generate the log entry in the first place.  It's
> >> really important to be able to configure the system to *generate* a
> >> minimal amount of communications.  Being able to filter the results
> >> later is a separate issue.
> > That's a very good point: many systems do not fall into the 'infinite
> disk' desktop-like category. Case in point:
> > embedded systems like Beaglebone, Rasberry Pi, etc.: their entire disk is 2GB of
> flash storage. Logging is still
> > useful for them but needs to be very flexible and minimal.
>  
>  There seems to be some common misconception that systemd is not being in use by the
> embedded crowd or does not
>  adhere to their needs but the embedded system you are mentioning there are already using
> systemd and journal along
>  with few more and their journal ( journald.conf ) settings usually boil down to something
> like this and serves
>  their need...
>  
>  [Journal]
>  Storage=none
>  SystemMaxUse=10M
>  MaxLevelStore=info
>  MaxLevelSyslog=info 
that may all be true

but the above configuration leads to supress possible interesting
messages from daemons which not flood the log and is only needed
because some components are more verbose than needed for normal
operations instead get only verbose in a debug-level

in normal operations you only need two events logged in case of
a cronjob a) started and b) finished which does crond anyways