Bug#949887: munin autopkgtest failure for sysvinit based tests

[Andreas Henriksson]

Hello,

While I don't know enough about how all of this works I think
I'd like to claim that this is a bug in munin (testsuite).
More details below.

On Sun, Jan 26, 2020 at 06:26:14PM +0100, Michael Biebl wrote:
> Package: munin,sysvinit-core
> Severity: serious
> 
> Hi,
> 
> the autopkgtest of munin currently fails, the
> master-cron autopkgtest using sysvinit-core fails with:
[...]
> autopkgtest [04:57:05]: test process requested reboot with marker into-sysv
> Failed to create rundir (/var/run/munin): Permission denied at /usr/share/munin/munin-update line 39.
[...]

Apparently the munin package is designed so that there's:
- a tmpfile(s) snippet that creates directories, including /run/munin
- an init script that exits on systemd but otherwise creates the
  directories that the tmpfile(s) snippet was supposed to create.
  (This feels quite WET, a more DRY solution would just be to hook up
  running systemd-tmpfiles which should work on sysvinit[0] as well.)

AFAIK on systemd tmpfiles are processed early and are guaranteed
to be handled by the time (normal) services are started.

When the autopkgtest is booted into sysvinit I assume there's a
race between the munin init script starting and the actual
tests running.

The crash quoted above, as far as I can tell, comes from:

[...]
> debian/tests/munin-master/01.master-components.t ..
> expecting success:
>   setuidgid munin /usr/share/munin/munin-update
>
>   not ok 1 - munin-update
>   #
>   #	  setuidgid munin /usr/share/munin/munin-update
>   #
[...]

The munin-update[1] program contains:

sub main {
    exit_if_run_by_super_user();
[...]
    my $update = Munin::Master::Update->new();
    $update->run();

    return 0;
}

The crash happens at the `$update->run();`[2] function call which
checks if /run/munin exists (which it apparently doesn't) and then
tries to create it[3].

As obvious by both the testsuite and the code, the program is *not*
being executed as root (but as munin user/group) and thus does not
have permission to create anything in (/var)/run.

I guess the problem can be fixed by adding as the first step in the
testsuite (running as root):
systemd-tmpfiles /usr/lib/tmpfiles.d/munin.conf

This should work on both systemd and sysvinit testbeds. It will
already have happened before on the systemd testbed but repeating
it should be harmless. (This however requires the systemd package
to be installed in the sysvinit testbed, so alternatively somehow
invoke the munin "service".)

(An alternative aproach which I don't know if it's possible would be
to investigate if you can somehow specify that the test-suite depends
on a particular init script to make sure things are started in the
right order on sysvinit testbed.)

Regards,
Andreas Henriksson

[0]: https://lists.debian.org/debian-devel/2020/01/msg00233.html
[1]: https://sources.debian.org/src/munin/2.0.54-1/master/_bin/munin-update.in/#L30
[2]: https://sources.debian.org/src/munin/2.0.54-1/master/lib/Munin/Master/Update.pm/#L45
[3]: https://sources.debian.org/src/munin/2.0.54-1/master/lib/Munin/Master/Update.pm/#L98