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

    • OMV 4.x (GIT/pre-alpha)

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

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

      Source Code

      1. Oct 2 20:28:30 HomeServer root: autoshutdown[3724]: INFO: ' Reading NICs ,IPs, ...'
      2. Oct 2 20:28:30 HomeServer root: autoshutdown[3724]: INFO: ' NIC 'bond0' not found, skipping 'bond0''
      3. Oct 2 20:28:30 HomeServer root: autoshutdown[3724]: INFO: ' NIC 'eth0' not found, skipping 'eth0''
      4. Oct 2 20:28:30 HomeServer root: autoshutdown[3724]: INFO: ' NIC 'eth1' not found, skipping 'eth1''
      5. Oct 2 20:28:30 HomeServer root: autoshutdown[3724]: WARN: ' No SERVERIP or CLASS found'
      6. Oct 2 20:28:30 HomeServer root: autoshutdown[3724]: WARN: ' exiting ...'
      7. Oct 2 20:31:03 HomeServer logger: autoshutdown[4230]: INFO: ' XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX'
      8. Oct 2 20:31:03 HomeServer autoshutdown.sh[4230]: <182>Oct 2 20:31:03 logger: autoshutdown[4230]: INFO: ' XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX'
      9. Oct 2 20:31:03 HomeServer logger: autoshutdown[4230]: INFO: ' XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX'
      10. Oct 2 20:31:03 HomeServer autoshutdown.sh[4230]: <182>Oct 2 20:31:03 logger: autoshutdown[4230]: INFO: ' XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX'
      11. Oct 2 20:31:03 HomeServer logger: autoshutdown[4230]: INFO: ' XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX'
      12. Oct 2 20:31:03 HomeServer autoshutdown.sh[4230]: <182>Oct 2 20:31:03 logger: autoshutdown[4230]: INFO: ' XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX'
      13. Oct 2 20:31:03 HomeServer logger: autoshutdown[4230]: INFO: ' X Version: 0.9.9.10'
      14. 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'
      15. Oct 2 20:31:03 HomeServer logger: autoshutdown[4230]: INFO: ' Initialize logging to local6'
      16. Oct 2 20:31:03 HomeServer autoshutdown.sh[4230]: <182>Oct 2 20:31:03 logger: autoshutdown[4230]: INFO: ' Initialize logging to local6'
      17. Oct 2 20:31:03 HomeServer root: autoshutdown[4230]: INFO: ' /etc/autoshutdown.conf loaded'
      Display All


      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:

      Brainfuck Source Code

      1. Oct 2 20:31:03 HomeServer root: autoshutdown[4230]: WARN: ' Invalid parameter format: FORCE_NIC'
      2. 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,$
      3. Oct 2 20:31:03 HomeServer root: autoshutdown[4230]: WARN: ' with spaces between every NIC: e.g. "eth1 wlan0 usb3 eth1.2"'
      4. Oct 2 20:31:03 HomeServer root: autoshutdown[4230]: WARN: ' Unsetting FORCE_NIC'
      5. Oct 2 20:31:03 HomeServer root: autoshutdown[4230]: INFO: ' ------------------------------------------------------'
      6. Oct 2 20:31:03 HomeServer root: autoshutdown[4230]: INFO: ' Reading NICs ,IPs, ...'
      7. Oct 2 20:31:03 HomeServer root: autoshutdown[4230]: INFO: ' NIC 'bond0' not found, skipping 'bond0''
      8. Oct 2 20:31:03 HomeServer root: autoshutdown[4230]: INFO: ' NIC 'eth0' not found, skipping 'eth0''
      9. Oct 2 20:31:03 HomeServer root: autoshutdown[4230]: INFO: ' NIC 'eth1' not found, skipping 'eth1''
      10. Oct 2 20:31:03 HomeServer root: autoshutdown[4230]: WARN: ' No SERVERIP or CLASS found'
      11. Oct 2 20:31:03 HomeServer root: autoshutdown[4230]: WARN: ' exiting ...'
      Display All
      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: MoBo Fujitsu D3222-B12 (Q87 chipset/Intel i217 gigabit lan controller), Intel i5-4590S, 8GB-Ram@1600MHz, 1x512GB SSD Samsung 850 Pro (sda2 - 35GB system, sda4 (rest) - for work), 4x3TB WD Red's Snapraid w/ mergerfs, DVBSky v952v3, OMV 4.0.x (always latest) with backportkernel 4.13 (always latest), omv-extras-plugin (always latests), AutoShutdown-Plugin, PlexMediaServer, Emby Server, SMB-Shares, TVHeadendServer (stable release),

      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:

      Source Code

      1. Oct 2 21:26:23 HomeServer root: autoshutdown[2993]: INFO: ' Reading NICs ,IPs, ...'
      2. Oct 2 21:26:23 HomeServer root: autoshutdown[2993]: INFO: ' NIC 'bond0' not found, skipping 'bond0''
      3. Oct 2 21:26:23 HomeServer root: autoshutdown[2993]: INFO: ' NIC 'eth0' found: try to get IP'
      4. Oct 2 21:26:23 HomeServer root: autoshutdown[2993]: INFO: ' _check_networkconfig(): Run: #1: IP-Adress found'
      5. 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'
      6. Oct 2 21:26:23 HomeServer root: autoshutdown[2993]: WARN: ' Invalid parameter format: Class: nnn.nnn.nnn]'
      7. 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$
      8. Oct 2 21:26:23 HomeServer root: autoshutdown[2993]: WARN: ' Please report this Bug and the CLI-output of 'ifconfig''
      9. Oct 2 21:26:23 HomeServer root: autoshutdown[2993]: WARN: ' unsetting NIC[2]: eth0 ...'
      10. Oct 2 21:26:23 HomeServer root: autoshutdown[2993]: WARN: ' Invalid parameter format: SERVERIP [iii]'
      11. 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'
      12. Oct 2 21:26:23 HomeServer root: autoshutdown[2993]: WARN: ' Please report this Bug and the CLI-output of 'ifconfig''
      13. Oct 2 21:26:23 HomeServer root: autoshutdown[2993]: WARN: ' unsetting NIC[2]: ...'
      14. Oct 2 21:26:23 HomeServer root: autoshutdown[2993]: INFO: ' NIC 'eth1' not found, skipping 'eth1''
      Display All


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


      Source Code

      1. The loopback network interface
      2. auto lo
      3. iface lo inet loopback
      4. # eth0 network interface
      5. auto eth0
      6. allow-hotplug eth0
      7. iface eth0 inet static
      8. address 192.168.1.200
      9. gateway 192.168.1.1
      10. netmask 255.255.255.0
      11. dns-nameservers 8.8.8.8 8.8.4.4
      12. pre-down ethtool -s $IFACE wol g
      13. iface eth0 inet6 manual
      14. pre-down ip -6 addr flush dev $IFACE
      Display All
      OMV-Server: MoBo Fujitsu D3222-B12 (Q87 chipset/Intel i217 gigabit lan controller), Intel i5-4590S, 8GB-Ram@1600MHz, 1x512GB SSD Samsung 850 Pro (sda2 - 35GB system, sda4 (rest) - for work), 4x3TB WD Red's Snapraid w/ mergerfs, DVBSky v952v3, OMV 4.0.x (always latest) with backportkernel 4.13 (always latest), omv-extras-plugin (always latests), AutoShutdown-Plugin, PlexMediaServer, Emby Server, SMB-Shares, TVHeadendServer (stable release),

      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: MoBo Fujitsu D3222-B12 (Q87 chipset/Intel i217 gigabit lan controller), Intel i5-4590S, 8GB-Ram@1600MHz, 1x512GB SSD Samsung 850 Pro (sda2 - 35GB system, sda4 (rest) - for work), 4x3TB WD Red's Snapraid w/ mergerfs, DVBSky v952v3, OMV 4.0.x (always latest) with backportkernel 4.13 (always latest), omv-extras-plugin (always latests), AutoShutdown-Plugin, PlexMediaServer, Emby Server, SMB-Shares, TVHeadendServer (stable release),

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

      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: wiki.debian.org/NetworkConfigu…e_Network_Interface_Names

      Huberer wrote:

      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?
      'OMV problems' with XU4 and Cloudshell 2? Nope, read this first. 'OMV problems' with Cloudshell 1? Nope, just Ohm's law or queue size.
    • @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: MoBo Fujitsu D3222-B12 (Q87 chipset/Intel i217 gigabit lan controller), Intel i5-4590S, 8GB-Ram@1600MHz, 1x512GB SSD Samsung 850 Pro (sda2 - 35GB system, sda4 (rest) - for work), 4x3TB WD Red's Snapraid w/ mergerfs, DVBSky v952v3, OMV 4.0.x (always latest) with backportkernel 4.13 (always latest), omv-extras-plugin (always latests), AutoShutdown-Plugin, PlexMediaServer, Emby Server, SMB-Shares, TVHeadendServer (stable release),

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

      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.
      'OMV problems' with XU4 and Cloudshell 2? Nope, read this first. 'OMV problems' with Cloudshell 1? Nope, just Ohm's law or queue size.
    • 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: MoBo Fujitsu D3222-B12 (Q87 chipset/Intel i217 gigabit lan controller), Intel i5-4590S, 8GB-Ram@1600MHz, 1x512GB SSD Samsung 850 Pro (sda2 - 35GB system, sda4 (rest) - for work), 4x3TB WD Red's Snapraid w/ mergerfs, DVBSky v952v3, OMV 4.0.x (always latest) with backportkernel 4.13 (always latest), omv-extras-plugin (always latests), AutoShutdown-Plugin, PlexMediaServer, Emby Server, SMB-Shares, TVHeadendServer (stable release),

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

      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.
      'OMV problems' with XU4 and Cloudshell 2? Nope, read this first. 'OMV problems' with Cloudshell 1? Nope, just Ohm's law or queue size.
    • $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...
      'OMV problems' with XU4 and Cloudshell 2? Nope, read this first. 'OMV problems' with Cloudshell 1? Nope, just Ohm's law or queue size.
    • tkaiser wrote:

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


      tkaiser wrote:



      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: MoBo Fujitsu D3222-B12 (Q87 chipset/Intel i217 gigabit lan controller), Intel i5-4590S, 8GB-Ram@1600MHz, 1x512GB SSD Samsung 850 Pro (sda2 - 35GB system, sda4 (rest) - for work), 4x3TB WD Red's Snapraid w/ mergerfs, DVBSky v952v3, OMV 4.0.x (always latest) with backportkernel 4.13 (always latest), omv-extras-plugin (always latests), AutoShutdown-Plugin, PlexMediaServer, Emby Server, SMB-Shares, TVHeadendServer (stable release),

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

      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)
      'OMV problems' with XU4 and Cloudshell 2? Nope, read this first. 'OMV problems' with Cloudshell 1? Nope, just Ohm's law or queue size.
    • 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: MoBo Fujitsu D3222-B12 (Q87 chipset/Intel i217 gigabit lan controller), Intel i5-4590S, 8GB-Ram@1600MHz, 1x512GB SSD Samsung 850 Pro (sda2 - 35GB system, sda4 (rest) - for work), 4x3TB WD Red's Snapraid w/ mergerfs, DVBSky v952v3, OMV 4.0.x (always latest) with backportkernel 4.13 (always latest), omv-extras-plugin (always latests), AutoShutdown-Plugin, PlexMediaServer, Emby Server, SMB-Shares, TVHeadendServer (stable release),

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

      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)
      'OMV problems' with XU4 and Cloudshell 2? Nope, read this first. 'OMV problems' with Cloudshell 1? Nope, just Ohm's law or queue size.
    • 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: MoBo Fujitsu D3222-B12 (Q87 chipset/Intel i217 gigabit lan controller), Intel i5-4590S, 8GB-Ram@1600MHz, 1x512GB SSD Samsung 850 Pro (sda2 - 35GB system, sda4 (rest) - for work), 4x3TB WD Red's Snapraid w/ mergerfs, DVBSky v952v3, OMV 4.0.x (always latest) with backportkernel 4.13 (always latest), omv-extras-plugin (always latests), AutoShutdown-Plugin, PlexMediaServer, Emby Server, SMB-Shares, TVHeadendServer (stable release),

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

      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

      Source Code

      1. FORCE_NIC=$(ip link | awk -F': ' '/: en|: eth|: wlan|: bond|: usb/ {print $2}')
      'OMV problems' with XU4 and Cloudshell 2? Nope, read this first. 'OMV problems' with Cloudshell 1? Nope, just Ohm's law or queue size.

      The post was edited 1 time, last by tkaiser ().

    • tkaiser wrote:

      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.

      github.com/OpenMediaVault-Plug…d44451a9763077e3d689d4f92
      omv 4.0.11 arrakis | 64 bit | 4.13 backports kernel | omvextrasorg 4.1.0
      omv-extras.org plugins source code and issue tracker - github.com/OpenMediaVault-Plugin-Developers

      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: MoBo Fujitsu D3222-B12 (Q87 chipset/Intel i217 gigabit lan controller), Intel i5-4590S, 8GB-Ram@1600MHz, 1x512GB SSD Samsung 850 Pro (sda2 - 35GB system, sda4 (rest) - for work), 4x3TB WD Red's Snapraid w/ mergerfs, DVBSky v952v3, OMV 4.0.x (always latest) with backportkernel 4.13 (always latest), omv-extras-plugin (always latests), AutoShutdown-Plugin, PlexMediaServer, Emby Server, SMB-Shares, TVHeadendServer (stable release),

      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:

      Source Code

      1. Oct 5 14:47:22 HomeServer root: autoshutdown[903]: INFO: ' Reading NICs ,IPs, ...'
      2. Oct 5 14:47:22 HomeServer root: autoshutdown[903]: INFO: ' NIC 'enp0s25' found: try to get IP'
      3. Oct 5 14:47:22 HomeServer root: autoshutdown[903]: INFO: ' _check_networkconfig(): Run: #1: IP-Adress found'
      4. 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'
      5. Oct 5 14:47:22 HomeServer root: autoshutdown[903]: WARN: ' Invalid parameter format: Class: nnn.nnn.nnn]'
      6. 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$
      7. Oct 5 14:47:22 HomeServer root: autoshutdown[903]: WARN: ' Please report this Bug and the CLI-output of 'ifconfig''
      8. Oct 5 14:47:22 HomeServer root: autoshutdown[903]: WARN: ' unsetting NIC[1]: enp0s25 ...'
      9. Oct 5 14:47:22 HomeServer root: autoshutdown[903]: WARN: ' Invalid parameter format: SERVERIP [iii]'
      10. 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'
      11. Oct 5 14:47:22 HomeServer root: autoshutdown[903]: WARN: ' Please report this Bug and the CLI-output of 'ifconfig''
      12. Oct 5 14:47:22 HomeServer root: autoshutdown[903]: WARN: ' unsetting NIC[1]: ...'
      13. Oct 5 14:47:22 HomeServer root: autoshutdown[903]: INFO: ' /tmp/autoshutdown created'
      Display All
      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: MoBo Fujitsu D3222-B12 (Q87 chipset/Intel i217 gigabit lan controller), Intel i5-4590S, 8GB-Ram@1600MHz, 1x512GB SSD Samsung 850 Pro (sda2 - 35GB system, sda4 (rest) - for work), 4x3TB WD Red's Snapraid w/ mergerfs, DVBSky v952v3, OMV 4.0.x (always latest) with backportkernel 4.13 (always latest), omv-extras-plugin (always latests), AutoShutdown-Plugin, PlexMediaServer, Emby Server, SMB-Shares, TVHeadendServer (stable release),

      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

      Source Code

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


      with

      Source Code

      1. 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:

      Source Code

      1. Oct 5 21:08:08 HomeServer root: autoshutdown[896]: INFO: ' Reading NICs ,IPs, ...'
      2. Oct 5 21:08:08 HomeServer root: autoshutdown[896]: INFO: ' NIC 'enp0s25' found: try to get IP'
      3. Oct 5 21:08:08 HomeServer root: autoshutdown[896]: INFO: ' _check_networkconfig(): Run: #1: IP-Adress found'
      4. Oct 5 21:08:08 HomeServer root: autoshutdown[896]: INFO: ' 'enp0s25' has IP: 192.168.1.200'
      5. 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: MoBo Fujitsu D3222-B12 (Q87 chipset/Intel i217 gigabit lan controller), Intel i5-4590S, 8GB-Ram@1600MHz, 1x512GB SSD Samsung 850 Pro (sda2 - 35GB system, sda4 (rest) - for work), 4x3TB WD Red's Snapraid w/ mergerfs, DVBSky v952v3, OMV 4.0.x (always latest) with backportkernel 4.13 (always latest), omv-extras-plugin (always latests), AutoShutdown-Plugin, PlexMediaServer, Emby Server, SMB-Shares, TVHeadendServer (stable release),

      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:

      Source Code

      1. Oct 6 01:57:27 HomeServer root: autoshutdown[891]: INFO: ' new supervision cycle started - check active hosts or processes'
      2. Oct 6 01:57:27 HomeServer root: autoshutdown[891]: INFO: ' retrieve list of active IPs for 'enp0s25' ...'
      3. Oct 6 01:57:28 HomeServer root: autoshutdown[891]: INFO: ' No active IPs in the specified IP-Range found'
      4. Oct 6 01:57:28 HomeServer root: autoshutdown[891]: INFO: ' Check Connections for 'enp0s25''
      5. Oct 6 01:57:28 HomeServer root: autoshutdown[891]: INFO: ' ULDL-Traffic-Check for 'enp0s25''
      6. Oct 6 01:57:28 HomeServer root: autoshutdown[891]: INFO: ' enp0s25: over the last 300 seconds: DL: inf kB/s; UL: inf kB/s'
      7. Oct 6 01:57:28 HomeServer root: autoshutdown[891]: INFO: ' enp0s25: UL- or DL-Rate is over 50 kB/s -> no shutdown'
      8. 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: MoBo Fujitsu D3222-B12 (Q87 chipset/Intel i217 gigabit lan controller), Intel i5-4590S, 8GB-Ram@1600MHz, 1x512GB SSD Samsung 850 Pro (sda2 - 35GB system, sda4 (rest) - for work), 4x3TB WD Red's Snapraid w/ mergerfs, DVBSky v952v3, OMV 4.0.x (always latest) with backportkernel 4.13 (always latest), omv-extras-plugin (always latests), AutoShutdown-Plugin, PlexMediaServer, Emby Server, SMB-Shares, TVHeadendServer (stable release),

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

      The post was edited 1 time, last by Huberer ().