[rsyslog] high CPU usage on 5.5.5 and 5.4.0

[Aaron Wiebe]

2010/7/1 Głowacki, Tomasz (INFO) <tomasz.glowacki at pseinfo.pl>:
>
> clock_gettime(CLOCK_REALTIME, {1277909500, 585805743}) = 0
> write(1, "9500.585805743:", 15)         = -1 EINVAL (Invalid argument)
> write(1, "b776db70: ", 10)              = -1 EINVAL (Invalid argument)
> write(1, "ruleset: get iRet 0 from rule.Pr"..., 43) = -1 EINVAL (Invalid argument)
> clock_gettime(CLOCK_REALTIME, {1277909500, 586203967}) = 0
> write(1, "9500.586203967:", 15)         = -1 EINVAL (Invalid argument)
> write(1, "b776db70: ", 10)              = -1 EINVAL (Invalid argument)
> write(1, "testing filter, f_pmask 0\n", 26) = -1 EINVAL (Invalid argument)
> clock_gettime(CLOCK_REALTIME, {1277909500, 586596069}) = 0
> write(1, "9500.586596069:", 15)         = -1 EINVAL (Invalid argument)
> write(1, "b776db70: ", 10)              = -1 EINVAL (Invalid argument)
> write(1, "ruleset: get iRet 0 from rule.Pr"..., 43) = -1 EINVAL (Invalid argument)
> clock_gettime(CLOCK_REALTIME, {1277909500, 586991581}) = 0
> write(1, "9500.586991581:", 15)         = -1 EINVAL (Invalid argument)
> write(1, "b776db70: ", 10)              = -1 EINVAL (Invalid argument)
> write(1, "testing filter, f_pmask 0\n", 26) = -1 EINVAL (Invalid argument)
> clock_gettime(CLOCK_REALTIME, {1277909500, 587383376}) = 0
> write(1, "9500.587383376:", 15)         = -1 EINVAL (Invalid argument)
> write(1, "b776db70: ", 10)              = -1 EINVAL (Invalid argument)
> write(1, "ruleset: get iRet 0 from rule.Pr"..., 43) = -1 EINVAL (Invalid argument)
> clock_gettime(CLOCK_REALTIME, {1277909500, 587778171}) = 0

This looks like a bug.  Can you provide a list of your environment
variables on startup?

This looks like debug logs are trying to be sent to stdout - which is
failing because stdout is closed (as it should be for a daemonized
application).  Something somewhere has flipped debugging information
on, and yet still forked the process off of the terminal.  Configuring
the app this way should be impossible - if its something in
configuration... if not, its just a bug where debug is being properly
activated after a fork.

-Aaron