Dear Maintainer,

when the apt-all plugin is loaded (what is automatic on Debian because of
the package install script), then two cron lines in /etc/cron.d/munin-node

*/5 * * * *    root if [ -x /etc/munin/plugins/apt_all ]; then
/etc/munin/plugins/apt_all update 7200 12 >/dev/null; elif [ -x
/etc/munin/plugins/apt ]; then /etc/munin/plugins/apt update 7200 12
*/10 * * * *   root lslocks -o PATH | grep -e "^/var/lib/dpkg/lock$"
/etc/munin/plugins/apt_all update 7200 12 >/dev/null; elif [ -x
/etc/munin/plugins/apt ]; then /etc/munin/plugins/apt update 7200 12
when root is already runnin an installation or system update
or
when computer is offline.

They have a third side effect: if user tries to start installing a package
just after those lines started to run, then, root will receive the error
message "lock already locked by an other process", what is a missleading
message. The very first time I got this message, I checked all my
consoles: "in which console am  I already running apt ?" then, after
founding none "am I being hacked ?". And when I restarted the same
command, it worked => "why does it work now ? I did nothing to release the
lock". And this may be very missleading for an experienced debian admin
who is just starting to learn about munin.

The case I had this weekend: a production server was offline because of a
faulty cable. The server is a gateway for a full room of machines. Every
single machine generated one email per hour, for two days ... those
machines are designed to send only one message per week; so getting one
message per hour blew up the SMTP.

Here is a typical error email:

W: Failed to fetch http://ftp.fr.debian.org/debian/dists/stretch/InRelease  Temporary failure resolving 'ftp.fr.debian.org'
W: Failed to fetch http://security.debian.org/dists/stretch/updates/InRelease  Temporary failure resolving 'security.debian.org'
W: Failed to fetch http://ftp.fr.debian.org/debian/dists/stretch-updates/InRelease  Temporary failure resolving 'ftp.fr.debian.org'
W: Failed to fetch http://www.ubnt.com/downloads/unifi/debian/dists/unifi5/InRelease  Temporary failure resolving 'www.ubnt.com'
W: Some index files failed to download. They have been ignored, or old ones used instead.


1: installation of package should inform admin about the fact these two cron lines may lock apt a few seconds per hour.

2: you need to find a way to EASILY let admin customise if he want to run those lines, or use an alternate way to update apt (I have seen some propositions in other bugs)

3: create a conf file that will let admin choose
- if those lines should be completely silent (add 2>/dev/null)
- at which frequency they should be run

4: ideally I would like those commands to not lock apt; but I know it's not possible in Debian. Gentoo is designed to minimise the time laps when the locks are created, and allows parallel execution of installation procedures. Debian locks every thing all the time; and this bug is not asking to change this behaviour. But this bug need to workaround the fact a random cron task may randomly prevent admin from working, or may randomly prevent correct execution of admin scripts/interfaces. An old working debian may suddenly break just after installing munin.

The apt-all plugin may be interesting and helpfull; but that cron bit is toxic for me.

In particular, the plugin has a small design flaw: it only produces warnings when updates are available. It should also provide critical state when security updates are available !!! This would be very usefull !!!

While I am suggesting the creation of a conf file for apt-all and it's cron file, a conf file for this plugin would also help fixing several other bugs pending; like the one or two bugs about Debian Version.

There are good ideas in this plugin; but poorly implemented.

What I am wondering is: should be remove this plugin from automatic installation ? (keep the plugin in the repo, but do not automatically enable it during package install). I thinck it should be removed from automatic installation before we make it cleaner, more user friendly, and remove it's side effects. Or at the very least, rapidly add a warning during installation, or a curses pop-up question.
http://benoit.demaine.info <http://benoit.demaine.info/>/
If computing were an exact science, IT engineers would'nt have work \_o<

"So all that's left, Is the proof that love's not only blind but deaf."
(FAKE TALES OF SAN FRANCISCO, Arctic Monkeys)

Hello Benoît-Pierre,

thank you for your bug report!


Am Sun, 22 Apr 2018 12:38:46 +0200
schrieb Benoît-Pierre DEMAINE <benoit@demaine.info>:

just for the matter of correctness: only the first of the two cron jobs above
is part of the Debian package. The second one is probably a local addition.
But this detail is not relevant for the topic of your report.

Yes, indeed.
Thankfully you reported this separately in #849548.
Thus let us focus on the other issues.

Maybe you want to propose a set of changes upstream.
The munin-node.postinst script runs the following:

  munin-node-configure --shell

This uses only the "family" named "auto".
The "apt_all" plugin is part of the "manual" family. Thus it should not be
enabled without manual intervention.


Regarding the scope of this bug report:
I can understand, that you are not happy about receiving one email per hour of
downtime for each of your disconnected servers.  But I am uncertain how this
effect of a failure could be avoided without adding a lot of complexity to the
cron job (or whatever mode of update).


A possible alternative to the current cron-based approach could be to let the
user apply an apt configuration settings manually:

 APT::Periodic::Update-Package-Lists "1";

This would cause a daily run of "apt update" via crond or a systemd timer.
(less frequent than now, but probably still acceptable)

But this would require a manual configuration setting of the user, which is
admittedly hard to communicate along the usual flow of enabling a munin plugin.

What do you think?
Or maybe you have a different suggestion?

Cheers,
Lars

Yes, I have tried to partly fix the bug on some hosts, but in these lines,
I can't see any code I write; or I forgot about it.

I barely have time to report half bugs I find; no time to fix any of them.

Yes; I did not even specifically ask this plugin; just asked for munin,
and all plugins. The plugin is installed by default in /etc.

Maybe ... maybe I have set env variables to guide dpkg for non interactive
installation; but those settings are mostly set for locales and keyboard;
I don't remember setting anything for munin; here is the code I run now

/usr/bin/apt-get --no-remove --yes install munin-node munin-plugins-extra

and my
debconf-set-selections <<< "[...]"
section does not contain any line about munin.

It is.

Or was.

I don't have the bug on all machines, because very few machines are set
with exim; most of my machines don't have exim (or not configured).
never had this under Gentoo; this issue is specific to Debian. Other
package managers are able to handle parallel execution. So, it's from the
base, probably a bad idea to implement this cron task anyway. This type of
thing would not be an issue on other distros. But on Debian ... it should
be disables as soon as any user is logged in.

To avoid the email error:
- start by pinging/wget/curl the server before performing the apt thing (I
know, people with web proxy will be in trouble): curl mirror >/dev/null && apt
- disable output completely: >/dev/null 2>&1
- add a filter in exim
- grep -v "[our error]"
deep concepts of the Debian spirit. So I never understood the "Debian way
of things".

What I know is that, even I install packages manually, I may receive some
notifications in ncurses or "more/less" messages, and I need to aknoledge
them. In full non interactive setups, some package specific communications
are sent to me by email, when exim is configured. They usually talk about
major security changes in SSH, or Debian critical changes.

Those emails have the subject:
apt-listchanges: news for <HOST>

You could notify about whatever you want via this method.