Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance
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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance
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 signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance
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 signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance
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 signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance
(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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance
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 signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance
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. signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance
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 signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance
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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance
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 signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance
- 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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance
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 signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance
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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance
Please avoid cross-posting in the middle of a thread without contextualization. Regards, H. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance
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
Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance
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 signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance
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 signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance
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.rei...@thelounge.net Antwort an: Development discussions related to Fedora devel@lists.fedoraproject.org An: devel@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
Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance
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 mat...@fedoraproject.org Fedora Project Leader -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
