1 hour ago, bedivereyang said:

does the user.scripts plugin come with a script to download xmrig

Absolutely not

On 5/12/2023 at 1:27 AM, adgilcan said:

I think I solved it and post it here for others.

 

The order displayed is defined by the order of the folders in config/plugins/user.scripts/scripts

It appears you can rename these without having to alter the name of the script in User Scripts.  At least that seems to work for me.

 

I hope that helps

 

D

 

Have 2 question on the order of the scripts displayed in GUI.

 

How can it be linked to the order of folders within a folder since I've always thought such a thing doesn't exist,

that there only exist a concept of "Display Order": how a client renders it at the "viewer"'s end (by size, by creation time, etc). And there isn't such a thing as an inherent order of within a folder.

 

1. How can I change the GUI order currently? (a.k.a how to change the order of `config/plugins/user.scripts/scripts`?)

 

2. Can we change it so that the order is just by the name of the script?

(this will also satisfy this feature request

)

 

Thanks!

Edited July 6, 20241 yr by StylishQuoter

Hey everyone. I'm another user having trouble with the log button not showing, which occurs even if I run a script in the background. Not sure what to do -- here's an example attached, before aborting the script and after.

All of a sudden, when I try to apply the cron schedule changes, I get this...

 

error: /plugins/user.scripts/exec.php: missing csrf_token

 

UnRAID v6.12.10
User Scripts v2024.03.29

 

Any idea why this would happen out of the blue?  I haven't updated anything...

I am having this issue where User Scripts seems to be running a script twice.

 

The schedule of my scripts are "At Startup of Array" and the logs show this:

Script Starting Jul 09, 2024 20:50.57

Full logs for this script are available at /tmp/user.scripts/tmpScripts/HDDmain snapshotting/log.txt

Script Finished Jul 09, 2024 20:50.57

Full logs for this script are available at /tmp/user.scripts/tmpScripts/HDDmain snapshotting/log.txt

Script Starting Jul 09, 2024 22:38.51

Full logs for this script are available at /tmp/user.scripts/tmpScripts/HDDmain snapshotting/log.txt

Script Finished Jul 09, 2024 22:38.51

Full logs for this script are available at /tmp/user.scripts/tmpScripts/HDDmain snapshotting/log.txt


Script Starting Jul 09, 2024 20:50.57

Full logs for this script are available at /tmp/user.scripts/tmpScripts/SSDmain snapshotting/log.txt

Script Finished Jul 09, 2024 20:50.57

Full logs for this script are available at /tmp/user.scripts/tmpScripts/SSDmain snapshotting/log.txt

Script Starting Jul 09, 2024 22:38.51

Full logs for this script are available at /tmp/user.scripts/tmpScripts/SSDmain snapshotting/log.txt

Script Finished Jul 09, 2024 22:38.51

Full logs for this script are available at /tmp/user.scripts/tmpScripts/SSDmain snapshotting/log.txt

 

The scripts add a cronjob for Sanoid like this

#!/bin/bash
(crontab -l 2>/dev/null; echo "*/5 * * * *  /usr/local/sbin/sanoid --configdir=/mnt/ssdmain --cron") | crontab -

 

And crontab -l confirms the cronjob is being added twice

root@Alagaesia:~# crontab -l
# If you don't want the output of a cron job mailed to you, you have to direct
# any output to /dev/null.  We'll do this here since these jobs should run
# properly on a newly installed system.  If a script fails, run-parts will
# mail a notice to root.
#
# Run the hourly, daily, weekly, and monthly cron jobs.
# Jobs that need different timing may be entered into the crontab as before,
# but most really don't need greater granularity than this.  If the exact
# times of the hourly, daily, weekly, and monthly cron jobs do not suit your
# needs, feel free to adjust them.
#
# Run hourly cron jobs at 47 minutes after the hour:
47 * * * * /usr/bin/run-parts /etc/cron.hourly 1> /dev/null
#
# Run daily cron jobs at 4:40 every day:
40 4 * * * /usr/bin/run-parts /etc/cron.daily 1> /dev/null
#
# Run weekly cron jobs at 4:30 on the first day of the week:
30 4 * * 0 /usr/bin/run-parts /etc/cron.weekly 1> /dev/null
#
# Run monthly cron jobs at 4:20 on the first day of the month:
20 4 1 * * /usr/bin/run-parts /etc/cron.monthly 1> /dev/null
*/5 * * * *  /usr/local/sbin/sanoid --configdir=/mnt/hddmain --cron
*/5 * * * *  /usr/local/sbin/sanoid --configdir=/mnt/ssdmain --cron
*/5 * * * *  /usr/local/sbin/sanoid --configdir=/mnt/hddmain --cron
*/5 * * * *  /usr/local/sbin/sanoid --configdir=/mnt/ssdmain --cron

 

I think this has been happening since I first used User Scripts(over a year+), but I only ever used User Scripts for Sanoid so duplicate snapshots did not affect me much. I only now am diving deeper into this issue since I am currently changing some of my Sanoid schedules.

Edited August 12, 20241 yr by Percutio
Added all scripts image

On 8/10/2024 at 11:53 PM, House Of Cards said:

All of a sudden, when I try to apply the cron schedule changes, I get this...

 

error: /plugins/user.scripts/exec.php: missing csrf_token

 

UnRAID v6.12.10
User Scripts v2024.03.29

 

Any idea why this would happen out of the blue?  I haven't updated anything...

 

No ideas?  Everything is up to date.  Restarted.  Nothing fixes this....

18 hours ago, House Of Cards said:

No ideas?  Everything is up to date.

Post the diags to confirm the plugin is up to date.

7 hours ago, JorgeB said:

Post the diags to confirm the plugin is up to date.

Here you go.  Thanks for the help...

 

 

diagnostics-20240818-1304.zip

@Squidany idea why this is happening with up to date plugin?

 

On 8/17/2024 at 3:40 PM, House Of Cards said:

error: /plugins/user.scripts/exec.php: missing csrf_token

 

On 8/19/2024 at 6:39 AM, JorgeB said:

@Squidany idea why this is happening with up to date plugin?

 

 

I'm a bit disappointed there are no ideas here.  I've been in a holding pattern for a month with this not working.  I have close to 250 scripts, and I can no longer edit a schedule for them.

2 hours ago, House Of Cards said:

I'm a bit disappointed there are no ideas here.  I've been in a holding pattern for a month with this not working.  I have close to 250 scripts, and I can no longer edit a schedule for them.

 

There is the unlikely possibility that a plugin in your browser could be interfering. Could you try to make a trivial change from the browser on your phone and see if that works?

Hi all,

i have a problem with "rsync" log when running in background.
I am not able to see the file progression
Opening the "log.txt" it seems that the file progression is written in one line without going in a new line
How is the break line done? can i change something to make this working?

 

Edited August 29, 20241 yr by Yusseiin

23 hours ago, WizADSL said:

 

There is the unlikely possibility that a plugin in your browser could be interfering. Could you try to make a trivial change from the browser on your phone and see if that works?

Same result when I do that.  I also disabled anything on the firewall for ad-blocking previously, but same.  From what I understand it's a cross site token or something, designed to guard against attacks so I went exploring that angle a bit...  Thing is I haven't changed anything besides upgrading UnRAID.  It was perfect until now, and seemingly without reason, but there have been no updates on this plugin since like march...

It strange because there are a lot of other users using the plugin, including myself, without issues, but that error is usually a plugin issue, so not sure where the issue comes from.

17 minutes ago, JorgeB said:

It strange because there are a lot of other users using the plugin, including myself, without issues, but that error is usually a plugin issue, so not sure where the issue comes from.

I'll keep looking.  I know it works, so I'm probably a unicorn in this regard.  It's gotta be something on my end, just not sure what.

 

20 hours ago, House Of Cards said:

I'll keep looking.  I know it works, so I'm probably a unicorn in this regard.  It's gotta be something on my end, just not sure what.

 

I installed Tailscale, and accessed the server over the cell network remotely over the VPN, so completely independent of my network and browsers, same issue.  Could it be related to the number of scripts?  Is there a limit that may throw an error?

 

I was hoping @Squid would have some insight...

Hi All,

I need help running scripts with custom cron schedule as they don't seem to be running at the schedule I set.

I only have 2 scripts. An antivirus script and a clear drive script. I wanted to schedule the Antivirus script but didn't seem to run at the time i set. However, when I click 'run script', 'run in background', or using the pre-defined schedule (I used 'at stopping of array' for testing) they work without any issue.

I tested again by making a new simple script with a custom cron schedule set:

#!/bin/bash
powerdown

 

I set the cron schedule to:

0 9 * * *     (fyi, It was 8:45am when I set the schedule)
(9am every every day)

I waited a few minutes after 9am but nothing happened (server did not power down) and no log was recorded. I did try at different times as well....9:05am, 11:30am - 5 9 * * * , 30 11 * * * , etc. Also tried every 30 seconds.... 30 * * * *)

However, I was able to run the script when clicking 'run script', 'run in background', or using the pre-defined schedule as tested above and the device powered down accordingly. A log was created as well.

 

I also made sure that the system date and time was also correct. So I am a bit stumped as to why it won't run.

I have attached the unraid logs in case that helps. Also ran the commands below in case that helps - i did see some posts suggest running this and can see the script has been added to it. Would greatly appreciate any help. Please see below:

root@Tower:~# crontab -l
# If you don't want the output of a cron job mailed to you, you have to direct
# any output to /dev/null.  We'll do this here since these jobs should run
# properly on a newly installed system.  If a script fails, run-parts will
# mail a notice to root.
#
# Run the hourly, daily, weekly, and monthly cron jobs.
# Jobs that need different timing may be entered into the crontab as before,
# but most really don't need greater granularity than this.  If the exact
# times of the hourly, daily, weekly, and monthly cron jobs do not suit your
# needs, feel free to adjust them.
#
# Run hourly cron jobs at 47 minutes after the hour:
47 * * * * /usr/bin/run-parts /etc/cron.hourly 1> /dev/null
#
# Run daily cron jobs at 4:40 every day:
40 4 * * * /usr/bin/run-parts /etc/cron.daily 1> /dev/null
#
# Run weekly cron jobs at 4:30 on the first day of the week:
30 4 * * 0 /usr/bin/run-parts /etc/cron.weekly 1> /dev/null
#
# Run monthly cron jobs at 4:20 on the first day of the month:
20 4 1 * * /usr/bin/run-parts /etc/cron.monthly 1> /dev/null
8 9 * * * /usr/local/emhttp/plugins/nvidia-driver/include/update-check.sh &>/dev/null 2>&1
# Job for VM Backup plugin default:
0 3 * * 0 /usr/local/emhttp/plugins/vmbackup/runscript.php run_backup default > /dev/null 2>&1

 

 

root@Tower:~# cat /etc/cron.d/root
# Generated docker monitoring schedule:
10 0 * * 1 /usr/local/emhttp/plugins/dynamix.docker.manager/scripts/dockerupdate check &> /dev/null

# Generated system monitoring schedule:
*/1 * * * * /usr/local/emhttp/plugins/dynamix/scripts/monitor &> /dev/null

# Generated mover schedule:
0 0 1 * * /usr/local/sbin/mover &> /dev/null

# Generated plugins version check schedule:
10 0 * * 1 /usr/local/emhttp/plugins/dynamix.plugin.manager/scripts/plugincheck &> /dev/null

# Generated array status check schedule:
20 0 * * * /usr/local/emhttp/plugins/dynamix/scripts/statuscheck &> /dev/null

# Generated Unraid OS update check schedule:
11 0 1 * * /usr/local/emhttp/plugins/dynamix.plugin.manager/scripts/unraidcheck &> /dev/null

# Generated cron settings for docker autoupdates
0 0 * * * /usr/local/emhttp/plugins/ca.update.applications/scripts/updateDocker.php >/dev/null 2>&1
# Generated cron settings for plugin autoupdates
0 0 * * * /usr/local/emhttp/plugins/ca.update.applications/scripts/updateApplications.php >/dev/null 2>&1

# CRON for CA background scanning of applications
57 * * * * php /usr/local/emhttp/plugins/community.applications/scripts/notices.php > /dev/null 2>&1

# Generated system data collection schedule:
*/1 * * * * /usr/local/emhttp/plugins/dynamix.system.stats/scripts/sa1 1 1 &> /dev/null

# Generated cron schedule for user.scripts
0 9 * * * /usr/local/emhttp/plugins/user.scripts/startCustom.php /boot/config/plugins/user.scripts/scripts/powerdown/script > /dev/null 2>&1

 

tower-diagnostics-20240909-0934.zip

Edited September 10, 20241 yr by Daburgers
more context

 

On 9/10/2024 at 2:29 PM, Daburgers said:

Hi All,

I need help running scripts with custom cron schedule as they don't seem to be running at the schedule I set.

I only have 2 scripts. An antivirus script and a clear drive script. I wanted to schedule the Antivirus script but didn't seem to run at the time i set. However, when I click 'run script', 'run in background', or using the pre-defined schedule (I used 'at stopping of array' for testing) they work without any issue.

I tested again by making a new simple script with a custom cron schedule set:

#!/bin/bash
powerdown

 

I set the cron schedule to:

0 9 * * *     (fyi, It was 8:45am when I set the schedule)
(9am every every day)

I waited a few minutes after 9am but nothing happened (server did not power down) and no log was recorded. I did try at different times as well....9:05am, 11:30am - 5 9 * * * , 30 11 * * * , etc. Also tried every 30 seconds.... 30 * * * *)

However, I was able to run the script when clicking 'run script', 'run in background', or using the pre-defined schedule as tested above and the device powered down accordingly. A log was created as well.

 

I also made sure that the system date and time was also correct. So I am a bit stumped as to why it won't run.

I have attached the unraid logs in case that helps. Also ran the commands below in case that helps - i did see some posts suggest running this and can see the script has been added to it. Would greatly appreciate any help. Please see below:

root@Tower:~# crontab -l
# If you don't want the output of a cron job mailed to you, you have to direct
# any output to /dev/null.  We'll do this here since these jobs should run
# properly on a newly installed system.  If a script fails, run-parts will
# mail a notice to root.
#
# Run the hourly, daily, weekly, and monthly cron jobs.
# Jobs that need different timing may be entered into the crontab as before,
# but most really don't need greater granularity than this.  If the exact
# times of the hourly, daily, weekly, and monthly cron jobs do not suit your
# needs, feel free to adjust them.
#
# Run hourly cron jobs at 47 minutes after the hour:
47 * * * * /usr/bin/run-parts /etc/cron.hourly 1> /dev/null
#
# Run daily cron jobs at 4:40 every day:
40 4 * * * /usr/bin/run-parts /etc/cron.daily 1> /dev/null
#
# Run weekly cron jobs at 4:30 on the first day of the week:
30 4 * * 0 /usr/bin/run-parts /etc/cron.weekly 1> /dev/null
#
# Run monthly cron jobs at 4:20 on the first day of the month:
20 4 1 * * /usr/bin/run-parts /etc/cron.monthly 1> /dev/null
8 9 * * * /usr/local/emhttp/plugins/nvidia-driver/include/update-check.sh &>/dev/null 2>&1
# Job for VM Backup plugin default:
0 3 * * 0 /usr/local/emhttp/plugins/vmbackup/runscript.php run_backup default > /dev/null 2>&1

 

 

root@Tower:~# cat /etc/cron.d/root
# Generated docker monitoring schedule:
10 0 * * 1 /usr/local/emhttp/plugins/dynamix.docker.manager/scripts/dockerupdate check &> /dev/null

# Generated system monitoring schedule:
*/1 * * * * /usr/local/emhttp/plugins/dynamix/scripts/monitor &> /dev/null

# Generated mover schedule:
0 0 1 * * /usr/local/sbin/mover &> /dev/null

# Generated plugins version check schedule:
10 0 * * 1 /usr/local/emhttp/plugins/dynamix.plugin.manager/scripts/plugincheck &> /dev/null

# Generated array status check schedule:
20 0 * * * /usr/local/emhttp/plugins/dynamix/scripts/statuscheck &> /dev/null

# Generated Unraid OS update check schedule:
11 0 1 * * /usr/local/emhttp/plugins/dynamix.plugin.manager/scripts/unraidcheck &> /dev/null

# Generated cron settings for docker autoupdates
0 0 * * * /usr/local/emhttp/plugins/ca.update.applications/scripts/updateDocker.php >/dev/null 2>&1
# Generated cron settings for plugin autoupdates
0 0 * * * /usr/local/emhttp/plugins/ca.update.applications/scripts/updateApplications.php >/dev/null 2>&1

# CRON for CA background scanning of applications
57 * * * * php /usr/local/emhttp/plugins/community.applications/scripts/notices.php > /dev/null 2>&1

# Generated system data collection schedule:
*/1 * * * * /usr/local/emhttp/plugins/dynamix.system.stats/scripts/sa1 1 1 &> /dev/null

# Generated cron schedule for user.scripts
0 9 * * * /usr/local/emhttp/plugins/user.scripts/startCustom.php /boot/config/plugins/user.scripts/scripts/powerdown/script > /dev/null 2>&1

 

tower-diagnostics-20240909-0934.zip 231.44 kB · 0 downloads

Managed to fix the issue:
 

The issue was that the system time in unraid was incorrect - even though I had manually set it correctly.

 

I noticed my server was actually powering down, but not at the right time. So that made me think it had to be my date & time settings. So I checked them again for the 4th time, and this is when I noticed the issue.

 

Although they were set correctly, for some strange reason the "New date & time" at the bottom of the settings was not correct.

 

So I decided to use NTP servers to see if that made any difference....and it did. The time adjusted correctly.

I tested out my script again with a new schedule and BOOM - it worked.

 

Attached is an image of my settings before and after I made the changes in case it helps someone else:

Edited September 14, 20241 yr by Daburgers

I like to have:

1. Support of @reboot in dropdown (it can be stored through the custom field, but after server reboot it is not part of /etc/cron.d/root) (yes, I need it before array start 😉)
2. Store script logs in /var/log/script
3. Make use of logrotate for /var/log/script
4. Optional permanent logs to flash drive (dropdown with hourly/daily/weekly for people not wanting permanent writes, uses rsync --delete to keep in sync with logrotate cleanups)
5. Store executable scripts with their name in /usr/local/bin
6. Optional custom share to edit scripts through SMB. Example:

[user-scripts-plugin]
	  path = /usr/local/bin
	  valid users = <selected-user>
	  read list =
	  write list = <selected-user>
	  force user = root

1.  (should be 7.) if the user kills a background script, you should fire this:

pkill -P <PID_OF_SCRIPT>

By that child commands like rsync or background commands are killed as well.

 

If we're doing suggestions for new features:

 

Allow providing a github URL for a script and an option to auto-update.

 

  

On 8/28/2024 at 11:33 AM, House Of Cards said:

I'm a bit disappointed there are no ideas here.  I've been in a holding pattern for a month with this not working.  I have close to 250 scripts, and I can no longer edit a schedule for them.

 

Spin up Unraid 7.0.0beta2 on a spare USB stick and give it a try.

 

Edited September 22, 20241 yr by Espressomatic

Hi.

 

I have a huge problem with this fantastic plugin.

 

Lately I can't see anything in the  window when running any script. They run, but I can't see anyting until they're done.

 

I have googled and googled, but no findings.

 

Any ideas ?

Let's say I have a schedule to run the script on an hourly basis, but the script itself takes more than an hour to run. Would I have multiple instances of the script running? Or would a subsequent run only execute if the script is not already running? 

50 minutes ago, stevenxl said:

Would I have multiple instances of the script running?

nope, 2nd instance wont start while running

 

and it will not run directly afterwards, it ll start on the next cron event.

 

simple sample, set this script to run every minute

 

#!/bin/bash

sleep 90

echo $(date) >> /tmp/test.txt

 

as you see it ll sleep 90 seconds, so it will only trigger every 2nd minute ...

10 hours ago, alturismo said:

nope, 2nd instance wont start while running

 

and it will not run directly afterwards, it ll start on the next cron event.

 

simple sample, set this script to run every minute

 

#!/bin/bash

sleep 90

echo $(date) >> /tmp/test.txt

 

as you see it ll sleep 90 seconds, so it will only trigger every 2nd minute ...

Thank you. That is awesome!!! 

Hi @Squid, may a hint why user scripts have issues with umlauts when running in background

 

i can run my script from terminal in following situations

 

1/ /mnt/cache/system/mover/mover_openfiles.sh << terminal, script.sh, in foreground

2/ /mnt/cache/system/mover/mover_openfiles.sh & << terminal, script.sh, in background

 

so i added all in a scheduled user script, which works fine

 

3/ /tmp/user.scripts/tmpScripts/show_mover/script << terminal, script, in foreground

4/ /tmp/user.scripts/tmpScripts/show_mover/script << terminal, script, in background

5/ webui RUN SCRIPT << in foreground

 

but ... as soon it runs scheduled or triggered from webui in background, umlaut issue occur ...

 

sample what happens (and crashes the script)

 

sample from Webui Output RUN SCRIPT (foreground) >> working

Script location: /tmp/user.scripts/tmpScripts/show_mover/script
Note that closing this window will abort the execution of this script
open dir on disk1: /mnt/disk1/Media/HDDVDR/Phönix
copy /mnt/disk1/Media/HDDVDR/Phönix/ to /mnt/cache/Media/HDDVDR/Phönix/
...
Sample from scheduled run (or RUN IN BACKGROUND) >> not working as Umlaut distorted

open dir on disk1: /mnt/disk1/Media/HDDVDR/Ph\xc3\xb6nix
move/copy /mnt/disk1/Media/HDDVDR/Ph\xc3\xb6nix/ to /mnt/cache/Media/HDDVDR/Ph\xc3\xb6nix/
sending incremental file list
rsync: [sender] change_dir "/mnt/disk1/Media/HDDVDR/Ph\xc3\xb6nix" failed: No such file or directory (2)
...

so letter "ö" is encoded to "\xc3\xb6"

 

and yes ... im aware about special characters ... but all names (pathes, files) are included in "" and working in way 1 - 5 ...

so this really wonders me and you may have an idea if solveable

 

i assume its related to the php call for scheduled and background jobs ... but i have no idea