[karmic] Upstart fixups

Bug #430220 reported by Michael Terry on 2009-09-15
34
This bug affects 5 people
Affects Status Importance Assigned to Milestone
rsyslog (Ubuntu)
Medium
Unassigned
Karmic
Medium
Unassigned

Bug Description

Binary package hint: rsyslog

After the recent upstart conversion, I looked at rsyslog. There were a few issues that I have a patch for:

1) The logrotate config file used invoke-rc.d reload. Which isn't supported by upstart, so logrotating wasn't restarting. Changed it to use the restart command.

2) The kmsg upstart script omitted the bs=1 argument, which is important to avoid buffering the kmsg pipe.

3) The kmsg fifo creation/deletion was still in the rsyslog upstart file, but I think it more properly belongs in the kmsg upstart file. This also involved changing the triggers for kmsg to 'starting rsyslog' and 'stopped rsyslog' so that kmsg is around for the whole lifecycle of rsyslog.

Related branches

Michael Terry (mterry) wrote :
Michael Terry (mterry) wrote :

Whoops, one with this bug number in the changelog.

Colin Watson (cjwatson) wrote :

Wouldn't 'service rsyslog restart' be more appropriate than 'restart rsyslog'? We seem to be converging on that as a standard.

Michael Terry (mterry) wrote :

Did not know that was preferred. Here's a new debdiff.

You shouldn't use service for native upstart jobs, just use "restart"

(in fact, you should use "reload" :p)

Michael Terry (mterry) wrote :

OK, here's one were we use reload again.

Johan Kiviniemi (ion) wrote :

How about using cat instead of dd, btw? dd bs=1 looks like:

read(0, "h", 1) = 1
write(1, "h", 1) = 1
read(0, "e", 1) = 1
write(1, "e", 1) = 1
read(0, "l", 1) = 1
write(1, "l", 1) = 1
read(0, "l", 1) = 1
write(1, "l", 1) = 1
read(0, "o", 1) = 1
write(1, "o", 1) = 1
read(0, "\n", 1) = 1
write(1, "\n", 1) = 1
read(0, "w", 1) = 1
write(1, "w", 1) = 1
read(0, "o", 1) = 1
write(1, "o", 1) = 1
read(0, "r", 1) = 1
write(1, "r", 1) = 1
read(0, "l", 1) = 1
write(1, "l", 1) = 1
read(0, "d", 1) = 1
write(1, "d", 1) = 1
read(0, "\n", 1) = 1
write(1, "\n", 1) = 1

where cat looks like:

read(0, "hello\n", 32768) = 6
write(1, "hello\n", 6) = 6
read(0, "world\n", 32768) = 6
write(1, "world\n", 6) = 6

Johan Kiviniemi (ion) wrote :

Btw, I thought I got a trace that looked like the one of cat by using dd obs=1 a couple of days ago, but I must have mixed up the trace files. dd obs=1 looks like:

read(0, "hello\n", 512) = 6
write(1, "h", 1) = 1
write(1, "e", 1) = 1
write(1, "l", 1) = 1
write(1, "l", 1) = 1
write(1, "o", 1) = 1
write(1, "\n", 1) = 1
read(0, "world\n", 512) = 6
write(1, "w", 1) = 1
write(1, "o", 1) = 1
write(1, "r", 1) = 1
write(1, "l", 1) = 1
write(1, "d", 1) = 1
write(1, "\n", 1) = 1

tags: added: patch
Joshua Timberman (jtimberman) wrote :

When my karmic system boots, I get this message on the console:

"Rather than invoking init scritps through /etc/init.d, use the service(8) utility, e.g. service S20rsyslog start

Since the script you are attemping to invoke has been converted to an Upstart job, you may also use the start(8) utility, e.g. start S20rsyslog
start: Unknown job: S20rsyslog"

Neil Wilson (neil-aldur) wrote :

Does using 'cat' rather than 'dd' delay the kernel logging output wrt what is in dmesg?

I'm quite comfortable with anything as long as 'tailf /var/log/kern.log' works as expected when you're inserting and unplugging devices.

Changed in rsyslog (Ubuntu):
status: New → Confirmed
Michael Terry (mterry) wrote :

I assume cat works similarly, but we're so close to final freeze that I'm not excited about changing it (in case it does behave differently). sysklogd (the previous logger) used dd, and rsyslog has been using dd this cycle. Maybe file a separate bug about using cat instead for Lucid?

Michael Terry (mterry) on 2009-10-14
Changed in rsyslog (Ubuntu):
milestone: none → ubuntu-9.10
Steve Langasek (vorlon) on 2009-10-15
Changed in rsyslog (Ubuntu Karmic):
importance: Undecided → Medium
status: Confirmed → Triaged
Steve Langasek (vorlon) wrote :

@@ -7,7 +7,7 @@
        delaycompress
        compress
        postrotate
- invoke-rc.d rsyslog reload > /dev/null
+ reload rsyslog >/dev/null 2>&1 || true
        endscript
 }

Why are we ignoring errors from 'reload'? Wouldn't it be better to identify causes of failures and handle them explicitly?

Anyway, uploading this for karmic, thanks!

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package rsyslog - 4.2.0-2ubuntu5

---------------
rsyslog (4.2.0-2ubuntu5) karmic; urgency=low

  Upstart fixups; LP: #430220
  * debian/rsyslog.logrotate: Use start command to restart rsyslog
  * debian/rsyslog.rsyslog-kmsg.upstart: Restore bs=1 parameter to dd
  * debian/rsyslog.upstart: Move kmsg fifo creation/deletion to kmsg
    upstart script.

 -- Michael Terry <email address hidden> Tue, 22 Sep 2009 16:10:24 -0700

Changed in rsyslog (Ubuntu Karmic):
status: Triaged → Fix Released

This system is suffering random take downs most days by a gales of 'reload' and 'rsyslog' tasks which multiply until swap space is exhausted. After that I dunno what happens.

I found that the reason that my system was being taken down was a crude reload script in /usr/local/sbin which I had written before the introduction of upstart.

Perhaps reload should be called using the explicit path ie. /usr/sbin/reload.

Similarly, the explicit path for cron has been removed causing the logrotate rule designed to filter out routine cron jobs to fail, see #435893

Wups, that should be #463471

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers