May 27, 20242 yr 1 hour ago, Joly0 said: the commands just keep running forever yes, you open a subprozess (&) - That runing outside from main prozess. #!/bin/bash # Variables CONTAINER_NAME="LANCache-Prefill" # Function to clean up child processes cleanup() { echo "Cleaning up..." # Kill all child processes of the current process group pkill -TERM -P $$ exit 1 } # Trap termination signals to trigger cleanup trap cleanup SIGINT SIGTERM # Execute commands in Docker container sequentially execute_command() { docker exec -u prefill $CONTAINER_NAME /bin/bash -c "cd /lancacheprefill && $1" & PID=$! wait $PID } # Start each prefill command execute_command "./SteamPrefill/SteamPrefill prefill --force" execute_command "./EpicPrefill/EpicPrefill prefill --force" execute_command "./BattleNetPrefill/BattleNetPrefill prefill --force" # Clean up if the script finishes normally cleanup You can try this, this should open a process with three sub-processes. If you kill the main process, the sub-processes should also be killed.. Greetings Edited May 27, 20242 yr by Amane
May 27, 20242 yr 23 minutes ago, Amane said: yes, you open a subprozess (&) - That runing outside from main prozess. #!/bin/bash # Variables CONTAINER_NAME="LANCache-Prefill" # Function to clean up child processes cleanup() { echo "Cleaning up..." # Kill all child processes of the current process group pkill -TERM -P $$ exit 1 } # Trap termination signals to trigger cleanup trap cleanup SIGINT SIGTERM # Execute commands in Docker container sequentially execute_command() { docker exec -u prefill $CONTAINER_NAME /bin/bash -c "cd /lancacheprefill && $1" & PID=$! wait $PID } # Start each prefill command execute_command "./SteamPrefill/SteamPrefill prefill --force" execute_command "./EpicPrefill/EpicPrefill prefill --force" execute_command "./BattleNetPrefill/BattleNetPrefill prefill --force" # Clean up if the script finishes normally cleanup You can try this, this should open a process with three sub-processes. If you kill the main process, the sub-processes should also be killed.. Greetings Hey, thanks for the recommendation. I thought so aswell and tried that already, but as you can see in the screenshot, it doesnt work. If i abort the script, the command in the container is still bein executed:
May 27, 20242 yr AFAIK docker exec will just start the command you specified in the container and exit, it does not return the PID of the process it launched as the host sees it or keep track of what it executed. You'd have to do a 'docker exec [container] [find process and kill it]' Edited May 27, 20242 yr by Kilrah
May 27, 20242 yr 6 hours ago, idean said: But I'd still like to know why background processes can't access it directly? The issue is likely due to different environment contexts for foreground and background scripts. Can you see any differences in "printenv" when you run the script manually/foreground or automatically/background? #!/bin/bash # Execute the script in the background and foreground, then you will see the output and can check the differences. (e.q. $HOME) printenv # But if you set the path absolut and manually, you should have no problems: # Path for rclone.conf RCLONE_CONFIG_PATH=/root/.config/rclone/rclone.conf echo $(rclone config file --config $RCLONE_CONFIG_PATH) export RESTIC_PASSWORD=ABEAUTIFULPASSWORD export RESTIC_REPOSITORY=rclone:storj:SERVER/LOCATION echo "Starting backup..." restic backup --exclude-file=/boot/config/plugins/user.scripts/scripts/backup_data/excludes.txt --option rclone.program="rclone --config $RCLONE_CONFIG_PATH" restic forget --keep-last 2 --prune --option rclone.program="rclone --config $RCLONE_CONFIG_PATH" echo "Backup finished successfully" Does the absolute path work? Greetings Edited May 27, 20242 yr by Amane
May 27, 20242 yr 7 hours ago, sjtuross said: I think the best trigger of both scripts is docker_started. I think this event would be useful to all others and it could be much easier to set up with this event in user scripts add-on if possible. I hope I understand correctly that you are looking for a trigger when a certain container is started, or docker itself? You can have the script check if a certain container is running, and if so, continue? #!/bin/bash # Container name CONTAINER="container_name_to_check" # Check if the container is running if ! docker ps --format '{{.Names}}' | grep -q "^${CONTAINER}$"; then echo "Container $CONTAINER is not running. Exiting script." exit 1 else echo "Container $CONTAINER is running. Continue.." fi # Your script here.. Greetings Edited May 27, 20242 yr by Amane
May 27, 20242 yr 4 hours ago, Joly0 said: I thought so aswell and tried that you can try this for running the prefill commands parallel : #!/bin/bash # Variables CONTAINER_NAME="LANCache-Prefill" # Function to clean up child processes cleanup() { echo "Cleaning up..." # Kill all child processes of the current process group pkill -TERM -P $$ exit 0 } # Trap termination signals to trigger cleanup trap cleanup SIGINT SIGTERM # Execute commands in Docker container execute_command() { docker exec -u prefill $CONTAINER_NAME /bin/bash -c "cd /lancacheprefill && $1" & } # Start each prefill command in parallel execute_command "./SteamPrefill/SteamPrefill prefill --force" execute_command "./EpicPrefill/EpicPrefill prefill --force" execute_command "./BattleNetPrefill/BattleNetPrefill prefill --force" # Wait for all background processes to finish wait # Clean up if the script finishes normally cleanup try both and check the performence with the LANCache.-Prefill ..
May 28, 20242 yr 17 hours ago, Amane said: I hope I understand correctly that you are looking for a trigger when a certain container is started, or docker itself? You can have the script check if a certain container is running, and if so, continue? No, actually the trigger I need is when docker daemon is started. A workaround solution was provided in the post below. I'm just thinking it would be useful to more users if this docker_started event is supported by user scripts add-on. . I
June 4, 20242 yr 35 minutes ago, ChaOS125 said: Scheduled "daily" You can set this in the Unraid webUI at Settings - Scheduler - Fixed Schedules.
June 4, 20242 yr 1 hour ago, ChaOS125 said: What does it mean on Scheduled "daily" does it mean it happens at 0:01? I think so, i will test but i thik its (0 0 * * *)
June 6, 20242 yr Hi, i tried running one of the default scripts to remove dangling images and received the following error: NoteError response from daemon: conflict: unable to delete 4acdeafdf597 (cannot be forced) - image is being used by running container 4f1978a0b6d1 Is this an error that can be ignored? Thanks
June 8, 20242 yr On 6/4/2024 at 4:30 PM, ChaOS125 said: What does it mean on Scheduled "daily" does it mean it happens at 0:01? On my system, the term “daily” is at 4:40 AM Sat Jun 8 04:40:01 CEST 2024 Script Finished Jun 08, 2024 04:40.01 On 6/4/2024 at 5:07 PM, trurl said: You can set this in the Unraid webUI at Settings - Scheduler - Fixed Schedules. The scheduler is for: Parity Check Mover TRIM (I didn't have more settings) Edited June 8, 20242 yr by Amane
June 9, 20242 yr @AmaneI really think something is bugged with the "Run in background" option. I have another very simple script that looks like this: #!/bin/bash # Define the target folder for the files target_folder="/mnt/user/filme" # Define the desired owner of the copied files desired_owner="99" # Add the paths to the files to be copied here file_paths=( ) rsync -zvvP --bwlimit=300 --partial-dir="$target_folder/.rsync-partial" --chown="$desired_owner" "${file_paths[@]}" "$target_folder" And when i run that in background and abort it, the rsync process just keeps running. So how am i supposed to stop it then?
June 9, 20242 yr 4 hours ago, Joly0 said: I really think something is bugged with the "Run in background" option. Yes, I can confirm that. My script which "normalizes" all rights with "xargs" also continues to run in the background if i abort it. But I think it's normal that the current subprocess is not canceled, it just doesn't start a new one if you abort it. Edited June 9, 20242 yr by Amane
June 9, 20242 yr 4 hours ago, Amane said: Yes, I can confirm that. My script which "normalizes" all rights with "xargs" also continues to run in the background if i abort it. But I think it's normal that the current subprocess is not canceled, it just doesn't start a new one if you abort it. Yes, but this cant be intended behaviour. Why would you want to abort a background script, just for the processes in the background to keep running. Imo this doesnt make much sense. But maybe @Squidcan give his opinion on this and maybe clarify it.
June 9, 20242 yr It really isn't as simple as you would wish. I'll let Squid give the more technical input, but I'll offer you a way to view this issue. Think of the script as job with a list of commands that are running sequentially in some order. When you abort the script, you stop this job, and no further commands from the script are executed. The difficult issue is stopping the command that is executing when you abort the script. The command could be almost anything. How do you wish the command to be stopped? In a controlled manner, or just kill the process? If the process is killed, will it leave the system in an undefined or unstable condition? I can see a lot of fuzzy decisions here, each dependent on just what command is running at the time the script is aborted.
June 9, 20242 yr 7 minutes ago, ConnerVT said: It really isn't as simple as you would wish. I'll let Squid give the more technical input, but I'll offer you a way to view this issue. Think of the script as job with a list of commands that are running sequentially in some order. When you abort the script, you stop this job, and no further commands from the script are executed. The difficult issue is stopping the command that is executing when you abort the script. The command could be almost anything. How do you wish the command to be stopped? In a controlled manner, or just kill the process? If the process is killed, will it leave the system in an undefined or unstable condition? I can see a lot of fuzzy decisions here, each dependent on just what command is running at the time the script is aborted. I mean, that makes kinda sense, but why doesnt userr scripts "simply" run the scripts itself? Wouldnt that make more sense? Aborting would then send a sigterm/sigkill/whatever signal to the script, which the script could handle. Imo that would make way more sense, atleast imo
June 9, 20242 yr I mean, if you run a script in foreground, you can close/stop it and the processes stop aswell and i would think that if you run it in background and you abort it, the same would happen. Atleast from searching this topic for this "issue" others seem to think the same. Abort should stop the script and the execution of any processes
June 9, 20242 yr Author 7 minutes ago, Joly0 said: I mean, if you run a script in foreground, you can close/stop it and the processes stop aswell and i would think that if you run it in background and you abort it, the same would happen. Atleast from searching this topic for this "issue" others seem to think the same. Abort should stop the script and the execution of any processes Basically what @ConnerVT said, but a key difference between the foreground and the background is that the entire "shell" on the foreground stops which closes down everything, but when in the background there is no "shell" so it's a pita to find and close down sub processes.
June 9, 20242 yr 11 minutes ago, Squid said: Basically what @ConnerVT said, but a key difference between the foreground and the background is that the entire "shell" on the foreground stops which closes down everything, but when in the background there is no "shell" so it's a pita to find and close down sub processes. Thanks for the answer. Imo it makes sense, how its done atm according to your explanation, but i (and probably others) still think, that the script should be run as is and let the user implement their ways of signal handling using trap and such things. That would make that feature easier to understand and use in my opinion. I am not sure if most people know, that if you abort a background script, the script actually doesnt really "abort". Ofc changing that would be quite a hassle, but it makes the feature quite hard to use manually, when you have to run a long lasting command and want to interrupt it if needed.
June 16, 20242 yr Hey @Squid! Back in the world of Unraid after years and already tinkering with Command line and your plugin looks great ! Thanks for providing it. I had a feature idea for this plugin, but looking in this thread and nobody asked since 2016 kind of makes me scared to ask 😁 Do you think it would be possible to add a "duplicate" button ? I understand we could open the script, copy the content, create new and paste into it is quite straight forward, but still, would be great. Just weight in time vs reward and let me know what you think Cheers Edited June 16, 20242 yr by PerniciousDuck Spelling
June 17, 20242 yr On 5/27/2024 at 1:30 PM, Joly0 said: Hey, thanks for the recommendation. I thought so aswell and tried that already, but as you can see in the screenshot, it doesnt work. If i abort the script, the command in the container is still bein executed: Hey, I'm a little late to this conversation, but I would recommend against running the three prefills in parallel. Each one can open up to 30 concurrent requests to download from the internet which can cause some serious contention on your network and seriously degrade overall performance. I'm curious as to what reason you're trying to run these in parallel. Also have you seen ich777's container for exactly this?
July 5, 20242 yr /boot/config/plugins/user.scripts/scripts/setting/script Does anyone know if this user.scripts is normal? Is it part of the plugin, or has it been modified by someone? Here’s the situation: I discovered a mining program running on my Unraid, and upon checking the logs, I found that someone had logged into my Unraid and modified the SSH keys. Finally, I found a script in user.scripts that downloads xmrig. What I want to know is the sequence of events: did someone log into my Unraid and modify my user.scripts script to download xmrig, or does the user.scripts plugin come with a script to download xmrig, and then someone logged into my Unraid?
July 5, 20242 yr 25 minutes ago, bedivereyang said: /boot/config/plugins/user.scripts/scripts/setting/script Does anyone know if this user.scripts is normal? Is it part of the plugin, or has it been modified by someone? Here’s the situation: I discovered a mining program running on my Unraid, and upon checking the logs, I found that someone had logged into my Unraid and modified the SSH keys. Finally, I found a script in user.scripts that downloads xmrig. What I want to know is the sequence of events: did someone log into my Unraid and modify my user.scripts script to download xmrig, or does the user.scripts plugin come with a script to download xmrig, and then someone logged into my Unraid? IIRC the plugin doesn’t come with any scripts added. Just some examples that you can add.
July 5, 20242 yr 30 minutes ago, bedivereyang said: someone had logged into my Unraid Is your server on the internet?
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.