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

  • 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:



    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:


    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

    OMV-Server-HW: MoBo Fujitsu D3417-B2 (Intel-LAN), Intel Xeon E3-1245 v6 Kaby Lake (4x3.70GHz), 16GB-Ram ECC UDIMM, 1x512GB SSD Samsung 850 Pro (sda2 - 30GB system, 4GB swap, sda5/rest - for work), 1x 10TB WD Red Pro, 1x 3TB WD Red (both basic setup) - Digibit R1 Sat-IP-Server with SatIP-Axe-Firmware


    OMV-Server-SW: Debian Buster with Proxmox kernel (always up-to-date), OMV v5 (always latest), omv-extras-plugin (always latests), AutoShutdown-Plugin, Docker with PlexMediaServer, TVHeadend, any many more


    BackupServer: Synology DS1010+ with 4GB Ram, 9TB@SHR (different hdd's), DSM 5.2-5967-2

  • 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:



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



    OMV-Server-HW: MoBo Fujitsu D3417-B2 (Intel-LAN), Intel Xeon E3-1245 v6 Kaby Lake (4x3.70GHz), 16GB-Ram ECC UDIMM, 1x512GB SSD Samsung 850 Pro (sda2 - 30GB system, 4GB swap, sda5/rest - for work), 1x 10TB WD Red Pro, 1x 3TB WD Red (both basic setup) - Digibit R1 Sat-IP-Server with SatIP-Axe-Firmware


    OMV-Server-SW: Debian Buster with Proxmox kernel (always up-to-date), OMV v5 (always latest), omv-extras-plugin (always latests), AutoShutdown-Plugin, Docker with PlexMediaServer, TVHeadend, any many more


    BackupServer: Synology DS1010+ with 4GB Ram, 9TB@SHR (different hdd's), DSM 5.2-5967-2

  • 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"

    OMV-Server-HW: MoBo Fujitsu D3417-B2 (Intel-LAN), Intel Xeon E3-1245 v6 Kaby Lake (4x3.70GHz), 16GB-Ram ECC UDIMM, 1x512GB SSD Samsung 850 Pro (sda2 - 30GB system, 4GB swap, sda5/rest - for work), 1x 10TB WD Red Pro, 1x 3TB WD Red (both basic setup) - Digibit R1 Sat-IP-Server with SatIP-Axe-Firmware


    OMV-Server-SW: Debian Buster with Proxmox kernel (always up-to-date), OMV v5 (always latest), omv-extras-plugin (always latests), AutoShutdown-Plugin, Docker with PlexMediaServer, TVHeadend, any many more


    BackupServer: Synology DS1010+ with 4GB Ram, 9TB@SHR (different hdd's), DSM 5.2-5967-2

  • 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


    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?

  • @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.

    OMV-Server-HW: MoBo Fujitsu D3417-B2 (Intel-LAN), Intel Xeon E3-1245 v6 Kaby Lake (4x3.70GHz), 16GB-Ram ECC UDIMM, 1x512GB SSD Samsung 850 Pro (sda2 - 30GB system, 4GB swap, sda5/rest - for work), 1x 10TB WD Red Pro, 1x 3TB WD Red (both basic setup) - Digibit R1 Sat-IP-Server with SatIP-Axe-Firmware


    OMV-Server-SW: Debian Buster with Proxmox kernel (always up-to-date), OMV v5 (always latest), omv-extras-plugin (always latests), AutoShutdown-Plugin, Docker with PlexMediaServer, TVHeadend, any many more


    BackupServer: Synology DS1010+ with 4GB Ram, 9TB@SHR (different hdd's), DSM 5.2-5967-2

  • 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.

  • 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

    OMV-Server-HW: MoBo Fujitsu D3417-B2 (Intel-LAN), Intel Xeon E3-1245 v6 Kaby Lake (4x3.70GHz), 16GB-Ram ECC UDIMM, 1x512GB SSD Samsung 850 Pro (sda2 - 30GB system, 4GB swap, sda5/rest - for work), 1x 10TB WD Red Pro, 1x 3TB WD Red (both basic setup) - Digibit R1 Sat-IP-Server with SatIP-Axe-Firmware


    OMV-Server-SW: Debian Buster with Proxmox kernel (always up-to-date), OMV v5 (always latest), omv-extras-plugin (always latests), AutoShutdown-Plugin, Docker with PlexMediaServer, TVHeadend, any many more


    BackupServer: Synology DS1010+ with 4GB Ram, 9TB@SHR (different hdd's), DSM 5.2-5967-2

  • 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.

  • $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).



    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.

    OMV-Server-HW: MoBo Fujitsu D3417-B2 (Intel-LAN), Intel Xeon E3-1245 v6 Kaby Lake (4x3.70GHz), 16GB-Ram ECC UDIMM, 1x512GB SSD Samsung 850 Pro (sda2 - 30GB system, 4GB swap, sda5/rest - for work), 1x 10TB WD Red Pro, 1x 3TB WD Red (both basic setup) - Digibit R1 Sat-IP-Server with SatIP-Axe-Firmware


    OMV-Server-SW: Debian Buster with Proxmox kernel (always up-to-date), OMV v5 (always latest), omv-extras-plugin (always latests), AutoShutdown-Plugin, Docker with PlexMediaServer, TVHeadend, any many more


    BackupServer: Synology DS1010+ with 4GB Ram, 9TB@SHR (different hdd's), DSM 5.2-5967-2

  • 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)

  • 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.

    OMV-Server-HW: MoBo Fujitsu D3417-B2 (Intel-LAN), Intel Xeon E3-1245 v6 Kaby Lake (4x3.70GHz), 16GB-Ram ECC UDIMM, 1x512GB SSD Samsung 850 Pro (sda2 - 30GB system, 4GB swap, sda5/rest - for work), 1x 10TB WD Red Pro, 1x 3TB WD Red (both basic setup) - Digibit R1 Sat-IP-Server with SatIP-Axe-Firmware


    OMV-Server-SW: Debian Buster with Proxmox kernel (always up-to-date), OMV v5 (always latest), omv-extras-plugin (always latests), AutoShutdown-Plugin, Docker with PlexMediaServer, TVHeadend, any many more


    BackupServer: Synology DS1010+ with 4GB Ram, 9TB@SHR (different hdd's), DSM 5.2-5967-2

  • 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)

  • 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)

    OMV-Server-HW: MoBo Fujitsu D3417-B2 (Intel-LAN), Intel Xeon E3-1245 v6 Kaby Lake (4x3.70GHz), 16GB-Ram ECC UDIMM, 1x512GB SSD Samsung 850 Pro (sda2 - 30GB system, 4GB swap, sda5/rest - for work), 1x 10TB WD Red Pro, 1x 3TB WD Red (both basic setup) - Digibit R1 Sat-IP-Server with SatIP-Axe-Firmware


    OMV-Server-SW: Debian Buster with Proxmox kernel (always up-to-date), OMV v5 (always latest), omv-extras-plugin (always latests), AutoShutdown-Plugin, Docker with PlexMediaServer, TVHeadend, any many more


    BackupServer: Synology DS1010+ with 4GB Ram, 9TB@SHR (different hdd's), DSM 5.2-5967-2

  • 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|stretchjessie") and then replace line 1180 simply with

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

    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

    omv 7.0.4-2 sandworm | 64 bit | 6.5 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.10 | compose 7.1.2 | k8s 7.0-6 | cputemp 7.0 | mergerfs 7.0.3


    omv-extras.org plugins source code and issue tracker - github


    Please try ctrl-shift-R and read this before posting a question.

    Please put your OMV system details in your signature.
    Please don't PM for support... Too many PMs!

  • 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.

    OMV-Server-HW: MoBo Fujitsu D3417-B2 (Intel-LAN), Intel Xeon E3-1245 v6 Kaby Lake (4x3.70GHz), 16GB-Ram ECC UDIMM, 1x512GB SSD Samsung 850 Pro (sda2 - 30GB system, 4GB swap, sda5/rest - for work), 1x 10TB WD Red Pro, 1x 3TB WD Red (both basic setup) - Digibit R1 Sat-IP-Server with SatIP-Axe-Firmware


    OMV-Server-SW: Debian Buster with Proxmox kernel (always up-to-date), OMV v5 (always latest), omv-extras-plugin (always latests), AutoShutdown-Plugin, Docker with PlexMediaServer, TVHeadend, any many more


    BackupServer: Synology DS1010+ with 4GB Ram, 9TB@SHR (different hdd's), DSM 5.2-5967-2

  • @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:


    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

    OMV-Server-HW: MoBo Fujitsu D3417-B2 (Intel-LAN), Intel Xeon E3-1245 v6 Kaby Lake (4x3.70GHz), 16GB-Ram ECC UDIMM, 1x512GB SSD Samsung 850 Pro (sda2 - 30GB system, 4GB swap, sda5/rest - for work), 1x 10TB WD Red Pro, 1x 3TB WD Red (both basic setup) - Digibit R1 Sat-IP-Server with SatIP-Axe-Firmware


    OMV-Server-SW: Debian Buster with Proxmox kernel (always up-to-date), OMV v5 (always latest), omv-extras-plugin (always latests), AutoShutdown-Plugin, Docker with PlexMediaServer, TVHeadend, any many more


    BackupServer: Synology DS1010+ with 4GB Ram, 9TB@SHR (different hdd's), DSM 5.2-5967-2

  • 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

    OMV-Server-HW: MoBo Fujitsu D3417-B2 (Intel-LAN), Intel Xeon E3-1245 v6 Kaby Lake (4x3.70GHz), 16GB-Ram ECC UDIMM, 1x512GB SSD Samsung 850 Pro (sda2 - 30GB system, 4GB swap, sda5/rest - for work), 1x 10TB WD Red Pro, 1x 3TB WD Red (both basic setup) - Digibit R1 Sat-IP-Server with SatIP-Axe-Firmware


    OMV-Server-SW: Debian Buster with Proxmox kernel (always up-to-date), OMV v5 (always latest), omv-extras-plugin (always latests), AutoShutdown-Plugin, Docker with PlexMediaServer, TVHeadend, any many more


    BackupServer: Synology DS1010+ with 4GB Ram, 9TB@SHR (different hdd's), DSM 5.2-5967-2

  • 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.

    OMV-Server-HW: MoBo Fujitsu D3417-B2 (Intel-LAN), Intel Xeon E3-1245 v6 Kaby Lake (4x3.70GHz), 16GB-Ram ECC UDIMM, 1x512GB SSD Samsung 850 Pro (sda2 - 30GB system, 4GB swap, sda5/rest - for work), 1x 10TB WD Red Pro, 1x 3TB WD Red (both basic setup) - Digibit R1 Sat-IP-Server with SatIP-Axe-Firmware


    OMV-Server-SW: Debian Buster with Proxmox kernel (always up-to-date), OMV v5 (always latest), omv-extras-plugin (always latests), AutoShutdown-Plugin, Docker with PlexMediaServer, TVHeadend, any many more


    BackupServer: Synology DS1010+ with 4GB Ram, 9TB@SHR (different hdd's), DSM 5.2-5967-2

    Einmal editiert, zuletzt von Huberer ()

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!