[karmic] Upstart fixups

Whoops, one with this bug number in the changelog.

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

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)

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

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

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

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"

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.

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?

@@ -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!

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

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