Bug#896561: munin: plugin apt-all generates load of emails
>> 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 >>> /dev/null; fi >> */10 * * * * root lslocks -o PATH | grep -e "^/var/lib/dpkg/lock$" >>> /dev/null || 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 >>> /dev/null; fi > 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, 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. >> 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 !!! > Maybe you want to propose a set of changes upstream. I barely have time to report half bugs I find; no time to fix any of them. > > >> 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). [..] > Are you sure, that the apt_all plugin was enabled automatically on your host? 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. > 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. 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). > 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). Regarding the fact it's impossible to run two apt-get un parallele, I 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]" > 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? > I have not read the complete Debian guidelines, and never understood the 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 You could notify about whatever you want via this method. -- >o_/ DEMAINE Benoît-Pierre (aka DoubleHP) 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."
Bug#896561: munin: plugin apt-all generates load of emails
Hello Benoît-Pierre, thank you for your bug report! Am Sun, 22 Apr 2018 12:38:46 +0200 schrieb Benoît-Pierre DEMAINE : > 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 > >/dev/null; fi > */10 * * * * root lslocks -o PATH | grep -e "^/var/lib/dpkg/lock$" > >/dev/null || 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 > >/dev/null; fi 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. > 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", [..] Yes, indeed. Thankfully you reported this separately in #849548. Thus let us focus on the other issues. > 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 !!! Maybe you want to propose a set of changes upstream. > 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). [..] Are you sure, that the apt_all plugin was enabled automatically on your host? 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
Bug#896561: munin: plugin apt-all generates load of emails
Package: munin Version: 2.0.33-1 Severity: minor 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 >/dev/null; fi */10 * * * * root lslocks -o PATH | grep -e "^/var/lib/dpkg/lock$" >/dev/null || 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 >/dev/null; fi They generate garbage email in two cases: 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. -- System Information: Debian Release: 9.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-6-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages munin depends on: ii cron [cron-daemon]3.0pl1-128+deb9u1 ii fonts-dejavu-core 2.37-1 ii libdate-manip-perl6.57-1 pn
