March 4, 201412 yr I'll test with the -w option, thanks! I didn't see the new apcupsd thread until now actually. I'll try it out, thanks for the heads up.
March 4, 201412 yr dlandon 2 questions if you please :0 1. since i am using this new powerdown script i see some of my applications not auto run after a reboot... no clue why so far i noticed vfs_recycle and crashplan having the issue please note they are both installed but for some reason they are not running just clicking start makes them run 2. on one time my array didn't want to shut down and i figured it out it was my lazylibrarian plugin checking for new books did you add these rc.d start and stop lines to your script? there is a very old plugin from this app in this subforum which i adapted many times to work with the current git maintainer but the start and stop lines remained the same rc.lazylibrarian start rc.lazylibrarian stop
March 4, 201412 yr Author dlandon 2 questions if you please :0 1. since i am using this new powerdown script i see some of my applications not auto run after a reboot... no clue why so far i noticed vfs_recycle and crashplan having the issue please note they are both installed but for some reason they are not running just clicking start makes them run Powerdown shouldn't have anything to do with plugins starting. Powerdown only applies when shutting down, unless you are using the 'S' scripts to start things. Are you on V6? V6 plugins can start installing before the network is available causing some plugins problems. 2. on one time my array didn't want to shut down and i figured it out it was my lazylibrarian plugin checking for new books did you add these rc.d start and stop lines to your script? there is a very old plugin from this app in this subforum which i adapted many times to work with the current git maintainer but the start and stop lines remained the same rc.lazylibrarian start rc.lazylibrarian stop Any scripts found in the rc.d directory that aren't unRAID distributed are executed with the 'stop' parameter on shutdown. Powerdown does not start any of the rc.d scripts. Verify that the plugin is installing the rc.lazylibrarion as an executable file.
March 4, 201412 yr Nope still running 5.05 waiting for beta 4 release to start on the 6 series yeah there is a lazylibrarian rc.d file so that should be ok then ... thought there was still a ile with a list of all plugins but if it compiles this list himself then i am not worried
March 4, 201412 yr I am running running unRAID 6 beta3 with Xen using a single VM. Stock unRAID except for the powerdown script, 2.06. I used Freddie's code from reply #122: [ -f /var/run/xenstored.pid ] && xl shutdown -a sleep 20 I am planning on more VMs in the future so this fits my needs well. Added it as a shell script within /boot/config/plugins/powerdown/rc.unRaid.d VM shuts down normally. unRAID shuts down normally, no parity check on power up. I'll add a S script to start my VM back up normally later. Now just need that APC addon to work with 6 and I'll be set! Many thanks to dlandon and everyone else that has helped in testing this. I will gladly continue to help with test. Use xl shutdown -a -w and you won't need the sleep. The -w parameter waits for all VMs to be shut down. I think apcupsd for v6 has been updated. That worked much better. I watched xl list and unRAID waited as expected until it was gone from the list. I've also grabbed the 64 bit version of apcupsd and the daemon stays up now. I haven't tested unplugging the UPS yet or the startup script to power up the VM. I'll do those tomorrow as I have memory to install anyways. Appreciate the help!
March 4, 201412 yr Unfortunately, even v2.06 doesn't manage to always shut my system down cleanly. The additional debug shows that it is shfs holding the device open, which is consistent with the "2 devices still in use", indicating that the other one is a user share. I know that it must be my 'Photos' share being held open by minidlna. The code for "/etc/rc.d/rc.minidlna stop" is: minidlna_stop() { # no-op if not running if [ ! -r /var/run/minidlna/minidlna.pid ]; then return fi echo -n "Stopping minidlna..." kill $(cat /var/run/minidlna/minidlna.pid) echo "minidlna stopped" echo } Looking at the running system, the content of minidlna.pid is consistent with the active minidlna process. What I am aware of is that minidlna spawns child processes while it's running - perhaps everytime it serves data to the client(s)? I'm not sure exactly how minidlna works. The pid file always seems to contain the pid of the parent process (owned by pid 1). I still wonder whether minidlna is too slow to stop while there is a child process in existence or, rather, powerdown is too quick to proceed. I re-iterate that I've never experienced this problem with powerdown 1.02. syslog-20140304-073031.txt.zip
March 4, 201412 yr I have unMENU installed already. Don't think I'm going to install dynamix just to have this up-to-date. Will check the OP for information. Maybe Joe L should update unMenu for the new Powerdown. Yes, he should.
March 4, 201412 yr Author Unfortunately, even v2.06 doesn't manage to always shut my system down cleanly. The additional debug shows that it is shfs holding the device open, which is consistent with the "2 devices still in use", indicating that the other one is a user share. I know that it must be my 'Photos' share being held open by minidlna. The code for "/etc/rc.d/rc.minidlna stop" is: minidlna_stop() { # no-op if not running if [ ! -r /var/run/minidlna/minidlna.pid ]; then return fi echo -n "Stopping minidlna..." kill $(cat /var/run/minidlna/minidlna.pid) echo "minidlna stopped" echo } Looking at the running system, the content of minidlna.pid is consistent with the active minidlna process. What I am aware of is that minidlna spawns child processes while it's running - perhaps everytime it serves data to the client(s)? I'm not sure exactly how minidlna works. The pid file always seems to contain the pid of the parent process (owned by pid 1). I still wonder whether minidlna is too slow to stop while there is a child process in existence or, rather, powerdown is too quick to proceed. I re-iterate that I've never experienced this problem with powerdown 1.02. Delete the /boot/packages/powerdown-2.06-noarch-unRAID.tgz file and re-install powerdown. I've added logging of the rc.d scripts when starting so we can see the output of each of the stop scripts.
March 5, 201412 yr Okay, logfile attached. I'm not sure that we learn very much. minidlna is definitely being stopped, and issuing the stop from a terminal session definitely works. There is an interesting anomaly from mysql, but I guess that the child is killed when the parent is killed first. It is definitely shfs holding a file open on disk3 and, during normal running, lsof only ever shows one jpg open at a time - the one being displayed by my photoframe, served by minidlna. I think that I need to experiment with turning the photoframe off suddenly, and see what state minidlne/shfs is left in. I can only think that minidlna quits, but shfs doesn't release the file. syslog-20140305-081213.txt.zip.txt
March 5, 201412 yr Author Okay, logfile attached. I'm not sure that we learn very much. minidlna is definitely being stopped, and issuing the stop from a terminal session definitely works. There is an interesting anomaly from mysql, but I guess that the child is killed when the parent is killed first. It is definitely shfs holding a file open on disk3 and, during normal running, lsof only ever shows one jpg open at a time - the one being displayed by my photoframe, served by minidlna. I think that I need to experiment with turning the photoframe off suddenly, and see what state minidlne/shfs is left in. I can only think that minidlna quits, but shfs doesn't release the file. Log file? It's always disk3. What shares do you have only on disk3?
March 5, 201412 yr Sorry about missing logfile - I was distracted by another power cut ... have had to start the generator. disk3 has: downloaded - only used, over nfs, when I have jdownloader running (not used for several months) Karaoke - never accessed Photos - Where I store all my photos, and only regularly used by minidlna to serve my photoframe. None of these shares appear on any other disk.
March 5, 201412 yr Author Okay, logfile attached. I'm not sure that we learn very much. minidlna is definitely being stopped, and issuing the stop from a terminal session definitely works. There is an interesting anomaly from mysql, but I guess that the child is killed when the parent is killed first. It is definitely shfs holding a file open on disk3 and, during normal running, lsof only ever shows one jpg open at a time - the one being displayed by my photoframe, served by minidlna. I think that I need to experiment with turning the photoframe off suddenly, and see what state minidlne/shfs is left in. I can only think that minidlna quits, but shfs doesn't release the file. Ok. I see several things that I'd like to look into. The "rc.mpop stop" has no messages coming from the stop command. What is it and should it display some stop messages? There are two MySQL stops. "rc.mysql stop" and "rc.mysqld stop". I don't like the looks of that. The "rc.mysqld" is a daemon and maybe it should be stopped and not the "rc.mysql". Do you know the proper way to shut down MySQL? Powerdown is just walking through the rc. files and issuing stops. It may be that MySQL needs to be stopped in a certain sequence and powerdown is not doing that. If that's the case, I can show you how to handle this situation to get a clean shutdown.
March 5, 201412 yr Author Sorry about missing logfile - I was distracted by another power cut ... have had to start the generator. disk3 has: downloaded - only used, over nfs, when I have jdownloader running (not used for several months) Karaoke - never accessed Photos - Where I store all my photos, and only regularly used by minidlna to serve my photoframe. None of these shares appear on any other disk. Another idea. Create a file named K00.sh and put it in the /boot/config/plugins/powerdown/rc.unRAID.d/ directory: The contents should be: /etc/rc.d/rc.minidlna stop This script will be run by powerdown as soon as the powerdown is started and will stop minidlna early in the process. This may give it more time to complete its shutdown.
March 5, 201412 yr Okay, logfile attached. I'm not sure that we learn very much. minidlna is definitely being stopped, and issuing the stop from a terminal session definitely works. There is an interesting anomaly from mysql, but I guess that the child is killed when the parent is killed first. It is definitely shfs holding a file open on disk3 and, during normal running, lsof only ever shows one jpg open at a time - the one being displayed by my photoframe, served by minidlna. I think that I need to experiment with turning the photoframe off suddenly, and see what state minidlne/shfs is left in. I can only think that minidlna quits, but shfs doesn't release the file. Ok. I see several things that I'd like to look into. The "rc.mpop stop" has no messages coming from the stop command. What is it and should it display some stop messages? No, rc.mpop stop does not produce any message - it is simply deleting a cron job entry. There are two MySQL stops. "rc.mysql stop" and "rc.mysqld stop". I don't like the looks of that. The "rc.mysqld" is a daemon and maybe it should be stopped and not the "rc.mysql". Do you know the proper way to shut down MySQL? Powerdown is just walking through the rc. files and issuing stops. It may be that MySQL needs to be stopped in a certain sequence and powerdown is not doing that. I know nothing about the way that MySQL is set up - I'm simply using a plugin script which has been publicised on the Limetech sites. I'm not sure who created it, but the names 'Andrew Hamer-Adams' and 'pilot' appear in the revision history. However, it is neither of these which is causing my problem. md3 / disk3 is only being accessed by minidlna and, as I've already stated, powerdown v1.02 allows a clean shutdown. If that's the case, I can show you how to handle this situation to get a clean shutdown. I think that you're being distracted by oddities which are not the cause of my unclean shutdowns.
March 5, 201412 yr Another idea. Create a file named K00.sh and put it in the /boot/config/plugins/powerdown/rc.unRAID.d/ directory: The contents should be: /etc/rc.d/rc.minidlna stop This script will be run by powerdown as soon as the powerdown is started and will stop minidlna early in the process. This may give it more time to complete its shutdown. I think that it might be more useful to prove, first of all, whether minidlna is, indeed, failing to stop. A ps -eaf | grep mindlna just before the dismounts should do the trick. Edit: Sorry, harking back to my DEC days there ... of course I should have said 'umounts' rather than 'dismounts'!
March 5, 201412 yr I am running running unRAID 6 beta3 with Xen using a single VM. Stock unRAID except for the powerdown script, 2.06. I used Freddie's code from reply #122: [ -f /var/run/xenstored.pid ] && xl shutdown -a sleep 20 I am planning on more VMs in the future so this fits my needs well. Added it as a shell script within /boot/config/plugins/powerdown/rc.unRaid.d VM shuts down normally. unRAID shuts down normally, no parity check on power up. I'll add a S script to start my VM back up normally later. Now just need that APC addon to work with 6 and I'll be set! Many thanks to dlandon and everyone else that has helped in testing this. I will gladly continue to help with test. Use xl shutdown -a -w and you won't need the sleep. The -w parameter waits for all VMs to be shut down. I think apcupsd for v6 has been updated. Just tested this change after installing the new memory. Unplugged the UPS and was already under 10 minutes remaining. Watch xl list and the VM shut down and then unRAID went down cleaning. Power back up and everything is working. Thanks for the help and development time to get this to work with VMs.
March 8, 201412 yr Another idea. Create a file named K00.sh and put it in the /boot/config/plugins/powerdown/rc.unRAID.d/ directory: The contents should be: /etc/rc.d/rc.minidlna stop This script will be run by powerdown as soon as the powerdown is started and will stop minidlna early in the process. This may give it more time to complete its shutdown. I think that it might be more useful to prove, first of all, whether minidlna is, indeed, failing to stop. A ps -eaf | grep mindlna just before the dismounts should do the trick. Okay, we had (still have, but I've started the generator) a power cut this evening, and my ps shows that the minidlna process really is still active, despite the earlier message which says "minidlna stopped". I suspect that what is happening is that when the photoframe suffers the power cut, minidlna is in the middle of serving a photo. Now, either this causes minidlna to get into a flap and ignore the 'stop' or, more likely, it is waiting to time out the uncompleted transaction. Why did I not suffer this problem previously? Possible reasons are: 1) minidlna 1.1.0 is behaving differently in this circumstance to how v1.0.25 behaved. (Incidentally, I received notification yesterday, that minidlna 1.1.2 is available). 2) powerdown v1.02 was more aggressive than 2.x in forcing dismounts 3) powerdown v1.02 killed active processes which refused to die (but I don't believe that 1.02 ever did anything to stop processes). 4) powerdown v1.02, while producing the additional logging diagnostics, allowed a minidlna timeout to expire
March 8, 201412 yr Author Why did I not suffer this problem previously? Possible reasons are: 1) minidlna 1.1.0 is behaving differently in this circumstance to how v1.0.25 behaved. (Incidentally, I received notification yesterday, that minidlna 1.1.2 is available). Don't know. 2) powerdown v1.02 was more aggressive than 2.x in forcing dismounts Yes. Too aggressive. 3) powerdown v1.02 killed active processes which refused to die (but I don't believe that 1.02 ever did anything to stop processes). Yes. 1.02 did in fact force processes to stop. Was too forceful and caused other problems. The end result here is that plugins should be shutdown properly and not rely on powerdown to "force" them to shutdown. We walk through the /etc/rc.d/ scripts and issue the 'stop' command to stop all plugins and added the script mechanism to help in other cases like when using VMs. 4) powerdown v1.02, while producing the additional logging diagnostics, allowed a minidlna timeout to expire Maybe. I think minidlna needs more time to shut itself down than we give it. That's why I recommended stopping it earlier in the powerdown sequence with the S00.sh script. You may even have to add a sleep to give it enough time. The author of the minidlna plugin should really review the stop script in /etc/rc.d/rc.minidlna and not return from the script until minidlna is completely stopped assuring that powerdown can unmount the drives. As a side note, it appears from your log you are using the Logitech Media Server. It is a DLNA server. Why don't you use it to serve your photos instead of installing minidlna?
March 8, 201412 yr 2) powerdown v1.02 was more aggressive than 2.x in forcing dismounts Yes. Too aggressive. 3) powerdown v1.02 killed active processes which refused to die (but I don't believe that 1.02 ever did anything to stop processes). Yes. 1.02 did in fact force processes to stop. Was too forceful and caused other problems. The end result here is that plugins should be shutdown properly and not rely on powerdown to "force" them to shutdown. We walk through the /etc/rc.d/ scripts and issue the 'stop' command to stop all plugins and added the script mechanism to help in other cases like when using VMs. 4) powerdown v1.02, while producing the additional logging diagnostics, allowed a minidlna timeout to expire Maybe. I think minidlna needs more time to shut itself down than we give it. That's why I recommended stopping it earlier in the powerdown sequence with the S00.sh script. You may even have to add a sleep to give it enough time. In normal circumstances, rc.minidlna stop works quickly - by the time I can type a ps command, the process has already terminated. This is why I suspect that the failure to stop is due to the photoframe going awol when the power cuts out. As I say, I need to perform further testing on this. The author of the minidlna plugin should really review the stop script in /etc/rc.d/rc.minidlna and not return from the script until minidlna is completely stopped assuring that powerdown can unmount the drives. The plugin is my own work. Obviously, I can test that the process has, indeed, terminated. However, if this results in an interminable hang, then we're no better off. Perhaps retry for a few seconds, then do a kill -9, before returning. You say that powerdown 1.02 was too aggressive or forceful, but perhaps this is what is needed. Isn't it better for the array to shutdown cleanly at the expense of a recalcitrant process? As a side note, it appears from your log you are using the Logitech Media Server. It is a DLNA server. Why don't you use it to serve your photos instead of installing minidlna? Good question! When I first started with SlimServer, it didn't have dlna functionality. When dlna was added (to SBS?), it had some problems in the early days, therefore I never really grew accustomed to using the dlna functionality. I did try two other dlna servers before settling on minidlna - it was the first one which functioned correctly with my photoframe.
March 13, 201412 yr Maybe. I think minidlna needs more time to shut itself down than we give it. That's why I recommended stopping it earlier in the powerdown sequence with the S00.sh script. You may even have to add a sleep to give it enough time. In normal circumstances, rc.minidlna stop works quickly - by the time I can type a ps command, the process has already terminated. This is why I suspect that the failure to stop is due to the photoframe going awol when the power cuts out. As I say, I need to perform further testing on this. The author of the minidlna plugin should really review the stop script in /etc/rc.d/rc.minidlna and not return from the script until minidlna is completely stopped assuring that powerdown can unmount the drives. The plugin is my own work. Obviously, I can test that the process has, indeed, terminated. However, if this results in an interminable hang, then we're no better off. Perhaps retry for a few seconds, then do a kill -9, before returning. Okay. I have been adding debug messages into rc.minidlna and I think that I now have a handle on what is happening. First of all, I should say that minidlna appears to have no proper 'stop' command. Even the official distribution uses the kill command in rc.minidlna, so I have done the same in my plugin version. What appears to happen is that if the kill happens while a child process is hung (because the client went awol when the power cut occurred) then the parent process does, indeed, die. When that happens, the pid file is correctly deleted. However, the child process is left active and its parent pid is changed to '1'. Of course, the child process has no associated pid file. I think that my next step is to try using the killall command, using process name instead of pid.
March 15, 201412 yr What appears to happen is that if the kill happens while a child process is hung (because the client went awol when the power cut occurred) then the parent process does, indeed, die. When that happens, the pid file is correctly deleted. However, the child process is left active and its parent pid is changed to '1'. Of course, the child process has no associated pid file. I think that my next step is to try using the killall command, using process name instead of pid. That seems to have cracked it - I caught the following evidence in the syslog on the third power cut of the day: The power went off at 17:29:43. Powerdown initiated at 17:34:50 rc.minidlna stop invoked at 17:35:20 at this time two minidlna processes were active (the parent, started at 10:36 and the child, started at 17:29 - the minute the power failed) The first killall removed the parent, whereupon the child process changed owner pid to 1 Five seconds later, the child was still active and was then killed by a killall -9 I'm sure that this is the circumstance which would previously have led to an unclean powerdown. I'm now wondering whether it would be better to maintain the killall, 5 second pause, killall -9 sequence, or whether I should just do a killall -9 straight away.
March 15, 201412 yr I'm now wondering whether it would be better to maintain the killall, 5 second pause, killall -9 sequence, or whether I should just do a killall -9 straight away. The best way is to do a standard kill to terminate the process. This gives the process time to clean up. 5 seconds may not be enough. I don't know for sure. kill -9 is a last resort. it is untrappable and the process cannot clean up anything it may need to. flush buffers, remove tmpfiles, database close, etc, etc. the recommended procedure is. killall pause killall -9
March 15, 201412 yr I'm now wondering whether it would be better to maintain the killall, 5 second pause, killall -9 sequence, or whether I should just do a killall -9 straight away. The best way is to do a standard kill to terminate the process. This gives the process time to clean up. 5 seconds may not be enough. I don't know for sure. kill -9 is a last resort. it is untrappable and the process cannot clean up anything it may need to. flush buffers, remove tmpfiles, database close, etc, etc. the recommended procedure is. killall pause killall -9 Thanks for the advice ... that was my thinking. I could just tidy up, remove the debugging, and leave the functionality as is. From my observations during this exercise, I have concluded that 5 seconds is long enough for the parent to exit. I think that the child won't respond to a trappable kill but I could just try with, say, a 20 second delay, temporarily.
March 15, 201412 yr think that the child won't respond to a trappable kill but I could just try with, say, a 20 second delay, temporarily. That doesn't sound normal. Maybe use an explicit kill -TERM I would suggest doing this by hand first. Type in the kill command line, see how long it takes for the child to terminate. here's an interesting article to read. http://stackoverflow.com/questions/690415/in-what-order-should-i-send-signals-to-gracefully-shutdown-processes
March 16, 201412 yr think that the child won't respond to a trappable kill but I could just try with, say, a 20 second delay, temporarily. That doesn't sound normal. Maybe use an explicit kill -TERM ... which should be the default action. But, yes, I agree that it would be better to always give the signal name explicitly in scripts. I would suggest doing this by hand first. Type in the kill command line, see how long it takes for the child to terminate. I guess that I need to deliberately pull the power from my digital photoframe in order to try provoking the circumstances. here's an interesting article to read. http://stackoverflow.com/questions/690415/in-what-order-should-i-send-signals-to-gracefully-shutdown-processes Yes, definitely an interesting conversation, some of which I cannot totally agree with: Don't send SIGKILL. Ever. There are, clearly, circumstances where SIGKILL is a necessary evil. For instance, when dealing with my minidlna problem, KILLing a wayward process is necessary for the "greater good". Allowing the overall system to shutdown gracefully during a power cut justifies being harsh with one child process - one simply cannot afford to wait a long time for the one process to 'cleanup'. I also found this article. Most of the signals have very specific purpose, and not always to terminate a process. What it boils down to is that SIGTERM and SIGKILL are the only real options, with SIGINT and SIGQUIT being similar in action (but with specific intent) to SIGTERM. The pkill and xkill commands are new to me - xkill being very useful when working in a desktop/gui. It also occurs to me that the 'kill' command is an inappropriate name - perhaps it would be better named as 'signal'. Even the default action is not to kill, but to terminate! Anyway, in the end, it boils down to using SIGTERM followed, after a short delay, by SIGKILL is the appropriate way to deal with minidlna during a powercut. Edit: I extended the delay to 20 seconds and the stalled child process still doesn't quit on SIGTERM. I am not prepared to delay the shutdown process for any longer than this during a powercut. I have returned to a 5 second delay, removed the debugging and will leave it at that. I have not seen any ill-effects of using SIGKILL.
Archived
This topic is now archived and is closed to further replies.