something went horribly wrong on the last update .
After the update of today, the server is not working anymore, here is how and why:
the file /var/webmin/miniserv.error takes up all the free space with a repeating line
“file=/etc/network/interfaces line=source-directory /etc/network/interfaces.d”
I tested on a new vps on a fresh install and it’s giving this error too.
The “fix” was to copy the content of the file inside /etc/network/interfaces.d to the file /etc/network/interfaces
Note that Webmin’s Network Configuration module also stops working showing the exact same error message: Error reading file /etc/network/interfaces: unexpected line ‘source-directory /etc/network/interfaces.d’
Rolling back to the previous version of Webmin seems to fix the problem too.
Short term, I believe you can turn off stats collection to make this stop, but I’m having a hard time imagining having a dozen or so lines added to the log every five minutes (which is what I’m seeing) could have consumed very much disk space. According to my math, it’s only gonna add up to a couple megabytes after several hours.
There must be something else going on on your server to have caused “horribly wrong” (unless you only had a couple/few MB of free disk space on /var, which isn’t a great idea).
not a couple/few MB of free disk space on /var, the server had 19Go of free space before the upgrade, the file /var/webmin/miniserv.error was exactly 19Go less than an hour after the upgrade.
I’m reinstalling virtualmin on a new vps right now to tell you what’s going on
OK, that’s very different from the behavior I’ve been able to reproduce.
I think we do need to see what’s in those files as Ilia requested.
You can stop (systemctl stop webmin) or downgrade it to the version that isn’t causing this problem (apt install webmin=2.001), until we get this sorted out. There’s no reason to do anything drastic, like restoring from backups or whatever.
# Include files from /etc/network/interfaces.d:
source-directory /etc/network/interfaces.d
# Cloud images dynamically generate config fragments for newly
# attached interfaces. See /etc/udev/rules.d/75-cloud-ifupdown.rules
# and /etc/network/cloud-ifupdown-helper. Dynamically generated
# configuration fragments are stored in /run:
source-directory /run/network/interfaces.d
inside /etc/network/interfaces.d there is one file, 50-cloud-init:
# This file is generated from information provided by the datasource. Changes
# to it will not persist across an instance reboot. To disable cloud-init's
# network configuration capabilities, write a file
# /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
# network: {config: disabled}
auto lo
iface lo inet loopback
dns-nameservers xxx:xxx:xxx:xxx
auto ens3
iface ens3 inet dhcp
accept_ra 0
mtu 1500
# control-alias ens3
iface ens3 inet6 static
address 2001:xxx:xxx:xxx::xxx/56
post-up route add -A inet6 default gw 2001:xxx:xxx:xxx::1 || true
pre-down route del -A inet6 default gw 2001:xxx:xxx:xxx::1 || true
ls -alh /etc/network
total 40K
drwxr-xr-x 7 root root 4.0K Jan 15 21:47 .
drwxr-xr-x 99 root root 4.0K Jan 15 21:40 ..
-rwxr-xr-x 1 root root 1.9K Oct 20 04:36 cloud-ifupdown-helper
-rw-r--r-- 1 root root 69 Oct 20 04:36 cloud-interfaces-template
drwxr-xr-x 2 root root 4.0K Jan 15 21:38 if-down.d
drwxr-xr-x 2 root root 4.0K Oct 20 04:35 if-post-down.d
drwxr-xr-x 2 root root 4.0K Oct 20 04:34 if-pre-up.d
drwxr-xr-x 2 root root 4.0K Jan 15 21:38 if-up.d
-rw-r--r-- 1 root root 377 Oct 20 04:36 interfaces
drwxr-xr-x 2 root root 4.0K Jan 15 21:48 interfaces.d
Yeah, that’s a different problem than the one we’ve been able to reproduce (which is that some debug messages didn’t get turned off), but the problem you’re seeing is much more serious and it’s good we had debug messages to trigger misbehavior so it’d be easier to see immediately after update!
I’m gonna guess that’s the problem. I’m trying to figure out if anything we would do would trigger it, but I can’t imagine we’d ever do that.
But, you definitely don’t need two identical source-directory lines.
I’m gonna test and see if that causes the problem on my test system…I bet it does (it’s still a bug, but your config file shouldn’t look like that, either).
@Jamie, if user has source-directory instead of standard source, i.e. source-directory /etc/network/interfaces.d/* instead of source /etc/network/interfaces.d/* then we are gotten stuck in an infinite loop!
Edit2: Ilia just pointed out to me that the two source-directory lines we’re talking about are not identical, which changes everything. Well, changes most things.
You should change both lines (do not delete either) to use source syntax instead of source-directory. Or shut down webmin and wait until we roll a fix.
Sorry for the confusion. Dang. This is weird stuff. I guess /run/network/interfaces.d is network mounted block storage that the hosting provider manages.
That’s the workaround to using 2.011 without it getting messy. You’ll still get a few extra log entries every five minutes, but they are mostly harmless (I see a half dozen lines every five minutes on my test system).
this is what I did on my prod server. the problem occured on today’s update, not before, the host didn’t changed anything lately (same debian 11 image)