Bug#380434: munin-node silently refuses to start if /var/run/munin is not present
retitle 380434 deal with /var/run/munin gone AWOL severity 380434 wishlist tags 380434 fixed-upstream quit * Paul Radford In an effort to reduce FS writes on a system with a solid-state disk, I mount /var/run as a tmpfs, i.e. ramdisk. Other packages do not mind and create their /var/run/xxx directories as required, e.g. bind. When /var/run/munin is not present after a reboot, munin-node refuses to start but does not issue an error message. You arbitrarily delete contents of the munin-node package, and then consider it a bug that it doesn't work any longer? Please. There's already code to handle this situation in the upstream repositories, however. (To support Ubuntu, which does the same thing as you do, for some strange reason.) For what it's worth you'll end up with double the amount of writes with your setup (mkdir+pidfile creation vs. pidfile creation only). Regards -- Tore Anderson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#380434: munin-node silently refuses to start if /var/run/munin is not present
In an effort to reduce FS writes on a system with a solid-state disk, I mount /var/run as a tmpfs, i.e. ramdisk. Other packages do not mind and create their /var/run/xxx directories as required, e.g. bind. When /var/run/munin is not present after a reboot, munin-node refuses to start but does not issue an error message. You arbitrarily delete contents of the munin-node package, and then consider it a bug that it doesn't work any longer? Please. No, I consider it a bug that munin-node fails silently, without so much as an error message. I was only able to discover the cause via strace. I know that that is not a package maintainer's bug, but that you might fix it in the same way as mldonkey was fixed, with an init script tweak: http://www.mail-archive.com/ubuntu-bugs@lists.ubuntu.com/msg16629.html There's already code to handle this situation in the upstream repositories, however. (To support Ubuntu, which does the same thing as you do, for some strange reason.) For what it's worth you'll end up with double the amount of writes with your setup (mkdir+pidfile creation vs. pidfile creation only). I'm not troubled by more writes on the tmpfs. Thanks for the consideration, though. Regards Cheers, Paul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#380434: munin-node silently refuses to start if /var/run/munin is not present
* Paul Radford
No, I consider it a bug that munin-node fails silently, without so much
as an error message. I was only able to discover the cause via strace.
When you yank out essential data from underneath dpkg, all bets are
off. Anyway, I cannot reproduce the silent failure you're describing:
[EMAIL PROTECTED] :) sudo /etc/init.d/munin-node start
Starting munin-node: FAILED!
The log brings more information:
2006/07/31-16:12:09 Couldn't open pid file /var/run/munin/munin-node.pid
[No such file or directory].
at line 268 in file /usr/share/perl5/Net/Server.pm
2006/07/31-16:12:09 Server closing!
That's munin-node 1.2.3-1, on Debian Woody.
I know that that is not a package maintainer's bug, but that you might fix
it in the same way as mldonkey was fixed, with an init script tweak:
http://www.mail-archive.com/ubuntu-bugs@lists.ubuntu.com/msg16629.html
The following patch was commited to SVN a while back:
Index: munin-node.init
===
--- munin-node.init (revision 999)
+++ munin-node.init (working copy)
@@ -65,6 +65,14 @@
start() {
log_daemon_msg Starting Munin-Node
+ # /var/run could be a tmpfs filesystem,
+ # make sure that the pidfile directory exists
+ PIDDIR=${PIDFILE%/*}
+ if [ ! -d $PIDDIR ]; then
+ mkdir $PIDDIR
+ chmod 0755 $PIDDIR
+ chown munin $PIDDIR
+ fi
if pidofproc -p $PIDFILE $DAEMON /dev/null; then
log_progress_msg started beforehand
log_end_msg 0
I haven't actually tried it, but it looks correct to me. (Don't know
if this is how mldonkey was handled, though.)
I'm not troubled by more writes on the tmpfs.
Duh, of course. Thinko.
--
Tore Anderson
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#380434: munin-node silently refuses to start if /var/run/munin is not present
Tore Anderson wrote:
When you yank out essential data from underneath dpkg, all bets are
off. Anyway, I cannot reproduce the silent failure you're describing:
[EMAIL PROTECTED] :) sudo /etc/init.d/munin-node start
Starting munin-node: FAILED!
The log brings more information:
2006/07/31-16:12:09 Couldn't open pid file /var/run/munin/munin-node.pid
[No such file or directory].
at line 268 in file /usr/share/perl5/Net/Server.pm
2006/07/31-16:12:09 Server closing!
That's munin-node 1.2.3-1, on Debian Woody.
That's what I get for setting log level to 0 in munin-node.conf (/var
mounted read-only), I guess. *slaps forehead*. I had been looking for a
stdout message, but again that's upstream's decision. Sorry.
The following patch was commited to SVN a while back:
Index: munin-node.init
===
--- munin-node.init (revision 999)
+++ munin-node.init (working copy)
@@ -65,6 +65,14 @@
start() {
log_daemon_msg Starting Munin-Node
+ # /var/run could be a tmpfs filesystem,
+ # make sure that the pidfile directory exists
+ PIDDIR=${PIDFILE%/*}
+ if [ ! -d $PIDDIR ]; then
+ mkdir $PIDDIR
+ chmod 0755 $PIDDIR
+ chown munin $PIDDIR
+ fi
if pidofproc -p $PIDFILE $DAEMON /dev/null; then
log_progress_msg started beforehand
log_end_msg 0
I haven't actually tried it, but it looks correct to me. (Don't know
if this is how mldonkey was handled, though.)
Yes, that looks perfect and is similar to my own modification. Thanks.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#380434: munin-node silently refuses to start if /var/run/munin is not present
On Mon, Jul 31, 2006 at 12:35:44PM +0200, Tore Anderson wrote: There's already code to handle this situation in the upstream repositories, however. (To support Ubuntu, which does the same thing as you do, for some strange reason.) It isn't particularly strange; Ubuntu uses a tmpfs for /var/run now. -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#380434: munin-node silently refuses to start if /var/run/munin is not present
* Matt Zimmerman It isn't particularly strange; Ubuntu uses a tmpfs for /var/run now. Which is exactly what I find strange. I asked Tollef about it the other day, and understood it simplified some cleanup script slightly. Hardly something worth breaking heaps of packages, local applications and distribution compability over, in my humble opinion. Anyway, the next version of Munin will handle this situation (and I believe my co-maint has already uploaded a version with the fix to Ubuntu's universe). -- Tore Anderson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#380434: munin-node silently refuses to start if /var/run/munin is not present
* Paul Radford That's what I get for setting log level to 0 in munin-node.conf (/var mounted read-only), I guess. *slaps forehead*. I had been looking for a stdout message, but again that's upstream's decision. Sorry. I believe that by the time it bombs out, it has already detached from the terminal, so it's unable to print it there. (I may be mistaken, though.) Stdout message or no, as long as the init script correctly detected that the start of the daemon process failed, printed a FAILED message to warn about that (and gave the correct return code), I feel more cannot be expected. But of course, patches would be welcome. ;-) I just hope I get around to preparing a new release soon. There hasn't been much activity neither from upstream nor me lately, I'm afraid... It'll probably be more fun to be indoors in autumn! -- Tore Anderson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#380434: munin-node silently refuses to start if /var/run/munin is not present
On Mon, Jul 31, 2006 at 05:06:38PM +0200, Tore Anderson wrote: * Matt Zimmerman It isn't particularly strange; Ubuntu uses a tmpfs for /var/run now. Which is exactly what I find strange. I asked Tollef about it the other day, and understood it simplified some cleanup script slightly. That isn't accurate. It solves a number of real problems, such as the situation where a pid file needs to be written there, but the root filesystem is mounted read-only (or even not mounted yet, e.g. initramfs). -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#380434: munin-node silently refuses to start if /var/run/munin is not present
* Matt Zimmerman That isn't accurate. It solves a number of real problems, such as the situation where a pid file needs to be written there, but the root filesystem is mounted read-only (or even not mounted yet, e.g. initramfs). Good point. Would've been nice if those files were moved back to a proper /var/run as soon as possible after it became writable, though. That would probably have fixed the early-userspace problem without breaking late-userspace. But I guess it's too late for that now. -- Tore Anderson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#380434: munin-node silently refuses to start if /var/run/munin is not present
Package: munin-node Version: 1.2.3-1 In an effort to reduce FS writes on a system with a solid-state disk, I mount /var/run as a tmpfs, i.e. ramdisk. Other packages do not mind and create their /var/run/xxx directories as required, e.g. bind. When /var/run/munin is not present after a reboot, munin-node refuses to start but does not issue an error message. Perhaps a simple fix would be adding mkdir -p /var/run/munin or similar to the init.d script. System info: Debian Linux 3.1 sarge, i686 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
