Posts by nrand

    hi this is a bug in the way the iostat is used and calculated as it has changed in Debian 11. If you what to test the fix locally change line 965 to the line below.


    Code
    965 awk 'NR>3 && !/^$/{print $1 " " $6 " " $7}')


    As to the script exiting before 6 cycle, it aborted due to an error. The shutdown on error is undesirable and I will also fix this. this will be in 6.03 when released.

    I started porting Autoshutdown to OMV6 and I have hit issues/questions:


    1. Is it possible to use a custom icon in workbench/navigation.d/service.XXX.yaml file. The reason for asking for this is I cannot find a suitable mdi icon. I do have the original SVN autoshutdown icon and I would like to use this if possible but I need the details of how to get this to work. i.e. were to place the files and what to place in the 'icon:' yaml value.


    2. In the web interface when setting up a new form in workbench/component.d I have found that 'type: numberInput' current allows input of both floating point and integer which I need to restrict to integer. I have found that where port are used a custom validator 'patternType: Port' is used to validate the port is of the correct type. Is it possible to add a custom 'integer' validator or something similar so that a user cannot use a float in the GUI. (This used to be achieved by setting 'allowDecimals: false')


    3. I think there is a bug/missing functionality. If you look at 'https://github.com/openmediavault/openmediavault/blob/master/deb/openmediavault-forkeddaapd/usr/share/openmediavault/workbench/component.d/omv-services-daapd-form-page.yaml#L56' there is a modifier of 'type: readonly', However this does not work and is not available from 'https://github.com/openmediavault/openmediavault/blob/master/deb/openmediavault/workbench/src/app/core/components/intuition/models/form-field-config.type.ts#L287' I check the daapd plugin where this is used and it does not seem to work. It this a bug/missing or is there an alternative?

    @vcdwelt you description of how this work is incorrect:


    IP Range: Is just a simple ping check to check if a host is online. It does not require a port to work.

    Sockets: This check for connection to the OMV server via ports i.e. is the web OMV GUI open on a system (port 80 or 443) it does not require an IP but will state the client address that is connected.


    I tested the script and I think the IP Range check is functional, however there are a a few think to check. Dose the host expect a ping (ICMP packets) respond to them or could this have been disabled? As this is a requirement to get the IP Range to work. Secondly is the scrip running the ping test correctly, you need to check the autoshutdown logs, check both the config was expected (at the start of a script run) and check the output of the IP Range check (its the first check run so it should be easy to see).


    If you cannot see anything up post a verbose log (you need to turn this on in the GUI) and send your config. Note: I need just a fragment of the log with the config section and a couple of run of the ip range check. and i see if i can reproduce the problem.

    From the log you sent it looks as if the script is working correctly, here what it telling me:


    Code
    Sep 27 23:19:07 PT-NAS autoshutdown[16660]: root: DEBUG: '_check_net_status(): Port 22: Found active connections:'
    Sep 27 23:19:07 PT-NAS autoshutdown[16660]: root: DEBUG: '_check_net_status(): tcp ESTAB 0 0 192.168.1.165:22 192.168.1.135:33786'
    Sep 27 23:19:07 PT-NAS autoshutdown[16660]: root: INFO: '_check_net_status(): Found 1 active connection(s) on port 22 (SSH) from: 192.168.1.135'
    Sep 27 23:19:07 PT-NAS autoshutdown[16660]: root: DEBUG: '_check_net_status(): Port 80: Found active connections:'
    Sep 27 23:19:07 PT-NAS autoshutdown[16660]: root: DEBUG: '_check_net_status(): tcp ESTAB 0 0 [::ffff:192.168.1.165]:80 [::ffff:192.168.1.135]:50684'
    Sep 27 23:19:07 PT-NAS autoshutdown[16660]: root: INFO: '_check_net_status(): Found 1 active connection(s) on port 80 (HTTP) from: 192.168.1.135'

    You were ssh (port 22) into the OMV from 192.168.1.135 and had the OMV GUI open form the same IP using port 80. As there were active connection on the ports and you had them in you config:


    Code
    NSOCKETNUMBERS="21,22,80,3689,6991,9091,49152"


    The system did not shutdown as you configured. When you disconnected from ssh and the OMV GUI the system closed down as expected. So I think we are good. I set-up the patches as soon as I can and get them released. Thanks for the help debugging the script.

    ok so that an improvement. to know what going on in the post stuff i need a little more info. (this is why the script has a debug/verbose mode) turn on debug in the script and it should give the raw port info it found to determine there was activity. if you post the section with debug on i can tell you what it thinks is going on or if you found another bug ;)

    I still cannot re-create your issue even with localisation changes. However this has lead me to finding postfix issue with some of the regex expressions that can cause issues. So can you test the below?


    Here how to do it, this will require you to do this all in a shell.


    Code
    $ wget https://raw.githubusercontent.com/nrandon/openmediavault-autoshutdown/test/usr/sbin/autoshutdown
    $ chmod +x autoshutdown
    $ sudo cp autoshutdown /usr/sbin/autoshutdown


    To test first run the scripts directly directly:


    Code
    $ sudo /usr/sbin/autoshutdown


    Hopefully this will work. If is does not run add the "#!/bin/bash -x" and send the output close to were it stopped as you have done before and I try to see if i can see what up. If it work then use the OMV GUI and start the service as you have before and i submit a patch with a set of fixes.

    hi, this is not all that useful as it the salt output not the service output, but I am not entirely surprised this is not working as I am missing something on your system. The script should have worked as the original failure would kill the script on all systems and we not seeing this. However, this does not mean there is no issue.


    So I going to need a few more bit of info form you, it also possible the script edit you did has an issue.:


    1. Can I have the output form the failed service. this can be obtained from 'sudo journalctl -u autoshutdown.service' this should contain were the script is now failing.


    2. Can I have the output of: 'cat /etc/default/locale' I will mimic your localisation just to see if that the issue.


    3. Less useful but I just what to check: 'bash --version'


    1. Is the most important as i need to know why the script is now falling.

    hmm, this work for me just find however, I really don't like the current _log function. cany you try replacing the current _log function with the following (again you have to edit the /usr/sbin/autoshitdown script by hand:


    Hopefully this will work for you without issues but let see. let me know how you get on.

    Hi, yet this is a bit odd, can I have a copy of your /etc/autoshutdown.conf. Also can you modify the script that is running /usr/sbin/autoshutdown and change line 1 to "#!/bin/bash -x" (you will need to be root to do this) this will show what the script is doing just prior the problem.

    If you had to change two line I have a different solution, which is more compatible with older scripts it turns out.


    Remove the previous fixes and change the following in /usr/sbin/autoshutdown, line 1151.


    Code
    From: '$1 ~ regex && !/SLAVE/ {print $1}')
    To: '$1 ~ regex && !/SLAVE/{sub(/@.*/,"",$1); print $1}')

    The script the will now dropped the '@<interface_name>' from the network interface identification throughout the script. For example: 'eth0.42@eth0' would know as 'eth0.42'. This is similar to what it used to do I think. Can you give it a try and double check it form me. If this is good I will get the release out with the fix.


    Thanks again for doing this for me

    Hi systemd would have triggered the restart and the script was trying to check if the interface will get assigned (it has a 60 second timeout). What you are seeing in new behaviour as of v5.1.11. The new behaviour is to fix the restart from suspend and hibernate when using DHCP (and is similar to that of the 4.X version of the script). You can optimise this behaviour using the FORCE_NIC setting (see /etc/autoshutdown.default for more details).


    So I am assuming the script started up and ran autoshutdown (even if a bit slower to start)? Can you confirm it is now working, then i add the fix the a new release. Thanks you for checking this for me

    Hi sorry did not see this till now. I think this is easily fixed please do the following:


    Change the following in /usr/sbin/autoshutdown, line 1126.


    Code
    From: local state; state="$(< "/sys/class/net/${net_iface}/operstate")"
    To: local state; state="$(< "/sys/class/net/${net_iface%@*}/operstate")"

    Please let me now if this work for you and if it does I will place the fix in the 5.1.12 release.


    if it does not work I need a bit more info to fix it (hopefully this will not be required). let me know how you get on :)

    Ok here a fix you can apply to 5.1.11 (released today) until the fix is release and it give it a bit of testing.


    Change the following in /usr/sbin/autoshutdown, line 83


    Code
    From: local -r server_ips="${3// /\\|}"
    To: local -r server_ips="^\(${3// /\\|}\)$"


    This should fix it for you. can you confirm if it worked for you or not.