Autoshutdown-Plugin not working under OMV v4 and Debian Stretch with 4.12 kernel

Huberer · Oct 2nd 2017

Hello,

I've the following issue with the, for me very important plugin, Autoshutdown. This plugin is not working under OMV v4 and the reason (I strongly believe) has something to do with the naming of the network-card.
Under OMV v3 with Debian Jessie and back port kernel the name of the ethernet card was "eth0" but under OMV v4 with back port kernel the name of the ethernet card is "enp0s25" and it's impossible (for me) to change it into eth0 or eth1...

When I start Autoshutdown-Plugin the dashboard shows me that's enabled but there's a red dot under "running":

When I have a look under the log file I can see the following error:

Code

Oct  2 20:28:30 HomeServer root: autoshutdown[3724]: INFO: ' Reading NICs ,IPs, ...'
Oct  2 20:28:30 HomeServer root: autoshutdown[3724]: INFO: ' NIC 'bond0' not found, skipping 'bond0''
Oct  2 20:28:30 HomeServer root: autoshutdown[3724]: INFO: ' NIC 'eth0' not found, skipping 'eth0''
Oct  2 20:28:30 HomeServer root: autoshutdown[3724]: INFO: ' NIC 'eth1' not found, skipping 'eth1''
Oct  2 20:28:30 HomeServer root: autoshutdown[3724]: WARN: ' No SERVERIP or CLASS found'
Oct  2 20:28:30 HomeServer root: autoshutdown[3724]: WARN: ' exiting ...'
Oct  2 20:31:03 HomeServer logger: autoshutdown[4230]: INFO: ' XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX'
Oct  2 20:31:03 HomeServer autoshutdown.sh[4230]: <182>Oct  2 20:31:03 logger: autoshutdown[4230]: INFO: ' XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX'
Oct  2 20:31:03 HomeServer logger: autoshutdown[4230]: INFO: ' XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX'
Oct  2 20:31:03 HomeServer autoshutdown.sh[4230]: <182>Oct  2 20:31:03 logger: autoshutdown[4230]: INFO: ' XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX'
Oct  2 20:31:03 HomeServer logger: autoshutdown[4230]: INFO: ' XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX'
Oct  2 20:31:03 HomeServer autoshutdown.sh[4230]: <182>Oct  2 20:31:03 logger: autoshutdown[4230]: INFO: ' XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX'
Oct  2 20:31:03 HomeServer logger: autoshutdown[4230]: INFO: ' X Version: 0.9.9.10'
Oct  2 20:31:03 HomeServer autoshutdown.sh[4230]: <182>Oct  2 20:31:03 logger: autoshutdown[4230]: INFO: ' X Version: 0.9.9.10'
Oct  2 20:31:03 HomeServer logger: autoshutdown[4230]: INFO: ' Initialize logging to local6'
Oct  2 20:31:03 HomeServer autoshutdown.sh[4230]: <182>Oct  2 20:31:03 logger: autoshutdown[4230]: INFO: ' Initialize logging to local6'
Oct  2 20:31:03 HomeServer root: autoshutdown[4230]: INFO: ' /etc/autoshutdown.conf loaded'

Display More

What I did (because of info in the readme) was that I've added the following entry to the "extra options"

after restart of the Autoshutdown-Plugin there is the following message in the log file:

Code

Oct  2 20:31:03 HomeServer root: autoshutdown[4230]: WARN: ' Invalid parameter format: FORCE_NIC'
Oct  2 20:31:03 HomeServer root: autoshutdown[4230]: WARN: ' You set it to 'enp0s25', which is not a correct syntax. It has to match '[a-z]{3,}[0-9]{1}\.{0,1}[0-9]{0,$
Oct  2 20:31:03 HomeServer root: autoshutdown[4230]: WARN: ' with spaces between every NIC: e.g. "eth1 wlan0 usb3 eth1.2"'
Oct  2 20:31:03 HomeServer root: autoshutdown[4230]: WARN: ' Unsetting FORCE_NIC'
Oct  2 20:31:03 HomeServer root: autoshutdown[4230]: INFO: ' ------------------------------------------------------'
Oct  2 20:31:03 HomeServer root: autoshutdown[4230]: INFO: ' Reading NICs ,IPs, ...'
Oct  2 20:31:03 HomeServer root: autoshutdown[4230]: INFO: ' NIC 'bond0' not found, skipping 'bond0''
Oct  2 20:31:03 HomeServer root: autoshutdown[4230]: INFO: ' NIC 'eth0' not found, skipping 'eth0''
Oct  2 20:31:03 HomeServer root: autoshutdown[4230]: INFO: ' NIC 'eth1' not found, skipping 'eth1''
Oct  2 20:31:03 HomeServer root: autoshutdown[4230]: WARN: ' No SERVERIP or CLASS found'
Oct  2 20:31:03 HomeServer root: autoshutdown[4230]: WARN: ' exiting ...'

Display More

and Autoshutdown is still not working. I'm pretty sure that is has something to do with the naming of the ethernet-(onboard)-card.

How can I/we solve this issue?

Thanks in advance

Huberer · Oct 2nd 2017

Now, I found the reason because of the "fu**ing" naming of the ethernet card and also a solution to that. It's not a OMV v4 bug, nor it has something to do with Debian stretch and the new naming of the ethernet cards (don't ask me why). Here is the solution to get back to the old naming.

And here are the proofs for that:

Unfortunately there's still a bug showing in the log file but it looks the ASD is working:

Code

Oct  2 21:26:23 HomeServer root: autoshutdown[2993]: INFO: ' Reading NICs ,IPs, ...'
Oct  2 21:26:23 HomeServer root: autoshutdown[2993]: INFO: ' NIC 'bond0' not found, skipping 'bond0''
Oct  2 21:26:23 HomeServer root: autoshutdown[2993]: INFO: ' NIC 'eth0' found: try to get IP'
Oct  2 21:26:23 HomeServer root: autoshutdown[2993]: INFO: ' _check_networkconfig(): Run: #1: IP-Adress found'
Oct  2 21:26:23 HomeServer root: autoshutdown[2993]: INFO: ' 'eth0' has IP:         inet 192.168.1.200  netmask 255.255.255.0  broadcast 192.168.1.255'
Oct  2 21:26:23 HomeServer root: autoshutdown[2993]: WARN: ' Invalid parameter format: Class: nnn.nnn.nnn]'
Oct  2 21:26:23 HomeServer root: autoshutdown[2993]: WARN: ' It is set to 'inet 192.168.1.200 netmask 255.255.255.0 broadcast 192.168.1', which is not a correct synta$
Oct  2 21:26:23 HomeServer root: autoshutdown[2993]: WARN: ' Please report this Bug and the CLI-output of 'ifconfig''
Oct  2 21:26:23 HomeServer root: autoshutdown[2993]: WARN: ' unsetting NIC[2]: eth0 ...'
Oct  2 21:26:23 HomeServer root: autoshutdown[2993]: WARN: ' Invalid parameter format: SERVERIP [iii]'
Oct  2 21:26:23 HomeServer root: autoshutdown[2993]: WARN: ' It is set to '255', which is not a correct syntax. Maybe parsing 'ifconfig' did something wrong'
Oct  2 21:26:23 HomeServer root: autoshutdown[2993]: WARN: ' Please report this Bug and the CLI-output of 'ifconfig''
Oct  2 21:26:23 HomeServer root: autoshutdown[2993]: WARN: ' unsetting NIC[2]:  ...'
Oct  2 21:26:23 HomeServer root: autoshutdown[2993]: INFO: ' NIC 'eth1' not found, skipping 'eth1''

Display More

And this is how [tt]nano /etc/network/interfaces/tt] looks like

Code

The loopback network interface
auto lo
iface lo inet loopback


# eth0 network interface
auto eth0
allow-hotplug eth0
iface eth0 inet static
    address 192.168.1.200
    gateway 192.168.1.1
    netmask 255.255.255.0
    dns-nameservers 8.8.8.8 8.8.4.4
    pre-down ethtool -s $IFACE wol g
iface eth0 inet6 manual
    pre-down ip -6 addr flush dev $IFACE

Display More

Huberer · Oct 2nd 2017

So, next answer but not showing up this thread in the forum...

I also found another solution here which could be better than the one before. Maybe someone can test this solution and post the log of ASD which (maybe) doesn't show this error message with the "invalid parameter"

tkaiser · Oct 3rd 2017

Quote from Huberer

Under OMV v3 with Debian Jessie and back port kernel the name of the ethernet card was "eth0" but under OMV v4 with back port kernel the name of the ethernet card is "enp0s25"

Yes, things are changing and the change is explained here: https://wiki.debian.org/Networ…e_Network_Interface_Names

Quote from Huberer

it's impossible (for me) to change it into eth0 or eth1...

There's a bunch of options to do this but the only real solution is to make OMV and plugins compatible to the conventions of the underlying operating system. Maybe you might rephrase the contents of this thread to transform it into a nice, small and understandable bug report?

Huberer · Oct 3rd 2017

@tkaiser

First, thanks for making my post visible. While searching for a solution (i already posted above) I found out that the new naming of the ethernet card is enx+mac-address. But only if you make a clean Installation of Debian Stretch. When you upgrade from Jessie to Stretch the old naming with eth0, eth1,.. sustain (hopefully is this the correct word).
The main problem will be the naming of the ethernet card because of the new "Predictable Network Interface Names". That means that the mac address is responsible for the name of the ethernet card. There's no fix naming anymore. Like in the first link above where the user is talking about a "ens33" network name and, in my case, I have "enp0s25" as name for network name.

I don't know who is the mantainer of the ASD-plugin but I believe adopting the program code will be a challenge. Maybe @ryecoaaron has an idea how to solve this issue.

tkaiser · Oct 3rd 2017

Quote from Huberer

That means that the mac address is responsible for the name of the ethernet card. There's no fix naming anymore.

It's just the opposite. We had ABSOLUTELY non predictable interface names in the past (depending on BIOS (bugs) and order of driver loading you could end up with your nice network separation relying on interface names doing exactly the opposite after the system came up with different interface names), now it's a little bit better.

As usual: changes need adoption. One of the reasons OMV 4.x is not marked as stable right now.

Huberer · Oct 3rd 2017

Didn't know that the new naming is better then the old one. I thought that's better to use eth0, eth1, and so on.

I know that OMV 4.x is not stable right now but I think the network naming has nothing to do with OMV (just my 2 Cents) itselfs. Only because of the new naming the Autoshutdown-Plugin is not working properly anymore (when you do a fresh install). Hopefully someone is smart enough to fix it. Unforutnately I'm not that one (just a simple user).

thanks anyway

tkaiser · Oct 3rd 2017

Quote from Huberer

I know that OMV 4.x is not stable right now but I think the network naming has nothing to do with OMV (just my 2 Cents) itselfs.

OMV sits on top of Debian, right? That's not exactly a 'nothing to do with' situation. Care to remember why the transition from OMV 2 to 3 took that long? Since underlying Debian switched from sysv init to systemd which required changes here and there. Now with OMV 4 and Debian 9 there's another minor glitch to solve.

To understand why the new scheme is somewhat better than the old one you need more than one NIC and a situation where interface names changed (can happen eg. if you have been using a kernel where one NIC driver was built as a module and then after next kernel update included, or just some BIOS mess, or $whatever). If you build a firewall box where eth0 is WAN and eth1 is LAN and you reboot after a kernel update (or anything that could've changed interface names due to different driver loading order) and nothing is working any more you feel the need for predictable interface names already.

And no, not everything that is different is evil.

tkaiser · Oct 3rd 2017

$FORCE_NIC validation regex is not suitable for Debian 9 any more and the fallback to just 'bond0 eth0 eth1' is something I would call naive anyway

Most probably walking through 'ip link' output grepping for '^eth|^en|^bond' would already be sufficient...

Huberer · Oct 3rd 2017

Quote from tkaiser

$FORCE_NIC validation regex is not suitable for Debian 9 any more and the fallback to just 'bond0 eth0 eth1' is something I would call naive anyway

You're absolutely right. That's why I've started this thread because ASD is not working anymore under OMV v4/Debian 9 (when you make a clean installation - when you upgrade from OMV v3 => v4 the old naming remains).

Quote from tkaiser

Most probably walking through 'ip link' output grepping for '^eth|^en|^bond' would already be sufficient...

It sounds easy for someone who knows what to do but not for me otherwise I would already change it.

tkaiser · Oct 3rd 2017

Quote from Huberer

when you upgrade from OMV v3 => v4 the old naming remains

Yes, that's known and documented behaviour (see link to Debian wiki above). Doesn't change anything though since the 'old naming' is already declared deprecated in Stretch and won't be available in next Debian generation anyway. So all software relying on the primitive old scheme has to be adopted anyway sooner or later.

I just looked quickly into it to see whether that's an easy fix or not but won't spend more time on this other than explaining again and again that 'changes aren't evil'

(I prefer running OMV on devices that consume less in idle than those PC thingies when 'powered off' where people want to run this autoshutdown stuff)

Huberer · Oct 3rd 2017

I never said that changes are evil. I started this thread because of an incompatibility between Debian Stretch and Autoshutdown-Plugin.
I found some solutions to get ASD to work but these are just work-arounds I found. In my case the first test killed my ethernet access so I had to connect the server to a monitor and keyboard to fix everything via CLI.

I also found your thread about the ARM-based boards but I need power (for video transcoding and, at least one, VM) so this is not an option.

My hope is that someone can fix this new circumstance under ASD so that no workaround and pass-by the old naming system is needed.

tkaiser · Oct 3rd 2017

Quote from Huberer

I never said that changes are evil.

Well, talking about "f**cking" naming... anyway, doesn't matter, the obvious fix has to be adopted by the OMV plugin (which is quite easy in this case but that might not be true for all other plugins/extras that rely/depend on the old naming scheme. And an interesting observation really is that interface naming behaviour is different between an upgraded and a fresh Stretch installation since I would believe most developers so far tested with upgraded installation and weren't able to catch this problem).

Off-topic: I would differentiate between OMV and Plex use case since OMV can really run fine and as performant as any beefy x64 box on ARM devices consuming almost nothing. Wrt transcoding I currently try to avoid this. No issues since the mediaplayers all have sufficient video engines to cope with (be it QuickSync or ARM) and before I would allow insanely inefficient transcoding on CPU cores wasting huge amounts of energy I simply wait a bit more (all the multimedia ARM SoCs have capable video engines included, I think with the most recent Rockchip SoCs we see truly hardware accelerated transcoding first)

Huberer · Oct 3rd 2017

Ok, you're right. What I meant with "fu**ing naming" was just the changing of the name. Why it wasn't possible to stay on eth0,... but under the hood a new way of identifying the network. I guess that 80% of the Linux users don't care about the naming of the ethernet as long as it's working And I'm one of these 80%.
And you're right about the difference between an upgrade and a fresh installation otherwise @ryecoaaron has just realized this issue. I read in some posts that he upgraded to OMV v4 and didn't make a fresh installation. I read somewhere too, that an further upgrade from Debian 9 to Debian 10 (after an upgrade from 8 to 9) will change the naming anyway. So at least there the developers will realize the new naming.

Thanks for the info about the ARM devices. I know that they can play everything you throw at them. I also would prefer a low power NAS with hardware transcoding and VM running with less power consumption.
But you forgot the Apple world. Some apps aren't allowed to use the internal video player like Plex or TVHeadend on an Ipad/Iphone. Therefore you need software transcoding from the server. If it's possible I try to avoid this things. Therefor I've bought an Android Tablet (from Samsung with 16:10 display) for watching movies at home on the exercise machine.
But now we're getting to much off topic (even it's getting interesting - I watch your thread for sure)

tkaiser · Oct 3rd 2017

Quote from Huberer

I guess that 80% of the Linux users don't care about the naming of the ethernet as long as it's working And I'm one of these 80%.

Well, in fact the majority just limits everything around to their own limited use cases (dealing with eth0 only). As soon as you have more than one network interface you start to understand why predictable interface names matter. Imagine you have 3 network cards in your server and replaced the Marvell in PCIe slot 2 with an Intel. Prior to 'new' Stretch behaviour most probably all your interface names would have changed, now you end up with the same interface names even if you changed the vendor (since stuff like 'slot numbers' are encoded in the interface names).

Anyway...

@ryecoaaron: I looked again in the script and I would deal with it checking 'RELEASE=$(lsb_release -cs)' (and let the regex checking $FORCE_NIC only deal with "wheezy|~~stretch~~jessie") and then replace line 1180 simply with

Code

FORCE_NIC=$(ip link | awk -F': ' '/: en|: eth|: wlan|: bond|: usb/ {print $2}')

ryecoaaron · Oct 4th 2017

Quote from tkaiser

I looked again in the script and I would deal with it checking 'RELEASE=$(lsb_release -cs)' (and let the regex checking $FORCE_NIC only deal with "wheezy|stretchjessie") and then replace line 1180 simply with

Fine with me. Tested the command a few systems but I just don't have anyway to test it in the plugin.

https://github.com/OpenMediaVa…d44451a9763077e3d689d4f92

Huberer · Oct 4th 2017

Just to give a feedback. Today I've installed the ASD again and changed the line. It looks like that everything is working well.

Thanks @tkaiser and @ryecoaaron for fixing it.

Huberer · Oct 5th 2017

@tkaiser and @ryecoaaron

there's another issue with ASD which I found out. ASD doesn't recognize the broadcast-address of the ethernet card properly. And because of that the server shuts down even IP-scanning is enabled and the client with the proper IP is on.
Here is part of the log-file:

Code

Oct  5 14:47:22 HomeServer root: autoshutdown[903]: INFO: ' Reading NICs ,IPs, ...'
Oct  5 14:47:22 HomeServer root: autoshutdown[903]: INFO: ' NIC 'enp0s25' found: try to get IP'
Oct  5 14:47:22 HomeServer root: autoshutdown[903]: INFO: ' _check_networkconfig(): Run: #1: IP-Adress found'
Oct  5 14:47:22 HomeServer root: autoshutdown[903]: INFO: ' 'enp0s25' has IP:         inet 192.168.1.200  netmask 255.255.255.0  broadcast 192.168.1.255'
Oct  5 14:47:22 HomeServer root: autoshutdown[903]: WARN: ' Invalid parameter format: Class: nnn.nnn.nnn]'
Oct  5 14:47:22 HomeServer root: autoshutdown[903]: WARN: ' It is set to 'inet 192.168.1.200 netmask 255.255.255.0 broadcast 192.168.1', which is not a correct synt$
Oct  5 14:47:22 HomeServer root: autoshutdown[903]: WARN: ' Please report this Bug and the CLI-output of 'ifconfig''
Oct  5 14:47:22 HomeServer root: autoshutdown[903]: WARN: ' unsetting NIC[1]: enp0s25 ...'
Oct  5 14:47:22 HomeServer root: autoshutdown[903]: WARN: ' Invalid parameter format: SERVERIP [iii]'
Oct  5 14:47:22 HomeServer root: autoshutdown[903]: WARN: ' It is set to '255', which is not a correct syntax. Maybe parsing 'ifconfig' did something wrong'
Oct  5 14:47:22 HomeServer root: autoshutdown[903]: WARN: ' Please report this Bug and the CLI-output of 'ifconfig''
Oct  5 14:47:22 HomeServer root: autoshutdown[903]: WARN: ' unsetting NIC[1]:  ...'
Oct  5 14:47:22 HomeServer root: autoshutdown[903]: INFO: ' /tmp/autoshutdown created'

Display More

It doesn't matter if the IP-address of the server is set to stable or dhpc. I posted this issue as well on github here.

Thanks in advance

Huberer · Oct 5th 2017

I guess I've solved this issue:

I've replace line no. 1213

Code

IPFROMIFCONFIG[$NICNR]="$(ifconfig ${NIC[$NICNR]} | egrep "inet " | sed 's/[ ]*Bcast.*//g; s/.*://g')"

with

Code

IPFROMIFCONFIG[$NICNR]="$(ifconfig ${NIC[$NICNR]} | egrep "inet " | sed -r 's/[ ]*(Bcast|netmask).*//g; s/[ ]*inet[ ](adr:)?//g')"

restarted the server and the output of the log file is:

Code

Oct  5 21:08:08 HomeServer root: autoshutdown[896]: INFO: ' Reading NICs ,IPs, ...'
Oct  5 21:08:08 HomeServer root: autoshutdown[896]: INFO: ' NIC 'enp0s25' found: try to get IP'
Oct  5 21:08:08 HomeServer root: autoshutdown[896]: INFO: ' _check_networkconfig(): Run: #1: IP-Adress found'
Oct  5 21:08:08 HomeServer root: autoshutdown[896]: INFO: ' 'enp0s25' has IP: 192.168.1.200'
Oct  5 21:08:08 HomeServer root: autoshutdown[896]: INFO: ' /tmp/autoshutdown created'

The solution for this fix I found here. Have to check if this is correct or not, but if yes, maybe someone can change the line.

Thanks in advance

Huberer · Oct 6th 2017

So, another issue was found with this plugin. It doesn't recognize the ULDL-Rate. So if you set an amount to observe ASD can't find the proper settings. Here is the part of the log-file:

Code

Oct  6 01:57:27 HomeServer root: autoshutdown[891]: INFO: ' new supervision cycle started - check active hosts or processes'
Oct  6 01:57:27 HomeServer root: autoshutdown[891]: INFO: ' retrieve list of active IPs for 'enp0s25' ...'
Oct  6 01:57:28 HomeServer root: autoshutdown[891]: INFO: ' No active IPs in the specified IP-Range found'
Oct  6 01:57:28 HomeServer root: autoshutdown[891]: INFO: ' Check Connections for 'enp0s25''
Oct  6 01:57:28 HomeServer root: autoshutdown[891]: INFO: ' ULDL-Traffic-Check for 'enp0s25''
Oct  6 01:57:28 HomeServer root: autoshutdown[891]: INFO: ' enp0s25: over the last 300 seconds: DL: inf kB/s; UL: inf kB/s'
Oct  6 01:57:28 HomeServer root: autoshutdown[891]: INFO: ' enp0s25: UL- or DL-Rate is over 50 kB/s -> no shutdown'
Oct  6 01:57:28 HomeServer root: autoshutdown[891]: INFO: ' sleep for 300s.'

During this time the server had nothing to do (no updates, no downloads, no other plugins which are updating in the back).

So, for me, this plugin is not ready for OMV v4.

I've added this issue to quite a same matter at GitHub here.

Participate now!