Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Bug#672218: rsyslog: Logrotate error message

329 views
Skip to first unread message

Arne Wichmann

unread,
May 9, 2012, 4:30:04 AM5/9/12
to
Package: rsyslog
Version: 5.8.11-1
Severity: normal

Dear Maintainer,

For some time now I receive some new error messages by mail from cron:

/etc/cron.daily/logrotate:
invoke-rc.d: action rotate is unknown, but proceeding anyway.

As far as I can see they are coming from /etc/logrotate.d/rsyslog :

--- snip ---
postrotate
invoke-rc.d rsyslog rotate > /dev/null
endscript
--- snip ---

Greetings,

AW

-- System Information:
Debian Release: wheezy/sid
APT prefers testing
APT policy: (500, 'testing'), (500, 'stable'), (50, 'unstable'), (40, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.15 (SMP w/2 CPU cores; PREEMPT)
Locale: LANG=C, LC_CTYPE=de_DE (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash

Versions of packages rsyslog depends on:
ii initscripts 2.88dsf-22.1
ii libc6 2.13-32
ii lsb-base 4.1+Debian2
ii zlib1g 1:1.2.6.dfsg-2

Versions of packages rsyslog recommends:
ii logrotate 3.8.1-1

Versions of packages rsyslog suggests:
pn rsyslog-doc <none>
pn rsyslog-gnutls <none>
pn rsyslog-gssapi <none>
pn rsyslog-mysql | rsyslog-pgsql <none>
pn rsyslog-relp <none>

-- Configuration Files:
/etc/logcheck/ignore.d.server/rsyslog [Errno 13] Permission denied: u'/etc/logcheck/ignore.d.server/rsyslog'

-- debconf-show failed



--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Michael Biebl

unread,
Jan 23, 2013, 7:10:02 AM1/23/13
to
On 23.01.2013 12:41, Paul Slootman wrote:
> On Wed 23 Jan 2013, Michael Biebl wrote:
>> On 23.01.2013 11:47, Paul Slootman wrote:
>>
>>> The message is given by invoke-rc.d, NOT by the init script!
>
>> So it's the policy-rc.d layer which is causing that warning (not error)
>> message. What are you suggesting I should take into account here?
>> The only thing I can do is to stop using that crappy invoke-rc.d altogether.
>
> You're already redirecting away the standard output, how about also
> redirecting away standard error output?
>
> invoke-rc.d rsyslog rotate > /dev/null 2>&1
>
> Not very nice, but at least it will silence invoke-rc.d.

Eww, hiding real errors. I don't want to do that.

> Alternatively the sysv-rc people might want to provide some hook for
> invoke-rc.d so that policy-rc.d might indicate what to do with unknown
> actions. I've been looking but can't find any way of suppressing the
> invoke-rc.d output via the policy layer.
>
> invoke-rc.d rsyslog rotate 2>&1 > /dev/null | grep -v 'action rotate is unknown' >&2

That is super-ugly too.
I'm
more inclined to ditch the usage of invoke-rc.d altogether and simply
call the sysv init script directly or even drop the "action" from the
sysv init script and run "kill -SIGHUP $(cat /var/run/rsyslogd.pid)"
directly in the logrotate script.

Michael


--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

signature.asc

Paul Slootman

unread,
Jan 23, 2013, 7:10:02 AM1/23/13
to
reopen 672218
thanks

On Wed 09 May 2012, Michael Biebl wrote:
> On 09.05.2012 10:20, Arne Wichmann wrote:
> >
> > For some time now I receive some new error messages by mail from cron:
> >
> > /etc/cron.daily/logrotate:
> > invoke-rc.d: action rotate is unknown, but proceeding anyway.
> >
> > As far as I can see they are coming from /etc/logrotate.d/rsyslog :
> >
> > --- snip ---
> > postrotate
> > invoke-rc.d rsyslog rotate > /dev/null
> > endscript
> > --- snip ---
>
> You are not using the initscript that is provided by the Debian package:
>
> http://anonscm.debian.org/gitweb/?p=collab-maint/rsyslog.git;a=blob;f=debian/rsyslog.init;hb=HEAD#l119


That is NOT the problem.
I am getting the same on a clean install of a reasonably recent wheezy.

The message is given by invoke-rc.d, NOT by the init script!

This is what happens when I run it by hand:

# invoke-rc.d rsyslog rotate
invoke-rc.d: action rotate is unknown, but proceeding anyway.
[ ok ] Closing open files: rsyslogd.


>From the invoke-rc.d manpage:

INIT SCRIPT ACTIONS
The standard actions are: start, stop, force-stop, restart, reload,
force-reload, and status. Other actions are accepted, but they can
cause problems to policy-rc.d (see the INIT SCRIPT POLICY section), so
warnings are generated if the policy layer is active.

I have a /usr/sbin/policy-rc.d, and as "rotate" is not among those
mentioned above, invoke-rc.d gives a warning. rsyslog should take into
account those installations that choose to have /usr/sbin/policy-rc.d .


thanks,
Paul Slootman

Paul Slootman

unread,
Jan 23, 2013, 7:10:03 AM1/23/13
to
On Wed 23 Jan 2013, Michael Biebl wrote:
> On 23.01.2013 11:47, Paul Slootman wrote:
>
> > The message is given by invoke-rc.d, NOT by the init script!

> So it's the policy-rc.d layer which is causing that warning (not error)
> message. What are you suggesting I should take into account here?
> The only thing I can do is to stop using that crappy invoke-rc.d altogether.

You're already redirecting away the standard output, how about also
redirecting away standard error output?

invoke-rc.d rsyslog rotate > /dev/null 2>&1

Not very nice, but at least it will silence invoke-rc.d.
Alternatively the sysv-rc people might want to provide some hook for
invoke-rc.d so that policy-rc.d might indicate what to do with unknown
actions. I've been looking but can't find any way of suppressing the
invoke-rc.d output via the policy layer.

invoke-rc.d rsyslog rotate 2>&1 > /dev/null | grep -v 'action rotate is unknown' >&2

Might also work, sending stderr to the usual place although that will
exit with non-zero if there is no error, and vice versa :(


Paul

Paul Slootman

unread,
Jan 23, 2013, 7:20:02 AM1/23/13
to
On Wed 23 Jan 2013, Michael Biebl wrote:
> >
> > invoke-rc.d rsyslog rotate > /dev/null 2>&1
> >
> > Not very nice, but at least it will silence invoke-rc.d.
>
> Eww, hiding real errors. I don't want to do that.
>
> > Alternatively the sysv-rc people might want to provide some hook for
> > invoke-rc.d so that policy-rc.d might indicate what to do with unknown
> > actions. I've been looking but can't find any way of suppressing the
> > invoke-rc.d output via the policy layer.
> >
> > invoke-rc.d rsyslog rotate 2>&1 > /dev/null | grep -v 'action rotate is unknown' >&2
>
> That is super-ugly too.
> I'm
> more inclined to ditch the usage of invoke-rc.d altogether and simply
> call the sysv init script directly or even drop the "action" from the
> sysv init script and run "kill -SIGHUP $(cat /var/run/rsyslogd.pid)"
> directly in the logrotate script.

I'd do the kill -SIGHUP, after perhaps some sanity checking of the
pidfile (does it exist).


Thanks,

Roger Leigh

unread,
Jan 23, 2013, 8:40:01 AM1/23/13
to
clone 672218 -1
reassign -1 sysv-rc
retitle -1 sysv-rc: policy-rc.d/invoke-rc.d should better support unknown actions
thanks

On Wed, Jan 23, 2013 at 01:07:07PM +0100, Michael Biebl wrote:
> On 23.01.2013 12:41, Paul Slootman wrote:
> > On Wed 23 Jan 2013, Michael Biebl wrote:
> >> On 23.01.2013 11:47, Paul Slootman wrote:
> >>
> >>> The message is given by invoke-rc.d, NOT by the init script!
> >
> >> So it's the policy-rc.d layer which is causing that warning (not error)
> >> message. What are you suggesting I should take into account here?
> >> The only thing I can do is to stop using that crappy invoke-rc.d altogether.
> > Alternatively the sysv-rc people might want to provide some hook for
> > invoke-rc.d so that policy-rc.d might indicate what to do with unknown
> > actions. I've been looking but can't find any way of suppressing the
> > invoke-rc.d output via the policy layer.
> >
> > invoke-rc.d rsyslog rotate 2>&1 > /dev/null | grep -v 'action rotate is unknown' >&2
>
> That is super-ugly too.
> I'm
> more inclined to ditch the usage of invoke-rc.d altogether and simply
> call the sysv init script directly or even drop the "action" from the
> sysv init script and run "kill -SIGHUP $(cat /var/run/rsyslogd.pid)"
> directly in the logrotate script.

I'll have to look at the policy-rc.d stuff to see if we can sensibly
handle unknown actions. However, I would suspect it's difficult to
do so meaningfully primarily because they are unknown, unless we just
allow everything (which appears to be the default).

Until (and if) this is made possible, it certainly looks like
invoke-rc.d is probably not the ideal interface to use here.


Regards,
Roger

--
.''`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools
`- GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800

Michael Biebl

unread,
Jan 23, 2013, 10:10:03 AM1/23/13
to
Hi Roger,

On 23.01.2013 14:31, Roger Leigh wrote:
> Until (and if) this is made possible, it certainly looks like
> invoke-rc.d is probably not the ideal interface to use here.

What would be your recommendation? Call the init script directly?
signature.asc

Roger Leigh

unread,
Jan 23, 2013, 10:20:02 AM1/23/13
to
On Wed, Jan 23, 2013 at 03:59:59PM +0100, Michael Biebl wrote:
> Hi Roger,
>
> On 23.01.2013 14:31, Roger Leigh wrote:
> > Until (and if) this is made possible, it certainly looks like
> > invoke-rc.d is probably not the ideal interface to use here.
>
> What would be your recommendation? Call the init script directly?

I'm not sure I have a particularly good one. Other daemons e.g.
postfix use the daemon directly for this e.g. "postfix flush",
rather than extending the init script. In general, the actions
that the init scripts and tools allow are restricted to the usual
start/stop/restart/reload/status etc. and our tools don't
support extra actions (though it's certainly possible to add
them). For cases where you want to send commands to the daemon
that are not one of the above, it's really not in the (existing)
intended scope of an init script.

For the time being, I think signalling the running daemon
directly is probably OK. If supporting extended stuff across
init systems is needed, then we can certainly look at how best
to address this in invoke-rc.d, init scripts, etc. in jessie.

Martin Pitt

unread,
Jul 31, 2014, 5:20:02 AM7/31/14
to
Arne Wichmann [2012-05-09 10:20 +0200]:
> postrotate
> invoke-rc.d rsyslog rotate > /dev/null
> endscript

So what exactly would be wrong with just using "service" instead of
invoke-rc.d? Sure, that would call the init.d script also under
systemd, but do_rotate() is more or less just a fancy SIGHUP, so that
should work just fine? I tested it under systemd as well.

Thanks,

Martin
--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)

Michael Biebl

unread,
Aug 20, 2014, 1:10:02 PM8/20/14
to
Am 31.07.2014 11:05, schrieb Martin Pitt:
> Arne Wichmann [2012-05-09 10:20 +0200]:
>> postrotate
>> invoke-rc.d rsyslog rotate > /dev/null
>> endscript
>
> So what exactly would be wrong with just using "service" instead of
> invoke-rc.d? Sure, that would call the init.d script also under
> systemd, but do_rotate() is more or less just a fancy SIGHUP, so that
> should work just fine? I tested it under systemd as well.
>

Looks like this is no longer an issue.

Under current sid running invoke-rc.d rsyslog rotate, I get

# invoke-rc.d rsyslog rotate
[ ok ] Closing open files: rsyslogd.


I'm keeping this bug open though for now, as I eventually want to
replace the postrotate snippet with something which is not dependend on
the SysV init script. I'm currently leaning towards shipping a dedicated
helper script /usr/sbin/rsyslog-rotate, which runs something like

#!/bin/sh

if [ -d /run/systemd/system ] ; then
systemctl kill -s SIGHUP rsyslog.service
else
start-stop-daemon --stop --signal HUP --quiet --pidfile
/var/run/rsyslogd.pid --exec /usr/sbin/rsyslogd
fi



And then drop the "rotate" action from the SysV init script.
signature.asc
0 new messages