On 2013-06-14 00:46, Cristian Rodríguez wrote:

El 13/06/13 17:56, Carlos E. R. escribió:

...

Why is not systemd logging this output?

Because:

1. that output is sent to stderr.

2. The unit file has StandardOutput=null as expected, otherwise a feedback loop will ocurr (the messages emitted by rsyslog service messages will be logged to the journal, which in turn will be forwarded to the syslog socket, that will cause a request for a syslog implementation to be activated..goto beggining :-) )

3. By default StandardError= inherits StandardOutput, if you change StandardError= goto 2 ;)

Soo... there is no special case to capture the error /somehow/? -- Cheers / Saludos, Carlos E. R. (from 12.3 x86_64 "Dartmouth" at Telcontar)

On 2013-06-14 22:40, Cristian Rodríguez wrote:

El 14/06/13 03:54, Carlos E. R. escribió:

...

Soo... there is no special case to capture the error /somehow/?

Not at the moment for this particular case, syslog implementations _must_ have stdout and stderr connected to /dev/null otherwise they will trigger a loop.. that said, if the daemon can log its own errors to a separate file, it might be possible.

Can't stderr be redirected somewhere else? With bash it is possible. -- Cheers / Saludos, Carlos E. R. (from 12.3 x86_64 "Dartmouth" at Telcontar)

В Fri, 14 Jun 2013 23:07:59 +0200 "Carlos E. R." пишет:

On 2013-06-14 22:40, Cristian Rodríguez wrote:

...

El 14/06/13 03:54, Carlos E. R. escribió:

...

...

Soo... there is no special case to capture the error /somehow/?

Not at the moment for this particular case, syslog implementations _must_ have stdout and stderr connected to /dev/null otherwise they will trigger a loop.. that said, if the daemon can log its own errors to a separate file, it might be possible.

Can't stderr be redirected somewhere else? With bash it is possible.

ExecStart=/bin/sh -c 'exec rsyslogd -n $RSYSLOGD_PARAMS 2> /somewhere/else'

В Sat, 15 Jun 2013 09:35:37 +0400 Andrey Borzenkov пишет:

В Thu, 13 Jun 2013 18:46:51 -0400 Cristian Rodríguez пишет:

...

El 13/06/13 17:56, Carlos E. R. escribió:

...

Why is not systemd logging this output?

Because:

1. that output is sent to stderr.

2. The unit file has StandardOutput=null as expected, otherwise a feedback loop will ocurr (the messages emitted by rsyslog service messages will be logged to the journal, which in turn will be forwarded to the syslog socket, that will cause a request for a syslog implementation to be activated..goto beggining :-) )

So you think it is better to completely remove any possibility to find out why rsyslogd failed to start instead of rate-limiting number of failed attempts?

Does not systemd already disables socket activation if service failed to start several times in a sequence? Which would give user all information needed to fix the problem and re-enable it?

Actually I tested behavior with and without disabling rsyslogd stdout/stderr. Both with and without StandardOutput=inherit in rsyslog if I have error that prevents rsuslogd from starting I get exactly the same behavior - systemd permanently attempts to restart syslog.service spending 50% CPU in system and 50% CPU in user mode. Which is more or less obvious as normal system has quite a lot of logging going on, so rsyslog does not add anything significant here. OTOH removing StandardOutput=inherit from rsyslog.conf allows me to see, *WHY* it did not start: journalctl -b /sbin/rsyslogd -- Logs begin at Sat, 2013-06-15 10:12:46 MSK, end at Sat, 2013-06-15 10:17:02 MSK. -- Jun 15 10:14:35 linux-o0ic.site rsyslogd[1526]: rsyslogd: error during parsing file /etc/rsyslog.d/dummy.conf, on or before line 1: syntax error on token '=' [try http://www.rsyslog.com/e/2207 ] Jun 15 10:14:35 linux-o0ic.site rsyslogd[1526]: rsyslogd: CONFIG ERROR: could not interpret master config file '/etc/rsyslog.conf'. [try http://www.rsyslog.com/e/2207 ] Jun 15 10:14:35 linux-o0ic.site rsyslogd[1526]: rsyslogd: run failed with error -2207 (see rsyslog.h or try http://www.rsyslog.com/e/2207 to learn what that number means) ... (unfortunately those lines are not usually visible in "systemctl status", not sure why). So I fail to see any justification for suppressing rsyslog messages. Carlos, I think it warrants bug report so it can be followed. Additionally, it also demonstrates that systemd does not do any rate limiting on socket-activated services. Which is bad actually. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

В Sat, 15 Jun 2013 02:48:31 -0400 Cristian Rodríguez пишет:

On 06/15/2013 02:28 AM, Andrey Borzenkov wrote:

...

Additionally, it also demonstrates that systemd does not do any rate limiting on socket-activated services. Which is bad actually.

Rate limiting works here..(factory) what rsyslog you tested in what distro ?

openSUSE 12.3. We are here on opensuse@ list, are not we?

ps: changing the syslog service file "StandarOutput" will go against the documenation and the specification for the interaction of syslog and the journal/systemd

That's not a technical argument. Please explain, *what* will go wrong in this case instead of referring to holy book. If we rate limit rsyslog.service itself, we get burst of errors from it every now and then. What problem does it cause? Besides I demonstrated that even in default configuration systemd goes amok when rsyslog cannot be started. So what exactly does suppressing diagnostic output improve beyond making diagnostic impossible?

so you will have to makke your case upstream ;)

I did.

-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

В Sat, 15 Jun 2013 03:16:48 -0400 Cristian Rodríguez пишет:

On 06/15/2013 02:57 AM, Andrey Borzenkov wrote:

...

That's not a technical argument. Please explain, *what* will go wrong in this case instead of referring to holy book.

I already did in another post..the documentation also explains what will go wrong.

"Will create a feedback loop with your implementation where the messages your syslog implementation writes out are fed back to it."

This is loop only if syslogd echoes to stdout/stderr messages that are fed to it. Does rsyslog do it?

Yes, this should not happend, but there is no special unit setting to stop the feedback loop (needed just for syslog btw)

-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Cristian RodrC-guez wrote:

On 06/15/2013 04:04 AM, Andrey Borzenkov wrote:

...

This is loop only if syslogd echoes to stdout/stderr messages that are fed to it. Does rsyslog do it?

the error messages that rsyslog emits that get "lost" do so because they are sent to STDERR which is connected to /dev/null to avoid the loop.

---- It's hard to argue with such perfect, logic-proof reasoning. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2013-06-15 08:28, Andrey Borzenkov wrote:

В Sat, 15 Jun 2013 09:35:37 +0400 Andrey Borzenkov <> пишет:

Actually I tested behavior with and without disabling rsyslogd stdout/stderr.

Both with and without StandardOutput=inherit in rsyslog if I have error that prevents rsuslogd from starting I get exactly the same behavior - systemd permanently attempts to restart syslog.service spending 50% CPU in system and 50% CPU in user mode. Which is more or less obvious as normal system has quite a lot of logging going on, so rsyslog does not add anything significant here.

This happened to me. On some circumstances, if the looping is fast, sysmtemd notices and stops trying. Under certain limit, it respawn in a loop, consuming 100% cpu of one core, heating it up (the load was not spread, that's why I noticed). I wrote about that in another email.

Carlos, I think it warrants bug report so it can be followed.

Certainly. Huh, impossible, I get the "page is redirecting improperly", impossible to log in, even after clearing cookies (novell and attachmate). Finally... it took a long time. Bug 825135 - systemd rsyslog unit has problems in 12.3 (and factory) with reporting errors about itself What component do we use for systemd? There is no init, systemd, syslog... I selected maintenance. :-?

Additionally, it also demonstrates that systemd does not do any rate limiting on socket-activated services. Which is bad actually.

It does, but not always. I reported about that here. -- Cheers / Saludos, Carlos E. R. (from 12.3 x86_64 "Dartmouth" at Telcontar)

On 6/14/2013 12:22 AM, Cristian Rodríguez wrote:

El jue 13 jun 2013 21:17:08 CLT, Cristian Rodríguez escribió:

...

- + sd_notify(0, "READY=1"); mainloop();

fixed in SR #178930

Just for the record I do notice and appreciate that you do a lot of work to fix things in other code that doesn't play well with systemd where possible. I just hate that the assumption is that that's always an option, and when it's not an option, oh well too bad get other software. -- bkw -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 06/14/2013 12:22 AM, Cristian Rodríguez wrote:

El jue 13 jun 2013 21:17:08 CLT, Cristian Rodríguez escribió:

...

- + sd_notify(0, "READY=1"); mainloop();

fixed in SR #178930

Accepted now in upstream.. neeeeeeeeeeeeeext :-) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org