How to add stuff to the powerdown script

[MortenSchmidt]

Hi,

 

I installed Sabnzbd which stops the powerdown script from shutting down the server. I found here in the forums an easy way to kill it - KILLALL PYTHON.

 

If I open a console and type powerdown, then killall python, the server goes down as it should.

 

So, I tried to append the killall command to the script after the package is installed in the go script. Looks like this now:

 

CTRLALTDEL=YES LOGSAVE=30 installpkg /boot/powerdown/powerdown-1.02-noarch-unRAID.tgz
echo >>/sbin/powerdown killall python

 

But that doesn't work. I still need type killall python. I confirmed the line does indeed get appended there. Any ideas how to accomplish this ?

[Joe L.]

The following sed (stream-editor) command will edit the powerdown script to add/append the killall python command just after the command to stop the nfs daemon in the section of the script used to stop the array.

 

Put this in your go script after the installpkg line for the powerdown command

 

sed -i  "/rc.nfsd  stop/a killall python" /etc/rc.d/rc.unRAID

 

Note: there are two spaces between "rc.nfsd" and "stop/a"  It is probably easiest to cut-and-paste the command to get it corrrect.

 

It will then look like this in the go file:

CTRLALTDEL=YES LOGSAVE=30 installpkg /boot/powerdown/powerdown-1.02-noarch-unRAID.tgz

sed -i  "/rc.nfsd  stop/a killall python" /etc/rc.d/rc.unRAID

After you reboot you can check to see if it was installed by typing

grep python /etc/rc.d/rc.unRAID

It should return the line "killall python" you added.

 

Joe L.

[purko]

Will this do the same?

echo killall python >>/etc/rc.d/rc.local_shutdown

[Joe L.]

Will this do the same?

echo killall python >>/etc/rc.d/rc.local_shutdown

I don't think so.  I only see references to that file in the "start" section of the rc.unRAID script (to append the rc.unRAID stop command to the local_shutdown file.)

 

If the user is specifically invoking /sbin/powerdown, then as far as I can see, rc.local_shutdown is not involved.

[purko]

Wouldn't it be nice if the powerdown script had a line like this?

/boot/custom/etc/rc.d/rc.* stop

That way any custom packages could be given the chance to stop themselves 'nicely' before the mass killing begins.

 

[WeeboTech]

Wouldn't it be nice if the powerdown script had a line like this?

/boot/custom/etc/rc.d/rc.* stop

That way any custom packages could be given the chance to stop themselves 'nicely' before the mass killing begins.

 

I was thinking the same thing.

I can change it to do a directory sweep of a specific directory.

I would not do it on that directory because there may be scripts that are not geared to handle the stop, so it may end up starting things.

 

This is why I halted any further changes until I see where 5.0 brings us.

in the meantime, I've considered sweeping /boot/custom/etc/rc.d/powerdown.d and running every script there.

 

I may also add an inetd functionality to allow a sort of sol (shutdown on lan) command.

 

I broke my hand so this may have to wait a while until I can type at normal speed without errors and pain.

[purko]

Wouldn't it be nice if the powerdown script had a line like this?

/boot/custom/etc/rc.d/rc.* stop

That way any custom packages could be given the chance to stop themselves 'nicely' before the mass killing begins.

 

I was thinking the same thing.

I can change it to do a directory sweep of a specific directory.

I would not do it on that directory because there may be scripts that are not geared to handle the stop, so it may end up starting things.

No off-the-shelf Slackware package would go puting stuff in a directory like /boot/custom/etc/rc.d/

That makes it a good place for custom-made unRAID add-ons, to put their start/stop scripts there, if they so chose.

Any such script should be able to handle at least 'start' and 'stop' parameters. If they can't, they shouldn't be there, and it's not your problem.

As an example, the answer to the question of the starter of this thread would have simply been:

echo killall python >/boot/custom/etc/rc.d/rc.sabnzbd

...and that would have been the end of it, instead of trying to insert extra lines into your powerdown script.

 

I've considered sweeping /boot/custom/etc/rc.d/powerdown.d and running every script there.

I don't like that much, but if you have to do something like that, you could at least put that 'powerdown.d' someplace else.

 

[BRiT]

Will this do the same?

echo killall python >>/etc/rc.d/rc.local_shutdown

 

It does. The rc.local_shutdown is invoked from the system shutdown script. I have all my customized startup invoked inside rc.local_startup, and customized shutdown invoked inside rc.local_shutdown.

[Joe L.]

Wouldn't it be nice if the powerdown script had a line like this?

/boot/custom/etc/rc.d/rc.* stop

That way any custom packages could be given the chance to stop themselves 'nicely' before the mass killing begins.

 

I was thinking the same thing.

I can change it to do a directory sweep of a specific directory.

I would not do it on that directory because there may be scripts that are not geared to handle the stop, so it may end up starting things.

 

This is why I halted any further changes until I see where 5.0 brings us.

in the meantime, I've considered sweeping /boot/custom/etc/rc.d/powerdown.d and running every script there.

 

I may also add an inetd functionality to allow a sort of sol (shutdown on lan) command.

 

I broke my hand so this may have to wait a while until I can type at normal speed without errors and pain.

If you are in the mood to add things... we need to check for files (on the protected array) mounted as loop mounted file systems.

 

They will show up in the "mount" command, but do not show up as processes, or as open files, but if mounted on an unRAID disk that is in the array, they will keep the array from stopping.

 

Something like this might work:

mount | grep "loop=" | sed -n "s/.* on \(.*\) type .*/\1/p" | xargs umount

It will find the entries mounted as loop types and umount them

 

Sorry to learn you broke your hand.   Ouch...

 

Joe L.

[Joe L.]

Wouldn't it be nice if the powerdown script had a line like this?

/boot/custom/etc/rc.d/rc.* stop

That way any custom packages could be given the chance to stop themselves 'nicely' before the mass killing begins.

 

I was thinking the same thing.

I can change it to do a directory sweep of a specific directory.

I would not do it on that directory because there may be scripts that are not geared to handle the stop, so it may end up starting things.

No off-the-shelf Slackware package would go puting stuff in a directory like /boot/custom/etc/rc.d/

That makes it a good place for custom-made unRAID add-ons, to put their start/stop scripts there, if they so chose.

Any such script should be able to handle at least 'start' and 'stop' parameters. If they can't, they shouldn't be there, and it's not your problem.

As an example, the answer to the question of the starter of this thread would have simply been:

echo killall python >/boot/custom/etc/rc.d/rc.sabnzbd

...and that would have been the end of it, instead of trying to insert extra lines into your powerdown script.

I like this approach.  It would be clear it is custom, it is similar to the way Slackware handles start and stop events, and we can all work towards this changing the existing scripts to handle both "start" and "stop" events.

I've considered sweeping /boot/custom/etc/rc.d/powerdown.d and running every script there.

I don't like that much, but if you have to do something like that, you could at least put that 'powerdown.d' someplace else.

I don't like that as much either.  It is far easier in my opinion if the start and stop are both arguments to the same script.

 

Joe L.

[purko]

I would not do it on that directory because there may be scripts that are not geared to handle the stop, so it may end up starting things.

I am trying to think which scripts may that be.  As far as I can tell, none of the popular unRAID addons do such thing.

And if somebody makes such a package, they'll hear real quick in forum about a problem.

 

Most of the unRAID addons don't really need any special shutdown handling anyway.

Those that do are things like rtorrent, sabnzbd, sharing of a iso image, etc.

 

I know that if you put a  '/boot/custom/etc/rc.d/rc.* stop'  early in your powerdown script,

then I'll immediately update my unTorrent package to place one  '/boot/custom/etc/rc.d/rc.untorrent'  there.

 

@Joe: You could easily put one '/boot/custom/etc/rc.d/rc.iso_share' to do the umounting.

 

@Weebo: And while you're at it, won't you please make your installer rename the stock powerdown to old_powerdown?

I really don't see the benefit to having them both available by the same name. It only brings unnecessary confusion.

 

[Joe L.]

I would not do it on that directory because there may be scripts that are not geared to handle the stop, so it may end up starting things.

I am trying to think which scripts may that be.  As far as I can tell, none of the popular unRAID addons do such thing.

And if somebody makes such a package, they'll hear real quick in forum about a problem.

 

Most of the unRAID addons don't really need any special shutdown handling anyway.

Those that do are things like rtorrent, sabnzbd, sharing of a iso image, etc.

 

I know that if you put a  '/boot/custom/etc/rc.d/rc.* stop'  early in your powerdown script,

then I'll immediately update my unTorrent package to place one  '/boot/custom/etc/rc.d/rc.untorrent'  there.

 

@Joe: You could easily put one '/boot/custom/etc/rc.d/rc.iso_share' to do the umounting.

 

You bet I will.  There are actually three different scripts I'd put there... and certainly invoking each in that folder with a "start" argument is easy enough to perform to initially start up processes that should only start after the array is online.

 

Thinking about it even more, on unRAID version 4.5 I think we have enough information available to us between the syslog and  other clues that the array is stopping (or attempting to stop), or has just started.  I think I'll attempt to write a triggering program to run the custom/rc.d/* start and stop processes.  Soon, when unRAID 5.0 is available, we can replace it with actual before-stop and after-start event scripts.

[purko]

Thinking about it even more, on unRAID version 4.5 I think we have enough information available to us between the syslog and  other clues that the array is stopping (or attempting to stop), or has just started.   I think I'll attempt to write a triggering program to run the custom/rc.d/* start and stop processes.

 

That is one great idea! 

 

In that case my package can just install the rtorrent stuff, but not bother starting it:

leave it to your triggering program to do the starting once the array is fully started.

 

That'd be cool!

 

[WeeboTech]

I would not do it on that directory because there may be scripts that are not geared to handle the stop, so it may end up starting things.

I am trying to think which scripts may that be.  As far as I can tell, none of the popular unRAID addons do such thing.

And if somebody makes such a package, they'll hear real quick in forum about a problem.

 

Most of the unRAID addons don't really need any special shutdown handling anyway.

Those that do are things like rtorrent, sabnzbd, sharing of a iso image, etc.

 

I know that if you put a  '/boot/custom/etc/rc.d/rc.* stop'  early in your powerdown script,

then I'll immediately update my unTorrent package to place one  '/boot/custom/etc/rc.d/rc.untorrent'  there.

 

@Joe: You could easily put one '/boot/custom/etc/rc.d/rc.iso_share' to do the umounting.

 

@Weebo: And while you're at it, won't you please make your installer rename the stock powerdown to old_powerdown?

I really don't see the benefit to having them both available by the same name. It only brings unnecessary confusion.

 

 

ps> I can hardly type, so please understand my short and terse replies.

There are a number of programs/scripts released on the forum that do not take advantage of the start/stop parameters.  Early on we suggested having different directories for different levels.

 

I do not agree with running every '/boot/custom/etc/rc.d/rc.* stop' it should be another level down.

I do not care what that directory is, but it should be one level down.

Anything in the next level down is run with a start or stop parameter.

As is the case in many unix setups.

 

Monitoring array start/stop via syslog or mdcmd does seem like a good way to trigger run levels.

 

echo killall python >/boot/custom/etc/rc.d/rc.sabnzbd

 

This is not advisable, it ends up overwriting rc.sabnzbd instead of appending to a shutdown script or into the proper block of a shutdown script.

 

sed -i  "/rc.nfsd  stop/a killall python" /etc/rc.d/rc.unRAID

 

works, but this can also be put in /etc/rc.d/rc.local_shutdown and may be better there if put before the rc.unRAID call.

 

ps. I can hardly type, so please understand the reason for my short/terse replies.

 

[purko]

Weebo, take a break, man!

It's not like this stuff requires any kind of immediate action.

I'm just throwing some ideas around.

 

There are a number of programs/scripts released on the forum that do not take advantage of the start/stop parameters.

Do those programs/scripts put anything in '/boot/custom/etc/rc.d/'?  I don't think so.  So why should you worry?

 

echo killall python >/boot/custom/etc/rc.d/rc.sabnzbd

This is not advisable, it ends up overwriting rc.sabnzbd instead of appending to a shutdown script or into the proper block of a shutdown script.

I said that on purpose, because as it stands now, there's no 'rc.sabnzbd' there.

So that would have been just a quick patch, until the time that the guy who packages sabnzbd for unRAID learns that it's a cool idea to put his own start/stop 'rc.sabnzbd' in that directory.

 

[Joe L.]

I would not do it on that directory because there may be scripts that are not geared to handle the stop, so it may end up starting things.

I am trying to think which scripts may that be.  As far as I can tell, none of the popular unRAID addons do such thing.

And if somebody makes such a package, they'll hear real quick in forum about a problem.

 

Most of the unRAID addons don't really need any special shutdown handling anyway.

Those that do are things like rtorrent, sabnzbd, sharing of a iso image, etc.

 

I know that if you put a  '/boot/custom/etc/rc.d/rc.* stop'  early in your powerdown script,

then I'll immediately update my unTorrent package to place one  '/boot/custom/etc/rc.d/rc.untorrent'  there.

 

@Joe: You could easily put one '/boot/custom/etc/rc.d/rc.iso_share' to do the umounting.

 

@Weebo: And while you're at it, won't you please make your installer rename the stock powerdown to old_powerdown?

I really don't see the benefit to having them both available by the same name. It only brings unnecessary confusion.

 

 

ps> I can hardly type, so please understand my short and terse replies.

There are a number of programs/scripts released on the forum that do not take advantage of the start/stop parameters.  Early on we suggested having different directories for different levels.

 

I do not agree with running every '/boot/custom/etc/rc.d/rc.* stop' it should be another level down.

Is this because of the presence of existing scripts in this /boot/custom/etc/rc.d directory you are afraid would be invoked in error?

(you can answer Y/N to save your fingers)

I do not care what that directory is, but it should be one level down.

Anything in the next level down is run with a start or stop parameter.

As is the case in many unix setups.

There are some distributions on unix that have sub-directories for various run-levels.  Slackware does not.

I can understand though, as I have a number of scripts in the /boot/custom/etc/rc.d directory myself.  

Although most are currently commented out and do absolutely nothing, my own set of scripts is:

root@Tower:/boot/custom/etc/rc.o# ls
S01-initrc*                   S100-ntfs-3g-package-install*   S124-smartctl*              S40-set_read_buffer*       rc.local_startup*
S03-timezone_copy*            S110-file-package-install*      S130-monthly_parity_check*  S50-mail-install*         
S05-sleep*                    S120-apcupsd-package-install*   S140-frequent_ls*           S51-mail-forward-install*
S10-fix_log_rotate*           S121-lsof-package-install*      S150-spinup_when_accessed*  S70-update_nameserver*
S10-install_custom_packages*  S122-install-pciutils-package*  S20-spin_drives*            S80-update_hosts*
S10-smtp_alert*               S123-libraries-packages*        S30-inittab-powerdown*      

 

How about

/boot/custom/etc/rc.d/unraid.d

Will that work for you as the directory for the add-on rc.* scripts that can handle "start" and "stop" arguments (Y/N)?  (and anyone else who wants to add their ideas)  

Monitoring array start/stop via syslog or mdcmd does seem like a good way to trigger run levels.

echo killall python >/boot/custom/etc/rc.d/rc.sabnzbd

 

This is not advisable, it ends up overwriting rc.sabnzbd instead of appending to a shutdown script or into the proper block of a shutdown script.

I agree, it should have tested for the file's existence first.... it might clobber a more correct method of stopping the process.   Also, there may be a better way to shut down the process rather than sending it a sigkill signal.

sed -i  "/rc.nfsd  stop/a killall python" /etc/rc.d/rc.unRAID

 

works, but this can also be put in /etc/rc.d/rc.local_shutdown and may be better there if put before the rc.unRAID call.

 

ps. I can hardly type, so please understand the reason for my short/terse replies.

 

The big question for me is the order in which the scripts run.  Most of them are too late to terminate processes holding the array from stopping.  As long as we can figure out the correct order, then it does not matter.  I know you put rc.unRAID in rc.local_shutdown, but it does not help when trying to stop the array from the management console and one or more disks are busy and you never get to pressing the power button.

 

I just re-read the third-party-boot-architecture, as described in the wiki.   I have concerns about there being so many sub-directories (one per event) as it being unwieldy to deal with an existing package that has both "start" and "stop" events defined in a single script.

 

In the same way, I can occasionally see the need for some of the other events besides post-array-start and pre-array-stop, so I don't want to forget about them in the grand scheme of things.

 

(here is where it will hurt) What can we do to accommodate both needs? (simplicity vs. flexibility)

What do you think of a single unraid.d directory and calling the scripts there with arguments of

start                                 -- this can be a synonym for post_array_start

stop                                  -- this can be a synonym for pre_array_stop

pre_array_start                   (no current way to detect this I know of...)

pre_array_start_onboot        (this can be detected with a line added to the "go" script above the line invoking emhttp)

post_array_start_onboot      ( same as post_array_start logic, but looks for presence of flag file in /var/lock so it only runs once)

post_array_start                 (initial presence of mounted "md" devices where they were not mounted previously)

pre_array_stop                   (attempt to un-mount "md" devices)

post_array_stop                 ( no mounted "md" devices where there were previously )

 

It can be simplified if the scripts that only  need be invoked once per boot deal with that by their own flag in /var/lock.

If the flag is already present, they can do nothing, if the flag is not present, they can perform their tasks. (typically installing themselves)

That way, the "*_onboot" events are not needed at all.

 

Joe L

[purko]

start                                 -- this can be a synonym for post_array_start

stop                                  -- this can be a synonym for post_array_stop

 

Was that a typo?  Don't you mean...

start                                -- this can be a synonym for post_array_start

stop                                  -- this can be a synonym for pre_array_stop

 

[Joe L.]

start                                 -- this can be a synonym for post_array_start

stop                                  -- this can be a synonym for post_array_stop

 

Was that a typo?  Don't you mean...

start                                 -- this can be a synonym for post_array_start

stop                                  -- this can be a synonym for pre_array_stop

 

Yes, cut-and-paste error... it should be

start                                -- this can be a synonym for post_array_start

stop                                  -- this can be a synonym for pre_array_stop

[purko]

Well then, as long as we designate one directory which will get swept with a single...

/.../.../.../.../rc.* start

...and with...

/.../.../.../.../rc.* stop &
wait

... respectively by a trigger program upon 'post_array_start' and 'pre_array_stop' events,

then I don't much care where exactly we'll decide that directory to be.

('/boot/custom/etc/rc.d/' seemed like the logical choice, but pick anything else if you feel like)

[Joe L.]

You are going to love this but of humor...

I've got the basic monitoring script running here, with two stub functions to start and stop the entries in the rc.d hierarchy.

 

I took a look and found I still had mysql running from my test the other day.  It has a rc.mysql located in /etc/rc.d so I figured it would be good to use as a test.

 

In my pre-stop function I added a line

/etc/rc.d/rc.mysql stop

 

In my post-start function I put

/etc/rc.d/rc.mysql start

 

I figured I'd test with just the one program before writing a loop to process all in a directory, and it was already running keeping my disk1 busy, so I know if I were to attempt to stop the array it would not stop.

 

Now, I put everything into place, I'm watching my script run.  It works as I desired and it invoked the rc.mysql stop command.

 

I see "Permission denied" 

 

I'm running as root, so I was a bit confused... I investigated, the script was installed as mode 644. Not executable.

 

OK... so I change my script to call it with

sh -xv /etc/rc.d/rc.mysql stop

 

I run my monitoring script, press "Stop" on the unRAID management page,

Again, it detects the attempt to stop the array and AGAIN ... mysqld does not stop.

 

Arg.......

 

Debugging rc.mysqld next ... it is looking for a lock-file in

/var/run/mysql/mysql.pid

If it exists, it will terminate mysql using

killall mysqld

If it does not exist, it does nothing, even if mysqld is running.

 

Guess what, the mysql.pid file does not exist on my server, so it does not try to terminate itself.

 

Don't you love it when you have to debug other people's code...  ;D

 

Joe L.

[purko]

That's one crappy 'rc.mysql'! 

When you give it a chance to kill itself, it should do so, the nicest way it knows.

Or you'll have to pull out the big guns and kill it not so nicely.

 

[WeeboTech]

Is this because of the presence of existing scripts in this /boot/custom/etc/rc.d directory you are afraid would be invoked in error?

(you can answer Y/N to save your fingers)

 

Exactly, ie. until there is an official architecture strategy.

 

How about

/boot/custom/etc/rc.d/unraid.d

Will that work for you as the directory for the add-on rc.* scripts that can handle "start" and "stop" arguments (Y/N)?  (and anyone else who wants to add their ideas)

 

This works well.

[MortenSchmidt]

Wow, what a turnout, all the heavy hitters 

 

Thanks, inserting the killall python with the sed command suggested by Joe does the trick. As long as the Preclear_disk.sh script is not running...

 

Joe, are you going to add a stop script to your preclear package as well? Might be nit-picking here, but who is to say that script is not running exactly the day there will be an extended power outage and apcupsd tries to shut down?

 

For now, I guess I will put a command in the powerdown script to "killall preclear_disk.sh". We don't necessarily want that script killed when stopping the array, I guess. Seems to work too.

 

@Weebo: And while you're at it, won't you please make your installer rename the stock powerdown to old_powerdown?

I really don't see the benefit to having them both available by the same name. It only brings unnecessary confusion.

 

Say what??? Second that, I guess.

I'm still fairly green here and only just now found the likeley reason my initial trial with inserting the killall python command at the end of the powerdown script did not work. I just type powerdown, but now realize I need to type /sbin/powerdown. Not 100% user friendly if you ask me (although you guys do seem friendly enough )

 

Oh, and Cool that you guys get together this way to align issues like this! I sure do look forward to seeing this stuff you guys have been cooking up here implemented.

[Joe L.]

Joe, are you going to add a stop script to your preclear package as well? Might be nit-picking here, but who is to say that script is not running exactly the day there will be an extended power outage and apcupsd tries to shut down?

It is not running on any of the disks in the array, therefore, it would not stop the array from shutting down.  No need to kill it, it will terminate when the server powers off.  The critical point is to allow the array to stop cleanly, so we will not be faced with a full parity check upon power restore.

For now, I guess I will put a command in the powerdown script to "killall preclear_disk.sh". We don't necessarily want that script killed when stopping the array, I guess. Seems to work too.

As I said, not needed.

@Weebo: And while you're at it, won't you please make your installer rename the stock powerdown to old_powerdown?

I really don't see the benefit to having them both available by the same name. It only brings unnecessary confusion.

 

Say what??? Second that, I guess.

I'm still fairly green here and only just now found the likeley reason my initial trial with inserting the killall python command at the end of the powerdown script did not work. I just type powerdown, but now realize I need to type /sbin/powerdown. Not 100% user friendly if you ask me (although you guys do seem friendly enough )

 

Oh, and Cool that you guys get together this way to align issues like this! I sure do look forward to seeing this stuff you guys have been cooking up here implemented.

for the first few years of unRAID's existence the only "powerdown" command was the one WeeboTech wrote.

At some point in the past year or so, lime-technology added one of their own.  It is not equivalent.  It might even power down without stopping the array. (one user made that report)  Up until the lime-tech command appeared it was not necessary to use the full path to invoke it. 

 

Now, with the way the $PATH variable is set, you'll get the lime-tech command if you don't specify the full path. All it does is press the "Powerdown" button on the management web-page. (The one that is normally not visible unless the array  is stopped)

 

As I said, one user reported it did not cleanly stop their array first.

 

Joe L.

[MortenSchmidt]

OK, sounds reasonable. What a mess with the limetech powerdown command being added there. Guess that is why I stated it would not shut down when preclear is running, I was using the limetech powerdown when fiddling with the console.

 

I'm running my UPS test now with the server powered from the wall jack and hope to see it shut down. Again, thanks for the help.