Normally the mover moves my downloaded stuff to the array starting at 03:40. Is it possible to disable this and start the mover immediately after my server boots in the morning? Can it for instance be started with a command in the go script, perhaps after a delay, so everything is "settled"? ?

According to the Wiki, "... The mover is just a script called ‘/usr/share/sbin/mover’ "

 

So if you add "/usr/share/sbin/mover" to your Go script, it should run the mover.

 

HOWEVER ... if it tries to run and the array isn't yet running it probably won't work right.  I don't know if that's a potential issue at this point in the boot or not.  I know with "Cache_Dirs" you can add a -w option that will wait for the array to start; but I don't know if that option will also work with the mover or not (Decidedly NOT a "Linux guy").

 

You could also simply change the times when the Mover runs ... how to do that is outlined here:  http://lime-technology.com/wiki/index.php/Plugin/webGui/Mover_Settings

 

As I don't use a Cache drive, I didn't realize the time could be so easily changed (as Joe L noted).

 

However ... that doesn't answer your question about a "move on boot" option.

 

If that's not one of the choices, then you likely need some entry in the Go script, but Joe L didn't comment on whether or not my suggestion above would work.

 

Joe -- Any comment?

 

As I don't use a Cache drive, I didn't realize the time could be so easily changed (as Joe L noted).

 

However ... that doesn't answer your question about a "move on boot" option.

 

If that's not one of the choices, then you likely need some entry in the Go script, but Joe L didn't comment on whether or not my suggestion above would work.

 

Joe -- Any comment?

You would absolutely need to wait for the file systems to be available.  In the event of a non-clean power hit, I've seen it take 30 minutes or more replaying the file-system-journal before the disks were mounted.    There is no safe way to just delay a few minutes in the config/go script.

 

Joe L.

Once the event subsystem has been worked out, a script can monitor for an event and run when that event occurs. Or be part of that event subsystem.

 

For now, it's a poll operation.

 

What I might do is set the mover to run at earlier time.

Save the system logs (just in case you have to review).

Then shutdown.

 

or set the mover to run after you know you should have come up gracefully, i.e. given any restart or journal replaying.

 

Perhaps an hour after normal boot schedule.

 

Once the event subsystem has been worked out, a script can monitor for an event and run when that event occurs. Or be part of that event subsystem.

You can take advantage of the event system now.  You'll need to add a series of three lines in the config/go script though, and they will need to be at the top of the config/go script, before the line invoking "emhttp"

 

You can put something like this in your "config/go" script to create a one line script to the location looked for for event scripts each time you reboot.

mkdir -p /usr/local/emhttp/plugins/my_mover/event/

echo "sleep 60;/usr/local/sbin/mover & " >/usr/local/emhttp/plugins/my_mover/event/svcs_restarted

chmod +x /usr/local/emhttp/plugins/my_mover/event/svcs_restarted

Once you add those lines, the mover will kick off 60 seconds after the array has finished mounting its disks upon any restart (not just the first one in the morning) 

 

Note that you really do not have a plugin named "my_mover" but that is the path looked for by the event system.

(It can be any name other than "my_mover" as long as it does not have embedded spaces or quotes and you use the same name on all three added lines.)

 

Once the event subsystem has been worked out, a script can monitor for an event and run when that event occurs. Or be part of that event subsystem.

You can take advantage of the event system now.  You'll need to add a series of three lines in the config/go script though, and they will need to be at the top of the config/go script, before the line invoking "emhttp"

 

You can put something like this in your "config/go" script to create a one line script to the location looked for for event scripts each time you reboot.

mkdir -p /usr/local/emhttp/plugins/my_mover/event/

echo "sleep 60;/usr/local/sbin/mover & " >/usr/local/emhttp/plugins/my_mover/event/svcs_restarted

chmod +x /usr/local/emhttp/plugins/my_mover/event/svcs_restarted

Once you add those lines, the mover will kick off 60 seconds after the array has finished mounting its disks upon any restart (not just the first one in the morning) 

 

Note that you really do not have a plugin named "my_mover" but that is the path looked for by the event system.

(It can be any name other than "my_mover" as long as it does not have embedded spaces or quotes and you use the same name on all three added lines.)

 

Thanks Joe,

 

Very helpfull. Are these lines fully functional, and ready to be added to the go script?

 

I might give give it a go.

 

Once the event subsystem has been worked out, a script can monitor for an event and run when that event occurs. Or be part of that event subsystem.

You can take advantage of the event system now.  You'll need to add a series of three lines in the config/go script though, and they will need to be at the top of the config/go script, before the line invoking "emhttp"

 

You can put something like this in your "config/go" script to create a one line script to the location looked for for event scripts each time you reboot.

mkdir -p /usr/local/emhttp/plugins/my_mover/event/

echo "sleep 60;/usr/local/sbin/mover & " >/usr/local/emhttp/plugins/my_mover/event/svcs_restarted

chmod +x /usr/local/emhttp/plugins/my_mover/event/svcs_restarted

Once you add those lines, the mover will kick off 60 seconds after the array has finished mounting its disks upon any restart (not just the first one in the morning) 

 

Note that you really do not have a plugin named "my_mover" but that is the path looked for by the event system.

(It can be any name other than "my_mover" as long as it does not have embedded spaces or quotes and you use the same name on all three added lines.)

 

Thanks Joe,

 

Very helpfull. Are these lines fully functional, and ready to be added to the go script?

 

I might give give it a go.

they should be fully functional.

Once the event subsystem has been worked out, a script can monitor for an event and run when that event occurs. Or be part of that event subsystem.

You can take advantage of the event system now.  You'll need to add a series of three lines in the config/go script though, and they will need to be at the top of the config/go script, before the line invoking "emhttp"

 

You can put something like this in your "config/go" script to create a one line script to the location looked for for event scripts each time you reboot.

mkdir -p /usr/local/emhttp/plugins/my_mover/event/

echo "sleep 60;/usr/local/sbin/mover & " >/usr/local/emhttp/plugins/my_mover/event/svcs_restarted

chmod +x /usr/local/emhttp/plugins/my_mover/event/svcs_restarted

Once you add those lines, the mover will kick off 60 seconds after the array has finished mounting its disks upon any restart (not just the first one in the morning) 

 

Note that you really do not have a plugin named "my_mover" but that is the path looked for by the event system.

(It can be any name other than "my_mover" as long as it does not have embedded spaces or quotes and you use the same name on all three added lines.)

 

Thanks Joe,

 

Very helpfull. Are these lines fully functional, and ready to be added to the go script?

 

I might give give it a go.

they should be fully functional.

 

Do I have to add a line that actually starts the mover?

 

I don't see that the mover is actually running after adding these lines and rebooting.

 

It should, after about 1 minute.

I don't see that the mover is actually running after adding these lines and rebooting.

 

Did you change "my_mover" to the correct value the 3 times it occurs?

 

I don't see that the mover is actually running after adding these lines and rebooting.

 

Did you change "my_mover" to the correct value the 3 times it occurs?

That IS as good a name as any.  No need to change it in the sample script.  It simply is the name of the directory the script will be created in, and it fits the pattern looked for by unRAID

I don't see that the mover is actually running after adding these lines and rebooting.

 

Did you change "my_mover" to the correct value the 3 times it occurs?

That IS as good a name as any.  No need to change it in the sample script.  It simply is the name of the directory the script will be created in, and it fits the pattern looked for by unRAID

 

Ahh, I understand now.  I thought you were saying it had to be changed to match whatever the actual path was on the system it was being used on.

To be honest, I can't quit follow what the lines do and mean.

 

I can see a directory gets created and I checked in a telnet session, it does get created.

 

I added the lines to the go script, does it matter where?

 

The go script and syslog are attached.

syslog-2013-06-29.zip

I don't see that the mover is actually running after adding these lines and rebooting.

 

Did you change "my_mover" to the correct value the 3 times it occurs?

That IS as good a name as any.  No need to change it in the sample script.  It simply is the name of the directory the script will be created in, and it fits the pattern looked for by unRAID

 

Ahh, I understand now.  I thought you were saying it had to be changed to match whatever the actual path was on the system it was being used on.

It is the actual path.

The part that might change is the "name" you give this plugin.  (it is not a full plugin, but an event that works within the plugin system)  The event names are fixed, the event plugin path is fixed, the name of it (my_mover) can be anything that does not conflict with another plugin.

 

Joe L.

 

 

I'm definitely confused -- I don't need this at the moment, but I AM planning to add an SSD cache drive, and would then like to do something along these same lines.

 

Earlier, you said "... It can be any name other than "my_mover" as long as it does not have embedded spaces or quotes and you use the same name on all three added lines."

 

... but then you said it didn't need to be changed ... and that the lines as written should be "fully functional".    But it doesn't seem that's the case on dikkiedirk's system.  And you said "... The part that might change is the "name" you give this plugin ..." ==> but I thought that was fixed for the Mover ... isn't that right?

 

I'm definitely NOT a "Linux guy", but looking at the 3 lines, it appears to me the first line creates a /my_mover/event/  subfolder structure in the plugins folder;  the 2nd line seems to set a 60 second timer for the Mover (Is this right?);  and I have no idea what the 3rd line does.

 

But the real question is what dikkiedirk asked:  Should these 3 lines in the Go script cause the mover to run 60 seconds after emhttp is started?    If so, that's all he (and I) would like to do 

To be honest, I can't quit follow what the lines do and mean.

 

I can see a directory gets created and I checked in a telnet session, it does get created.

Yes, the first line creates a directory.

The second line creates a file in that directory with the commands to sleep 60 seconds and then invoke mover in the background.

The third line make the command file execuitable.

 

The file will be invoked when the svcs_restarted "event" occurs in unRAID.  This occurs after the upon startup after the disks are mounted and the SMB and other services are started.  At that time it is when the event fires, the script sleeps for 60 seconds, and then the mover is invoked.  It will also fire that event if you stop and then subsequently restart the array.

I added the lines to the go script, does it matter where?

Yes, it does...  If failed to work for youo because you did not add them before invoking emhttp.  It fires the "events".    By the time you added the lines, the event had already occurred, not finding your added plugin/event since it was not there yet. 

 

Guess you did not read earlier where I said

and they will need to be at the top of the config/go script, before the line invoking "emhttp"

The go script and syslog are attached.

 

The replacement "go" script follows.  Note I changed slightly the command I create in the "svcs_restarted" file.

 

#!/bin/bash

 

mkdir -p /usr/local/emhttp/plugins/my_mover/event/

echo 'sh -c "sleep 60;/usr/local/sbin/mover" &'  >/usr/local/emhttp/plugins/my_mover/event/svcs_restarted

chmod +x /usr/local/emhttp/plugins/my_mover/event/svcs_restarted

 

# Start the Management Utility

/usr/local/sbin/emhttp &

 

# Wait for disk1 to be mounted.

while ! test -d /mnt/disk1; do sleep 5; continue; done

 

# start the unMENU web-server

/boot/unmenu/uu

 

# mount the netgear file system

mkdir /mnt/netgear

mount -t cifs -o username=media,password=,uid=nobody,gid=users //192.168.10.101/media /mnt/netgear

 

#/boot/cache_dirs  -w

/boot/config/plugins/snap/snap.sh -b

 

# install the unMENU packages marked to re-install on reboot.

cd /boot/packages && find . -name '*.auto_install' -type f -print | sort | xargs -n1 sh -c

 

# schedule a powerdown at 1 AM.

echo "powerdown" | at 01:00

Thanks Joe,

 

I appreciate the detail.

 

Am I correct in assuming that even though dikkiedirk had the lines place AFTER emhttp had already started, if he had stopped the array, then restarted it, the Mover script would kicked off 60 seconds later?

 

Thanks Joe,

 

I appreciate the detail.

You are welcome

Am I correct in assuming that even though dikkiedirk had the lines place AFTER emhttp had already started, if he had stopped the array, then restarted it, the Mover script would kicked off 60 seconds later?

Yes, it would have. 

Thanks Joe,

 

I appreciate the detail.

 

Am I correct in assuming that even though dikkiedirk had the lines place AFTER emhttp had already started, if he had stopped the array, then restarted it, the Mover script would kicked off 60 seconds later?

 

Thanks from me to Joe.

 

I seem to run in an issue here. The positive thing is that the mover is running after booting the server, but one of the disks stays on "resizing". I don't know if starting the mover has anything to do with it. Maybe the 60 seconds sleep should be increased?

I seem to run in an issue here. The positive thing is that the mover is running after booting the server, but one of the disks stays on "resizing". I don't know if starting the mover has anything to do with it. Maybe the 60 seconds sleep should be increased?

Certainly, you can try increasing it.    Make sure you use the version I posted last, as it would work better.  (the one with the  line echo '"sh -c ...... "')

 

Joe L.

Will do Joe. I already added the last version. What is the difference, using the sh line?

Will do Joe. I already added the last version. What is the difference, using the sh line?

The "sleep" was not done in the background, but in the foreground.

It delayed the entire "event" (and emhttp) from continuing, rather than just delaying the "mover"

 

Joe L.