Discussion:
[systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance
(too old to reply)
Reindl Harald
2014-09-22 12:58:46 UTC
Permalink
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

-------------- 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.fedoraproject.org/pipermail/devel/attachments/20140922/1f2a85b4/attachment.sig>
&quot;Jóhann B. Guðmundsson&quot;
2014-09-22 13:55:41 UTC
Permalink
Post by Reindl Harald
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20140922/91e48750/attachment.html>
Reindl Harald
2014-09-22 14:08:18 UTC
Permalink
Post by Reindl Harald
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
-------------- 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.fedoraproject.org/pipermail/devel/attachments/20140922/ef7d8459/attachment.sig>
Sérgio Basto
2014-09-22 14:48:23 UTC
Permalink
Post by Reindl Harald
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: This is a digitally signed message part
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20140922/35edff63/attachment.sig>
Reindl Harald
2014-09-22 15:00:18 UTC
Permalink
Post by Sérgio Basto
Post by Reindl Harald
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


-------------- 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.fedoraproject.org/pipermail/devel/attachments/20140922/24a8549e/attachment.sig>
Sérgio Basto
2014-09-22 15:18:38 UTC
Permalink
Post by Reindl Harald
Post by Sérgio Basto
Post by Reindl Harald
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 ..
Post by Reindl Harald
it is even *possible* that it was changed but if so it shows
* 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.
Reindl Harald
2014-09-22 15:22:43 UTC
Permalink
Post by Sérgio Basto
Post by Reindl Harald
Post by Sérgio Basto
Post by Reindl Harald
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
Post by Sérgio Basto
Post by Reindl Harald
it is even *possible* that it was changed but if so it shows
* 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
-------------- 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.fedoraproject.org/pipermail/devel/attachments/20140922/ce41909f/attachment.sig>
Miloslav Trmač
2014-09-22 14:25:13 UTC
Permalink
(stripping systemd-devel)

----- Original Message -----
Post by Reindl Harald
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
Reindl Harald
2014-09-22 14:35:40 UTC
Permalink
Post by Miloslav Trmač
(stripping systemd-devel)
----- Original Message -----
Post by Reindl Harald
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

-------------- 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.fedoraproject.org/pipermail/devel/attachments/20140922/bbadd91f/attachment-0001.sig>
&quot;Jóhann B. Guðmundsson&quot;
2014-09-22 16:25:16 UTC
Permalink
Post by Miloslav Trmač
(stripping systemd-devel)
----- Original Message -----
Post by Reindl Harald
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
Miloslav Trmač
2014-09-22 16:35:12 UTC
Permalink
----- Original Message -----
Post by &quot;Jóhann B. Guðmundsson&quot;
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
Reindl Harald
2014-09-22 16:48:58 UTC
Permalink
Post by Miloslav Trmač
----- Original Message -----
Post by &quot;Jóhann B. Guðmundsson&quot;
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



-------------- 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.fedoraproject.org/pipermail/devel/attachments/20140922/6eb5029e/attachment.sig>
&quot;Jóhann B. Guðmundsson&quot;
2014-09-22 17:37:24 UTC
Permalink
Post by Miloslav Trmač
Post by &quot;Jóhann B. Guðmundsson&quot;
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
Reindl Harald
2014-09-22 17:51:55 UTC
Permalink
Post by Miloslav Trmač
Post by &quot;Jóhann B. Guðmundsson&quot;
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



-------------- 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.fedoraproject.org/pipermail/devel/attachments/20140922/cbd3196b/attachment.sig>
Reindl Harald
2014-09-22 18:17:38 UTC
Permalink
Post by Reindl Harald
Post by Miloslav Trmač
Post by &quot;Jóhann B. Guðmundsson&quot;
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

-------------- 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.fedoraproject.org/pipermail/devel/attachments/20140922/d4ee854b/attachment.sig>
&quot;Jóhann B. Guðmundsson&quot;
2014-09-22 19:00:02 UTC
Permalink
Post by Reindl Harald
# 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20140922/410f0710/attachment.html>
Reindl Harald
2014-09-22 19:05:22 UTC
Permalink
Post by Reindl Harald
# 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

-------------- 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.fedoraproject.org/pipermail/devel/attachments/20140922/6daaac02/attachment.sig>
Reindl Harald
2014-09-22 19:15:54 UTC
Permalink
Post by Reindl Harald
Post by Reindl Harald
# 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 at thelounge.net>
Antwort an: Development discussions related to Fedora <devel at lists.fedoraproject.org>
An: devel at lists.fedoraproject.org
Post by Reindl Harald
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.

-------------- 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.fedoraproject.org/pipermail/devel/attachments/20140922/75853c16/attachment.sig>
Matthew Miller
2014-09-23 02:09:13 UTC
Permalink
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:

--
Matthew Miller
<mattdm at fedoraproject.org>
Fedora Project Leader
DJ Delorie
2014-09-22 16:53:32 UTC
Permalink
Post by &quot;Jóhann B. Guðmundsson&quot;
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.
Haïkel
2014-09-22 16:58:35 UTC
Permalink
Please avoid cross-posting in the middle of a thread without contextualization.

Regards,
H.
&quot;Jóhann B. Guðmundsson&quot;
2014-09-22 18:24:50 UTC
Permalink
Post by DJ Delorie
Post by &quot;Jóhann B. Guðmundsson&quot;
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
Przemek Klosowski
2014-09-23 16:15:04 UTC
Permalink
Post by DJ Delorie
Post by &quot;Jóhann B. Guðmundsson&quot;
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20140923/1890227b/attachment.html>
&quot;Jóhann B. Guðmundsson&quot;
2014-09-23 17:41:43 UTC
Permalink
Post by Przemek Klosowski
Post by DJ Delorie
Post by &quot;Jóhann B. Guðmundsson&quot;
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20140923/83947fcd/attachment.html>
Reindl Harald
2014-09-23 18:08:45 UTC
Permalink
Post by DJ Delorie
Post by &quot;Jóhann B. Guðmundsson&quot;
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.
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

-------------- 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.fedoraproject.org/pipermail/devel/attachments/20140923/e88d5432/attachment.sig>
Continue reading on narkive:
Loading...