Re: [systemd-devel] How to quiet cron sessions logging with systemd-212?
On Mon, 09.06.14 12:01, Mantas Mikulėnas (graw...@gmail.com) wrote: I think there's also another problem – logind starts the user manager instance for cronjobs while it shouldn't do so for batch stuff. Probably a PAM configuration issue. Nope. This is intentional. A session is a session is a session, and we should provide the same functionality to all session,s including all services on the bus and all services systemd manages... We shouldn't end up providing only half a session if the trigger for something was only time, instead of some other reason... That said, certain system-level cronjobs should probably not be PAM sessions... PAM sessions are really mostly for stuff that really is a session of some kind, and not just system services that just need some code executed by time. The same way as a daemon that drops priviliges shouldn't do so through PAM, a system cronjob shouldn't involve PAM. But that of course would require changes to cron, to understand what a system and what a user cronjob was... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to quiet cron sessions logging with systemd-212?
On 10.06.2014 13:20, Lennart Poettering wrote: On Mon, 09.06.14 09:33, Leho Kraav (l...@kraav.com) wrote: After upgrading systemd 208 - 212, every single cron job creates this flood in systemd journal: Can I quiet this down somehow? The idea with the journal is that we log everything that happens on the system, without exceptions, without hiding anything. And filtering is then applied when you view things, based on the big pool of data you have. This can be annoying, of course, but I am so very sure we should't suppress these things, because soemtimes they are useful to know about. journalctl has powerful filtering capabilities, we have them to make this huge datase palatable... I'm actually all for getting the upstream i.e. cron/PAM acting more sane so we don't even arrive at the logging huge amounts of low-effectiveness information problem, but as you wrote in your other reply, that might be a whole separate project. In the meantime mgilbert's suggestion for using loginctl --linger parameter seems to accomplish the goal of quieting cron logging. Any side effects to consider? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to quiet cron sessions logging with systemd-212?
On Monday 09 June 2014 at 23:32:28, Mike Gilbert wrote: On Mon, Jun 9, 2014 at 4:42 PM, Reindl Harald h.rei...@thelounge.net wrote: Am 09.06.2014 22:32, schrieb Leonid Isaev: On Mon, Jun 09, 2014 at 09:19:20PM +0200, Reindl Harald wrote: [...] on our production infrastrcuture these messages would be *a lot* more than all other logs summarized *and* they are spitted to /var/log/messages to make things worst But why can't you write a syslog filter which uses facility as well as program name? So if you believe that systemd-generated messages are useless, drop them because you *can not* distinguish between *that* user messages and system message sbecause they have systemd as program name common, the PID changes and you don't want to drop *system messages* from systemd So, systemd starts certain things on _any_ user login: be it a real user, or a daemon. However * why do it need to do that much stuff * why can't it keep that stuff long-running you have already /usr/lib/systemd/systemd --user and (sd-pam) processes for every userid ever started a cronjob running all the time - so why flood the logs every minute again? Now that you mention it, you can cut down on a lot of the log spam by enabling linger for root and other users which run cron jobs. loginctl enable-linger user This will keep a systemd user instance running so that a new one is not spawned every time cron wakes up. It's more interesting, why a logind session is ever being created for the cron job... It shouldn't be that way, or do I misunderstand something? -- Ivan Shapovalov / intelfx / signature.asc Description: This is a digitally signed message part. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to quiet cron sessions logging with systemd-212?
Am 10.06.2014 12:20, schrieb Lennart Poettering: On Mon, 09.06.14 09:33, Leho Kraav (l...@kraav.com) wrote: After upgrading systemd 208 - 212, every single cron job creates this flood in systemd journal: Can I quiet this down somehow? The idea with the journal is that we log everything that happens on the system, without exceptions, without hiding anything. And filtering is then applied when you view things, based on the big pool of data you have. This can be annoying, of course, but I am so very sure we should't suppress these things, because soemtimes they are useful to know about if things are only *sometimes* useful that means most of the time they are not and for anybody who is not a systemd-developer or debugging something they are just noise at least the enable-linger should be default because you anyways have all the disturbing sd-pam processes long running which you need to kill after updates on libraries to get anything in listed with lsof | grep DEL | grep /usr clean so don't start a complete systemd session for a simple cronjob which did his job decades before systemd existed or just don't stop it all the time the started target... messages are in *any case* misleading signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to quiet cron sessions logging with systemd-212?
On Tue, 10.06.14 13:24, Leho Kraav (l...@kraav.com) wrote: On 10.06.2014 13:20, Lennart Poettering wrote: On Mon, 09.06.14 09:33, Leho Kraav (l...@kraav.com) wrote: After upgrading systemd 208 - 212, every single cron job creates this flood in systemd journal: Can I quiet this down somehow? The idea with the journal is that we log everything that happens on the system, without exceptions, without hiding anything. And filtering is then applied when you view things, based on the big pool of data you have. This can be annoying, of course, but I am so very sure we should't suppress these things, because soemtimes they are useful to know about. journalctl has powerful filtering capabilities, we have them to make this huge datase palatable... I'm actually all for getting the upstream i.e. cron/PAM acting more sane so we don't even arrive at the logging huge amounts of low-effectiveness information problem, but as you wrote in your other reply, that might be a whole separate project. In the meantime mgilbert's suggestion for using loginctl --linger parameter seems to accomplish the goal of quieting cron logging. Any side effects to consider? Well, you keep the systemd user instance running all the time then instead of just when it is used... Doing that for root is fine, but if you do that for all users, then well, you got an additional process running for each one of them... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to quiet cron sessions logging with systemd-212?
On 10.06.2014 19:01, Lennart Poettering wrote: In the meantime mgilbert's suggestion for using EDIT **loginctl enable-linger** command seems to accomplish the goal of quieting cron logging. Any side effects to consider? Well, you keep the systemd user instance running all the time then instead of just when it is used... Doing that for root is fine, but if you do that for all users, then well, you got an additional process running for each one of them... Right. For time being, root cron jobs are the primary issue. I'll see what happens with the others. enable-linger persists across reboots? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to quiet cron sessions logging with systemd-212?
On Tue, 10.06.14 14:31, Ivan Shapovalov (intelfx...@gmail.com) wrote: It's more interesting, why a logind session is ever being created for the cron job... It shouldn't be that way, or do I misunderstand something? We should create a logind session for all sessions of normal users. It doesn't matter if its just a background job or foreground, logind should know about it, we should set up its full environment (including the per-user systemd), and set all security limits and stuff. For system users (i.e. those with an uid 1000), for all that stuff that is just an implementation detail of the OS however there shouldn't really be any PAM or logind session created by cron. It should just setresuid() and invoke whatever it needs to invoke... Setting up a full PAM session is quite unnecessary then... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to quiet cron sessions logging with systemd-212?
On 09.06.2014 09:33, Leho Kraav wrote: After upgrading systemd 208 - 212, every single cron job creates this flood in systemd journal: juuni 09 09:20:01 xps14 crond[15112]: pam_unix(crond:session): session opened for user root by (uid=0) juuni 09 09:20:01 xps14 systemd[15113]: pam_unix(systemd-user:session): session opened for user root by (uid=0) juuni 09 09:20:01 xps14 systemd[1]: Starting user-0.slice. ... juuni 09 09:20:02 xps14 systemd[1]: Started User Manager for UID 0. juuni 09 09:20:02 xps14 CROND[15116]: (root) CMD (test -x /usr/sbin/run-crons /usr/sbin/run-crons ) juuni 09 09:20:02 xps14 CROND[15112]: pam_unix(crond:session): session closed for user root juuni 09 09:20:02 xps14 systemd[1]: Stopping User Manager for UID 0... ... juuni 09 09:20:02 xps14 systemd[1]: Stopped User Manager for UID 0. juuni 09 09:20:02 xps14 systemd[1]: Stopping user-0.slice. juuni 09 09:20:02 xps14 systemd[1]: Removed slice user-0.slice. Another related question to trying to filter this output: why some lines are logged with program crond and some CROND? With loginctl linger-enable a shorter version of a cron run looks like this now: ... juuni 10 19:30:01 xps14 crond[21310]: pam_unix(crond:session): session opened for user root by (uid=0) juuni 10 19:30:01 xps14 CROND[21311]: (root) CMD (test -x /usr/sbin/run-crons /usr/sbin/run-crons ) juuni 10 19:30:01 xps14 systemd[1]: Starting Session 99 of user root. juuni 10 19:30:01 xps14 systemd[1]: Started Session 99 of user root. juuni 10 19:30:01 xps14 CROND[21310]: pam_unix(crond:session): session closed for user root ... I am considering filtering crond out of the human-visible status window and that's how the uppercase vs lowercase question arose. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to quiet cron sessions logging with systemd-212?
Am 10.06.2014 18:01, schrieb Lennart Poettering: On Tue, 10.06.14 13:24, Leho Kraav (l...@kraav.com) wrote: On 10.06.2014 13:20, Lennart Poettering wrote: On Mon, 09.06.14 09:33, Leho Kraav (l...@kraav.com) wrote: After upgrading systemd 208 - 212, every single cron job creates this flood in systemd journal: Can I quiet this down somehow? The idea with the journal is that we log everything that happens on the system, without exceptions, without hiding anything. And filtering is then applied when you view things, based on the big pool of data you have. This can be annoying, of course, but I am so very sure we should't suppress these things, because soemtimes they are useful to know about. journalctl has powerful filtering capabilities, we have them to make this huge datase palatable... I'm actually all for getting the upstream i.e. cron/PAM acting more sane so we don't even arrive at the logging huge amounts of low-effectiveness information problem, but as you wrote in your other reply, that might be a whole separate project. In the meantime mgilbert's suggestion for using loginctl --linger parameter seems to accomplish the goal of quieting cron logging. Any side effects to consider? Well, you keep the systemd user instance running all the time then instead of just when it is used... Doing that for root is fine, but if you do that for all users, then well, you got an additional process running for each one of them... which is cheaper than fire up a complete session again and again with all the logs recent systemd generates and you *already* have long running processes for each user ever started a cronjob also under Fedora 20 which don't flood the logs otherwise they already annoy me a lot because the last decades that all was not there and cronjobs where just fine vmware4030 0.0 0.0 74208 2064 ?SJun08 0:00 (sd-pam) harry 4351 0.0 0.0 74208 2132 ?SJun08 0:00 (sd-pam) root 9806 0.0 0.0 74208 2208 ?SJun08 0:00 (sd-pam) wwwcron 10894 0.0 0.0 74208 2224 ?SJun08 0:00 (sd-pam) apache 10918 0.0 0.0 74208 2236 ?SJun08 0:00 (sd-pam) signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to quiet cron sessions logging with systemd-212?
On Tue, 10.06.14 19:03, Leho Kraav (l...@kraav.com) wrote: On 10.06.2014 19:01, Lennart Poettering wrote: In the meantime mgilbert's suggestion for using EDIT **loginctl enable-linger** command seems to accomplish the goal of quieting cron logging. Any side effects to consider? Well, you keep the systemd user instance running all the time then instead of just when it is used... Doing that for root is fine, but if you do that for all users, then well, you got an additional process running for each one of them... Right. For time being, root cron jobs are the primary issue. I'll see what happens with the others. enable-linger persists across reboots? Yes. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to quiet cron sessions logging with systemd-212?
On Tue, 10.06.14 20:05, Leho Kraav (l...@kraav.com) wrote: On 09.06.2014 09:33, Leho Kraav wrote: After upgrading systemd 208 - 212, every single cron job creates this flood in systemd journal: juuni 09 09:20:01 xps14 crond[15112]: pam_unix(crond:session): session opened for user root by (uid=0) juuni 09 09:20:01 xps14 systemd[15113]: pam_unix(systemd-user:session): session opened for user root by (uid=0) juuni 09 09:20:01 xps14 systemd[1]: Starting user-0.slice. ... juuni 09 09:20:02 xps14 systemd[1]: Started User Manager for UID 0. juuni 09 09:20:02 xps14 CROND[15116]: (root) CMD (test -x /usr/sbin/run-crons /usr/sbin/run-crons ) juuni 09 09:20:02 xps14 CROND[15112]: pam_unix(crond:session): session closed for user root juuni 09 09:20:02 xps14 systemd[1]: Stopping User Manager for UID 0... ... juuni 09 09:20:02 xps14 systemd[1]: Stopped User Manager for UID 0. juuni 09 09:20:02 xps14 systemd[1]: Stopping user-0.slice. juuni 09 09:20:02 xps14 systemd[1]: Removed slice user-0.slice. Another related question to trying to filter this output: why some lines are logged with program crond and some CROND? No idea. cron sends that string, we merely display it... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] How to quiet cron sessions logging with systemd-212?
After upgrading systemd 208 - 212, every single cron job creates this flood in systemd journal: juuni 09 09:20:01 xps14 crond[15112]: pam_unix(crond:session): session opened for user root by (uid=0) juuni 09 09:20:01 xps14 systemd[15113]: pam_unix(systemd-user:session): session opened for user root by (uid=0) juuni 09 09:20:01 xps14 systemd[1]: Starting user-0.slice. juuni 09 09:20:01 xps14 systemd[1]: Created slice user-0.slice. juuni 09 09:20:01 xps14 systemd[1]: Starting User Manager for UID 0... juuni 09 09:20:01 xps14 systemd[1]: Starting Session 107 of user root. juuni 09 09:20:01 xps14 systemd[1]: Started Session 107 of user root. juuni 09 09:20:02 xps14 systemd[15113]: Starting Paths. juuni 09 09:20:02 xps14 systemd[15113]: Reached target Paths. juuni 09 09:20:02 xps14 systemd[15113]: Starting Timers. juuni 09 09:20:02 xps14 systemd[15113]: Reached target Timers. juuni 09 09:20:02 xps14 systemd[15113]: Starting Sockets. juuni 09 09:20:02 xps14 systemd[15113]: Reached target Sockets. juuni 09 09:20:02 xps14 systemd[15113]: Starting Basic System. juuni 09 09:20:02 xps14 systemd[15113]: Reached target Basic System. juuni 09 09:20:02 xps14 systemd[15113]: Starting Default. juuni 09 09:20:02 xps14 systemd[15113]: Reached target Default. juuni 09 09:20:02 xps14 systemd[15113]: Startup finished in 31ms. juuni 09 09:20:02 xps14 systemd[1]: Started User Manager for UID 0. juuni 09 09:20:02 xps14 CROND[15116]: (root) CMD (test -x /usr/sbin/run-crons /usr/sbin/run-crons ) juuni 09 09:20:02 xps14 CROND[15112]: pam_unix(crond:session): session closed for user root juuni 09 09:20:02 xps14 systemd[1]: Stopping User Manager for UID 0... juuni 09 09:20:02 xps14 systemd[15113]: Stopping Default. juuni 09 09:20:02 xps14 systemd[15113]: Stopped target Default. juuni 09 09:20:02 xps14 systemd[15113]: Stopping Basic System. juuni 09 09:20:02 xps14 systemd[15113]: Stopped target Basic System. juuni 09 09:20:02 xps14 systemd[15113]: Stopping Paths. juuni 09 09:20:02 xps14 systemd[15113]: Stopped target Paths. juuni 09 09:20:02 xps14 systemd[15113]: Stopping Timers. juuni 09 09:20:02 xps14 systemd[15113]: Stopped target Timers. juuni 09 09:20:02 xps14 systemd[15113]: Stopping Sockets. juuni 09 09:20:02 xps14 systemd[15113]: Stopped target Sockets. juuni 09 09:20:02 xps14 systemd[15113]: Starting Shutdown. juuni 09 09:20:02 xps14 systemd[15113]: Reached target Shutdown. juuni 09 09:20:02 xps14 systemd[15113]: Starting Exit the Session... juuni 09 09:20:02 xps14 systemd[15113]: Received SIGRTMIN+24 from PID 15128 (kill). juuni 09 09:20:02 xps14 systemd[15114]: pam_unix(systemd-user:session): session closed for user root juuni 09 09:20:02 xps14 systemd[1]: Stopped User Manager for UID 0. juuni 09 09:20:02 xps14 systemd[1]: Stopping user-0.slice. juuni 09 09:20:02 xps14 systemd[1]: Removed slice user-0.slice. Can I quiet this down somehow? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to quiet cron sessions logging with systemd-212?
I think there's also another problem – logind starts the user manager instance for cronjobs while it shouldn't do so for batch stuff. Probably a PAM configuration issue. -- Mantas Mikulėnas graw...@gmail.com On Jun 9, 2014 9:34 AM, Leho Kraav l...@kraav.com wrote: After upgrading systemd 208 - 212, every single cron job creates this flood in systemd journal: juuni 09 09:20:01 xps14 crond[15112]: pam_unix(crond:session): session opened for user root by (uid=0) juuni 09 09:20:01 xps14 systemd[15113]: pam_unix(systemd-user:session): session opened for user root by (uid=0) juuni 09 09:20:01 xps14 systemd[1]: Starting user-0.slice. juuni 09 09:20:01 xps14 systemd[1]: Created slice user-0.slice. juuni 09 09:20:01 xps14 systemd[1]: Starting User Manager for UID 0... juuni 09 09:20:01 xps14 systemd[1]: Starting Session 107 of user root. juuni 09 09:20:01 xps14 systemd[1]: Started Session 107 of user root. juuni 09 09:20:02 xps14 systemd[15113]: Starting Paths. juuni 09 09:20:02 xps14 systemd[15113]: Reached target Paths. juuni 09 09:20:02 xps14 systemd[15113]: Starting Timers. juuni 09 09:20:02 xps14 systemd[15113]: Reached target Timers. juuni 09 09:20:02 xps14 systemd[15113]: Starting Sockets. juuni 09 09:20:02 xps14 systemd[15113]: Reached target Sockets. juuni 09 09:20:02 xps14 systemd[15113]: Starting Basic System. juuni 09 09:20:02 xps14 systemd[15113]: Reached target Basic System. juuni 09 09:20:02 xps14 systemd[15113]: Starting Default. juuni 09 09:20:02 xps14 systemd[15113]: Reached target Default. juuni 09 09:20:02 xps14 systemd[15113]: Startup finished in 31ms. juuni 09 09:20:02 xps14 systemd[1]: Started User Manager for UID 0. juuni 09 09:20:02 xps14 CROND[15116]: (root) CMD (test -x /usr/sbin/run-crons /usr/sbin/run-crons ) juuni 09 09:20:02 xps14 CROND[15112]: pam_unix(crond:session): session closed for user root juuni 09 09:20:02 xps14 systemd[1]: Stopping User Manager for UID 0... juuni 09 09:20:02 xps14 systemd[15113]: Stopping Default. juuni 09 09:20:02 xps14 systemd[15113]: Stopped target Default. juuni 09 09:20:02 xps14 systemd[15113]: Stopping Basic System. juuni 09 09:20:02 xps14 systemd[15113]: Stopped target Basic System. juuni 09 09:20:02 xps14 systemd[15113]: Stopping Paths. juuni 09 09:20:02 xps14 systemd[15113]: Stopped target Paths. juuni 09 09:20:02 xps14 systemd[15113]: Stopping Timers. juuni 09 09:20:02 xps14 systemd[15113]: Stopped target Timers. juuni 09 09:20:02 xps14 systemd[15113]: Stopping Sockets. juuni 09 09:20:02 xps14 systemd[15113]: Stopped target Sockets. juuni 09 09:20:02 xps14 systemd[15113]: Starting Shutdown. juuni 09 09:20:02 xps14 systemd[15113]: Reached target Shutdown. juuni 09 09:20:02 xps14 systemd[15113]: Starting Exit the Session... juuni 09 09:20:02 xps14 systemd[15113]: Received SIGRTMIN+24 from PID 15128 (kill). juuni 09 09:20:02 xps14 systemd[15114]: pam_unix(systemd-user:session): session closed for user root juuni 09 09:20:02 xps14 systemd[1]: Stopped User Manager for UID 0. juuni 09 09:20:02 xps14 systemd[1]: Stopping user-0.slice. juuni 09 09:20:02 xps14 systemd[1]: Removed slice user-0.slice. Can I quiet this down somehow? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to quiet cron sessions logging with systemd-212?
On Mon, Jun 09, 2014 at 10:48:31AM +0300, Leho Kraav wrote: Date: Mon, 09 Jun 2014 10:48:31 +0300 From: Leho Kraav l...@kraav.com To: Reindl Harald h.rei...@thelounge.net, systemd-devel@lists.freedesktop.org Subject: Re: [systemd-devel] How to quiet cron sessions logging with systemd-212? User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 On 09.06.2014 10:43, Reindl Harald wrote: nobody cares because the developers point of view is that what is interesting for them needs to be also faced by the sysadmin otherwise this would be only logged in debug-mode and bugreports not closed: https://bugzilla.redhat.com/show_bug.cgi?id=1072368#c3 frankly if that messages would at least have a prefix or a different process than systemd one could filter them out with rsyslog.conf without supress relevant boot messages Thanks for the info. I tried googling for this relatively hard, couldn't find that bug. Language on that bug is probably counterproductive, but other than that, some reasonably sensible way should exist to simply stop logging crap, not relying on just output filtering. What you see are authpriv-level logs, so it would be a really bad idea to suppress them, regardless of their source. Currently, journald doesn't provide any means of log processing, so your only choice is to filter logs when viewing them using journalctl command line or grep/awk; you can not control what is logged when and where. If you want log processing (multiple log directories, advanced filtering, etc.), use syslog-ng or rsyslog. For example, one can setup a special logfile for systemd-related messages with a given syslog facility (authpriv, daemon, etc.). HTH, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D pgpERrsRV4Zx0.pgp Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to quiet cron sessions logging with systemd-212?
Am 09.06.2014 17:28, schrieb Leonid Isaev: On Mon, Jun 09, 2014 at 10:48:31AM +0300, Leho Kraav wrote: Date: Mon, 09 Jun 2014 10:48:31 +0300 From: Leho Kraav l...@kraav.com To: Reindl Harald h.rei...@thelounge.net, systemd-devel@lists.freedesktop.org Subject: Re: [systemd-devel] How to quiet cron sessions logging with systemd-212? User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 On 09.06.2014 10:43, Reindl Harald wrote: nobody cares because the developers point of view is that what is interesting for them needs to be also faced by the sysadmin otherwise this would be only logged in debug-mode and bugreports not closed: https://bugzilla.redhat.com/show_bug.cgi?id=1072368#c3 frankly if that messages would at least have a prefix or a different process than systemd one could filter them out with rsyslog.conf without supress relevant boot messages Thanks for the info. I tried googling for this relatively hard, couldn't find that bug. Language on that bug is probably counterproductive, but other than that, some reasonably sensible way should exist to simply stop logging crap, not relying on just output filtering. What you see are authpriv-level logs, so it would be a really bad idea to suppress them, regardless of their source no user needs them, there are already logs which command was started for which user from crond with just 3 lines Jun 9 19:01:01 rawhide CROND[1696]: (root) CMD (run-parts /etc/cron.hourly) Jun 9 19:01:01 rawhide run-parts[1696]: (/etc/cron.hourly) starting 0anacron Jun 9 19:01:01 rawhide run-parts[1705]: (/etc/cron.hourly) finished 0anacron Jun 9 20:01:01 rawhide CROND[1735]: (root) CMD (run-parts /etc/cron.hourly) Jun 9 20:01:01 rawhide run-parts[1735]: (/etc/cron.hourly) starting 0anacron Jun 9 20:01:01 rawhide run-parts[1744]: (/etc/cron.hourly) finished 0anacron they are introduced in that floody way with recent systemd all the decades before crond did run fine, logs exactly what you need to know if /var/log/secure and /var/log/crond without writing *hundret thousands* loglines all day long on machines with a lot of cronjobs signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to quiet cron sessions logging with systemd-212?
On Mon, Jun 09, 2014 at 08:08:43PM +0200, Reindl Harald wrote:
Date: Mon, 09 Jun 2014 20:08:43 +0200
From: Reindl Harald h.rei...@thelounge.net
To: systemd-devel@lists.freedesktop.org
Subject: Re: [systemd-devel] How to quiet cron sessions logging with
systemd-212?
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101
Thunderbird/24.5.0
Am 09.06.2014 17:28, schrieb Leonid Isaev:
On Mon, Jun 09, 2014 at 10:48:31AM +0300, Leho Kraav wrote:
Date: Mon, 09 Jun 2014 10:48:31 +0300
From: Leho Kraav l...@kraav.com
To: Reindl Harald h.rei...@thelounge.net,
systemd-devel@lists.freedesktop.org
Subject: Re: [systemd-devel] How to quiet cron sessions logging with
systemd-212?
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101
Thunderbird/24.5.0
On 09.06.2014 10:43, Reindl Harald wrote:
nobody cares because the developers point of view is that what is
interesting for them needs to be also faced by the sysadmin
otherwise this would be only logged in debug-mode and bugreports
not closed: https://bugzilla.redhat.com/show_bug.cgi?id=1072368#c3
frankly if that messages would at least have a prefix or a different
process than systemd one could filter them out with rsyslog.conf
without supress relevant boot messages
Thanks for the info. I tried googling for this relatively hard, couldn't
find that bug.
Language on that bug is probably counterproductive, but other than that,
some reasonably sensible way should exist to simply stop logging crap, not
relying on just output filtering.
What you see are authpriv-level logs, so it would be a really bad idea to
suppress them, regardless of their source
no user needs them, there are already logs which command was
started for which user from crond with just 3 lines
If you don't need them -- OK, but don't speak for the others. Why systemd
should be treated any differently than other programs? If it generates authpriv
messages -- they should be collected, not ignored. What about normal, i.e.
user-initiated logins -- should they be logged?
Jun 9 19:01:01 rawhide CROND[1696]: (root) CMD (run-parts /etc/cron.hourly)
Jun 9 19:01:01 rawhide run-parts[1696]: (/etc/cron.hourly) starting 0anacron
Jun 9 19:01:01 rawhide run-parts[1705]: (/etc/cron.hourly) finished 0anacron
Jun 9 20:01:01 rawhide CROND[1735]: (root) CMD (run-parts /etc/cron.hourly)
Jun 9 20:01:01 rawhide run-parts[1735]: (/etc/cron.hourly) starting 0anacron
Jun 9 20:01:01 rawhide run-parts[1744]: (/etc/cron.hourly) finished 0anacron
they are introduced in that floody way with recent systemd
all the decades before crond did run fine, logs exactly what
you need to know if /var/log/secure and /var/log/crond
without writing *hundret thousands* loglines all day long
on machines with a lot of cronjobs
But why can't you write a syslog filter which uses facility as well as program
name? So if you believe that systemd-generated messages are useless, drop them,
or store them in a volatile location like /run/log. Something like this (in
syslog-ng language):
---
destination d_systemd { file(/run/log/systemd.log); };
filter f_daemon { facility(daemon) and not level(debug) and not \
program(systemd); };
filter f_systemd { program(systemd); };
log { source(src); filter(f_systemd); destination(d_systemd); };
---
--
Leonid Isaev
GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4
C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
pgpz5kfVKZuoL.pgp
Description: PGP signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to quiet cron sessions logging with systemd-212?
Am 09.06.2014 21:07, schrieb Leonid Isaev: On Mon, Jun 09, 2014 at 08:08:43PM +0200, Reindl Harald wrote: all the decades before crond did run fine, logs exactly what you need to know if /var/log/secure and /var/log/crond without writing *hundret thousands* loglines all day long on machines with a lot of cronjobs If you don't need them -- OK, but don't speak for the others. Why systemd should be treated any differently than other programs? because Lennart to ospeaks for others the way he closed that bugreport? why can't there be at least a config option to disable creating them at all? because other programs *never ever* procude *that lot* of loglines all day long - look at the simple calculation in the bugreport on our production infrastrcuture these messages would be *a lot* more than all other logs summarized *and* they are spitted to /var/log/messages to make things worst But why can't you write a syslog filter which uses facility as well as program name? So if you believe that systemd-generated messages are useless, drop them because you *can not* distinguish between *that* user messages and system message sbecause they have systemd as program name common, the PID changes and you don't want to drop *system messages* from systemd if they would contain a unique string / prefix to distinguish from cronjobs triggered messages i would have written a rsyslog filter as for a lot of other noise long ago however - the *large amount* of that messages even if you drop them consumes useless ressources on virtualization clusters and blow up the systemd-journal signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to quiet cron sessions logging with systemd-212?
On Mon, Jun 09, 2014 at 09:19:20PM +0200, Reindl Harald wrote: [...] on our production infrastrcuture these messages would be *a lot* more than all other logs summarized *and* they are spitted to /var/log/messages to make things worst But why can't you write a syslog filter which uses facility as well as program name? So if you believe that systemd-generated messages are useless, drop them because you *can not* distinguish between *that* user messages and system message sbecause they have systemd as program name common, the PID changes and you don't want to drop *system messages* from systemd So, systemd starts certain things on _any_ user login: be it a real user, or a daemon. However, if you already have logs from the daemon (cron) or a login program (login), why keep systemd-generated messages? I'd put them in a separate file... if they would contain a unique string / prefix to distinguish Do you have something concrete in mind? from cronjobs triggered messages i would have written a rsyslog filter as for a lot of other noise long ago however - the *large amount* of that messages even if you drop them consumes useless ressources on virtualization clusters and blow up the systemd-journal If resources are an issue, don't use the journal. In my experience, it consumes ~4x space compared to syslog (on a firewall machine, after 2 months uptime)... -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D pgpkW9mGeOXcS.pgp Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to quiet cron sessions logging with systemd-212?
Am 09.06.2014 22:32, schrieb Leonid Isaev: On Mon, Jun 09, 2014 at 09:19:20PM +0200, Reindl Harald wrote: [...] on our production infrastrcuture these messages would be *a lot* more than all other logs summarized *and* they are spitted to /var/log/messages to make things worst But why can't you write a syslog filter which uses facility as well as program name? So if you believe that systemd-generated messages are useless, drop them because you *can not* distinguish between *that* user messages and system message sbecause they have systemd as program name common, the PID changes and you don't want to drop *system messages* from systemd So, systemd starts certain things on _any_ user login: be it a real user, or a daemon. However * why do it need to do that much stuff * why can't it keep that stuff long-running you have already /usr/lib/systemd/systemd --user and (sd-pam) processes for every userid ever started a cronjob running all the time - so why flood the logs every minute again? if you already have logs from the daemon (cron) or a login program (login), why keep systemd-generated messages? I'd put them in a separate file... if i can put them in a seperate file i can filter them out if they would contain a unique string / prefix to distinguish Do you have something concrete in mind? systemd-user: or whatever that would also make clear the we *do not* start all sorts of targets, the flooding log in misleading anyways that below is just *not true* from the users point of view Jun 9 22:36:07 rawhide systemd[1]: Starting User Manager for UID 0... Jun 9 22:36:07 rawhide systemd[607]: Starting Paths. Jun 9 22:36:07 rawhide systemd[607]: Reached target Paths. Jun 9 22:36:07 rawhide systemd[607]: Starting Timers. Jun 9 22:36:07 rawhide systemd[607]: Reached target Timers. Jun 9 22:36:07 rawhide systemd[607]: Starting Sockets. Jun 9 22:36:07 rawhide systemd[607]: Reached target Sockets. Jun 9 22:36:07 rawhide systemd[607]: Starting Basic System. Jun 9 22:36:07 rawhide systemd[607]: Reached target Basic System. Jun 9 22:36:07 rawhide systemd[607]: Starting Default. Jun 9 22:36:07 rawhide systemd[607]: Reached target Default. Jun 9 22:36:07 rawhide systemd[607]: Startup finished in 9ms. Jun 9 22:36:07 rawhide systemd[1]: Started User Manager for UID 0. from cronjobs triggered messages i would have written a rsyslog filter as for a lot of other noise long ago however - the *large amount* of that messages even if you drop them consumes useless ressources on virtualization clusters and blow up the systemd-journal If resources are an issue, don't use the journal. In my experience, it consumes ~4x space compared to syslog (on a firewall machine, after 2 months uptime)... i don't use the journal, the configuration of journald is like below the log-flood makes things even worser because it leads to early rotation and purges systemctl status whatever.service informations by purging the memory-journal if it comes to ressource usage: all that dropped messages (if you could drop/filter them) are producing data and overhead in general, only because you manage to not see things that don't mean they produce no overhead [root@rawhide ~]# cat /etc/systemd/journald.conf [Journal] Storage=volatile Compress=no RateLimitInterval=10s RateLimitBurst=500 RuntimeMaxUse=15M signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to quiet cron sessions logging with systemd-212?
On Mon, Jun 9, 2014 at 4:42 PM, Reindl Harald h.rei...@thelounge.net wrote: Am 09.06.2014 22:32, schrieb Leonid Isaev: On Mon, Jun 09, 2014 at 09:19:20PM +0200, Reindl Harald wrote: [...] on our production infrastrcuture these messages would be *a lot* more than all other logs summarized *and* they are spitted to /var/log/messages to make things worst But why can't you write a syslog filter which uses facility as well as program name? So if you believe that systemd-generated messages are useless, drop them because you *can not* distinguish between *that* user messages and system message sbecause they have systemd as program name common, the PID changes and you don't want to drop *system messages* from systemd So, systemd starts certain things on _any_ user login: be it a real user, or a daemon. However * why do it need to do that much stuff * why can't it keep that stuff long-running you have already /usr/lib/systemd/systemd --user and (sd-pam) processes for every userid ever started a cronjob running all the time - so why flood the logs every minute again? Now that you mention it, you can cut down on a lot of the log spam by enabling linger for root and other users which run cron jobs. loginctl enable-linger user This will keep a systemd user instance running so that a new one is not spawned every time cron wakes up. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
