Blacklisted modules spam syslogs

Bug #66423 reported by Rocco Stanzione
30
This bug affects 1 person
Affects Status Importance Assigned to Milestone
module-init-tools (Ubuntu)
Fix Released
Low
Unassigned

Bug Description

If I blacklist a module - say, ipv6 - I get one message per minute in my syslog like so:
modprobe: WARNING: Not loading blacklisted module ipv6
This looks to have been introduced a while back by debian/patches/blacklist-warn.diff. Since spammy logs make life harder, not easier, I'm calling this buggy behavior.

Changed in module-init-tools:
importance: Undecided → Wishlist
Revision history for this message
Scott James Remnant (Canonical) (canonical-scott) wrote :

What keeps trying to load the ipv6 module?

Revision history for this message
Rocco Stanzione (trappist) wrote :

That's a pretty good question. Can you think of any strategies for figuring that out?

Changed in module-init-tools:
importance: Wishlist → Low
status: Unconfirmed → Confirmed
Revision history for this message
Juan Pablo Salazar Bertín (snifer) wrote :

Confirmed in Feisty Beta, all updates applied.
ipv6 module is blacklisted by default, and i get a lot of warnings in my logs.

Revision history for this message
rfried (rfried) wrote : find process triggering module load

I've disable ipv6 for sshd daemon.
Each ssh login has triggered an modprobe and generates a WARNING in syslog
--
--- sshd_config.ori 2007-04-16 16:42:10.000000000 +0200
+++ sshd_config 2007-04-16 16:42:21.000000000 +0200
@@ -1,6 +1,7 @@
 # Package generated configuration file
 # See the sshd(8) manpage for details

+AddressFamily inet
 # What ports, IPs and protocols we listen for
 Port 22
 # Use these options to restrict which interfaces/protocols sshd will bind to
--

I monitored module loads with this little shell script ...
/sbin/modprobe.my:
--
#!/bin/sh
{
echo
echo -n "==>"; date
echo
echo params: $@
echo
ps xaufwwww
echo
env
} >>/tmp/modprobe.log
exec modprobe.bin $@
--
mv /sbin/modprobe /sbin/modprobe.real; mv /sbin/modprobe.my /sbin/modprobe
=> and look processtree in /tmp/modprobe.log
=> when finished, do not forget to switsch /sbin/modprobe back ;-)

King Regards,
 Roland

Revision history for this message
Benjamin Braatz (hepta-sean-deactivatedaccount) wrote :

I can still confirm this on Hardy:
Apr 23 00:57:08 amalthea NetworkManager: <info> Supplicant state changed: 1
Apr 23 00:57:32 amalthea modprobe: WARNING: Not loading blacklisted module ipv6
Apr 23 00:57:33 amalthea last message repeated 7 times
Apr 23 00:59:01 amalthea last message repeated 6 times
Apr 23 00:59:18 amalthea last message repeated 47 times
Apr 23 01:01:28 amalthea NetworkManager: <info> Supplicant state changed: 0
Apr 23 01:01:29 amalthea NetworkManager: <info> Supplicant state changed: 1
Apr 23 01:03:46 amalthea NetworkManager: <info> Supplicant state changed: 0
Apr 23 01:03:50 amalthea NetworkManager: <info> Supplicant state changed: 1
Apr 23 01:04:26 amalthea modprobe: WARNING: Not loading blacklisted module ipv6
Apr 23 01:04:28 amalthea last message repeated 12 times
Apr 23 01:07:25 amalthea modprobe: WARNING: Not loading blacklisted module ipv6
Apr 23 01:07:25 amalthea last message repeated 2 times

In fact, it's even worse than in the original bug, since these are multiple calls to modprobe *per second*.
I don't know if these calls have anything to do with the NetworkManager messages (another kind of syslog spam).

I've attached the output of one of the "ps xaufwwww" in Roland's script above.
It doesn't tell too much, though, because modprobe is called from [khelper] in [kthreadd], so I suppose it's the kernel autoloader. (?)

PS: Does the performance and syslog spam effect of 248 calls to modprobe in two minutes ...
Apr 23 01:24:34 amalthea modprobe: WARNING: Not loading blacklisted module ipv6
Apr 23 01:24:56 amalthea last message repeated 184 times
Apr 23 01:26:05 amalthea last message repeated 52 times
Apr 23 01:26:37 amalthea last message repeated 11 times
... qualify this bug to be a little more urgent.

Revision history for this message
Imre Gergely (cemc) wrote :

I've just installed Hardy for my server, and installed PowerDNS as the authoritative DNS server. Every time i make a query (like 'host -r whatever localhost'), this message appears in the syslog:

Apr 27 15:25:51 ds9n modprobe: WARNING: Not loading blacklisted module ipv6

After installing ubuntu, i've disabled ipv6 support (as i don't need it right now, and it just bothers me, i've blacklisted it in /etc/modprobe.d).

Revision history for this message
Valentin Neacsu (valentin.neacsu) wrote :

Same problem here, fresh install of Hardy Server and blacklisted ipv6 in /etc/modprobe.d.

May 7 00:14:20 server-hostname modprobe: WARNING: Not loading blacklisted module ipv6
May 7 00:14:29 server-hostname modprobe: WARNING: Not loading blacklisted module ipv6
May 7 00:15:31 server-hostname modprobe: WARNING: Not loading blacklisted module ipv6
May 7 00:16:37 server-hostname modprobe: WARNING: Not loading blacklisted module ipv6
May 7 00:17:40 server-hostname modprobe: WARNING: Not loading blacklisted module ipv6
May 7 00:18:49 server-hostname modprobe: WARNING: Not loading blacklisted module ipv6
May 7 00:19:56 server-hostname modprobe: WARNING: Not loading blacklisted module ipv6
May 7 00:26:08 server-hostname modprobe: WARNING: Not loading blacklisted module ipv6
May 7 00:27:52 server-hostname modprobe: WARNING: Not loading blacklisted module ipv6
May 7 00:40:23 server-hostname modprobe: WARNING: Not loading blacklisted module ipv6

Revision history for this message
TS (dreammaster-max) wrote :

Excerpt from syslog:

Aug 9 07:39:01 hostname modprobe: WARNING: Not loading blacklisted module rt2500usb
Aug 9 07:39:32 hostname last message repeated 224 times
Aug 9 07:40:33 hostname last message repeated 448 times
Aug 9 07:41:33 hostname last message repeated 461 times
Aug 9 07:42:33 hostname last message repeated 440 times
Aug 9 07:43:33 hostname last message repeated 446 times
Aug 9 07:44:32 hostname last message repeated 432 times
Aug 9 07:45:33 hostname last message repeated 446 times

.....I assume this is not good. Could this have anything to do with aliases being loaded from udev modprobe rules?

Revision history for this message
Imre Gergely (cemc) wrote :

Confirmed this exists in Intrepid also. How to reproduce:

root@voy:~# date
Wed Feb 25 01:04:12 EET 2009

root@voy:~# host www.ubuntu.com localhost
;; connection timed out; no servers could be reached

root@voy:~# cat /var/log/syslog |grep ipv6 | tail -1
Feb 25 01:04:17 voy modprobe: WARNING: Not loading blacklisted module ipv6

Try to resolve any hostname using localhost as the nameserver, where there's actually no nameserver running on localhost.

Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package module-init-tools - 3.7~pre7-1

---------------
module-init-tools (3.7~pre7-1) jaunty; urgency=low

  * Repackage afresh for Ubuntu based off an upstream GIT import into bzr,
    rather than the Debian package.
  * New upstream pre-release:
    - many bug fixes. LP: #99547, #292887, #303613, #284001.
    - much profiling and optimisation work.
    - depmod generates and modprobe uses binary indexes for module lists,
      giving a significant performance benefit.
    - legacy support for pre-2.6 kernels dropped.
    - module ordering support. LP: #118040, #317724.
    - updated documentation. LP: #203828, #259791.

  * /etc/modprobe.d/aliases: Dropped this file, the kernel has been able to
    export the {char,block}-major-* aliases for a while and adding them to the
    appropriate modules is a one line patch. All aliases present here have
    been added to the Ubuntu kernel if not already present. LP: #332357.
  * /etc/modprobe.d/isapnp: Dropped this file, the modalias strings in it were
    not current with the strings produced by pnpacpi in the kernel (pnpbios
    does not produce any modalias strings), and this kind of thing is better
    off done with kernel patches.
  * /etc/modprobe.d/options: Dropped this file, changes to default kernel
    options should be changed in the kernel so that they also take effect if
    the module is built-in; and also to make sure they're kept in sync with
    any changes to option names or defaults (or even module names) in the
    kernel.
  * /etc/modprobe.d/arch/*, /etc/modprobe.d/arch-aliases: Dropped the arch
    directory and the symlink into it, these aliases and/or options are
    handled by kernel patches now.

  * /etc/modprobe.d/blacklist-amd76-edac: Merged with the ordinary blacklist
    file, since it only contains one line.
  * /etc/modprobe.d/blacklist{,-*}: Files renamed to end in ".conf" as
    required by new upstream version.a

  * /sbin/update-modules: This deprecated command has been removed.
  * Completely non-parallel-installable with modutils. LP: #208874.

  * All patches either merged upstream or dropped:
    - always_apply_blacklist: merged
    - blacklist-warn.diff: dropped. LP: #66423.
    - fix_8bit: merged
    - fix_sgml: merged
    - ignore_arch_directory: dropped
    - insmod-segv: merged
    - last_good_boot: dropped
    - modprobe_conf_and_directory: dropped
    - runparts_like_names: merged
    - silence_modprobe: dropped
    - use_blacklist_doc: merged

  * Note that from this version of module-init-tools, all configuration files
    in /etc/modprobe.d should end with ".conf", support for other names is
    retained with a warning but will be dropped.
  * Note that the Ubuntu -Q option to modprobe has been dropped, to silence
    modprobe use -q.

 -- Scott James Remnant <email address hidden> Mon, 09 Mar 2009 17:13:55 +0000

Changed in module-init-tools:
status: Confirmed → Fix Released
Revision history for this message
Ralph Dratman (ralph-dratman) wrote :

Scott (aka Launchopad Janitor),

Can or should the aforementioned update (module-init-tools (3.7~pre7-1) jaunty; urgency=low)
be installed on top of Hardy? If not, should another workaround be used?

This ipv6 warning is spamming my syslog too. I just experienced a comm outage for reasons not yet clear, and I wondered if this was related. Now I'm assuming no, but it's one more message to sort through, and I'd like to stop it.

Thank you.

Ralph Dratman
<email address hidden>

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.