search

michealespinola / syno.plexupdate

A script to automagically update Plex Media Server on Synology NAS
GNU General Public License v3.0
273 stars 23 forks source link

User Defined Script entry no longer requires 'bash' #23

Closed liwillbiz closed 2 years ago

liwillbiz commented 2 years ago

It seems that in DSM7 they've automatically assumed you're running a script through bash. So, if you run the copied script 'bash /volume1/homes/admin/scripts/bash/plex/syno.plexupdate/syno.plexupdate.sh' it throws a file not found error as it's basically running 'bash bash /volume1/homes/admin/scripts/bash/plex/syno.plexupdate/syno.plexupdate.sh'

michealespinola commented 2 years ago

Can you tell me where you are seeing this error? I don't see it in my Task Scheduler logs or anywhere else I can think to check.

michealespinola commented 2 years ago

I cannot find any public issues or documentation to support a change in DSM7 to automatically recognize a .sh script's need to be precluded with a call for bash. On my relatively vanilla DS1019+ box, I am unable to run .sh shell script via Task Scheduler or Terminal without specifying the bash interpreter.

Have you made any system customizations or changed the rights to the shell script to be executable?

liwillbiz commented 2 years ago

I was receiving the error in my logs. This is the exact output:

/bin/bash: bash /volume1/homes/name/Scripts/bash/plex/syno.plexupdate.sh: No such file or directory

I haven't made any changes or customizations to my setup either! It's really strange and was a head scratcher for me for a good bit. I wasn't sure why the error was being thrown and kept trying to change the actual path as I thought I was entering it wrong. Only after multiple attempts and more than a bit of frustration did I realize what it was actually saying. I removed the "bash" from the command and now it runs fine!

I really don't know what or why this is happening, but at least logically it seems that they've just implicitly added bash into the command!

michealespinola commented 2 years ago

What is the first line of your syno.plexupdate.sh script? As an example, mine is:

#!/bin/bash
liwillbiz commented 2 years ago

It's the exact same. I have made no changes to the script either, so it's exactly as downloaded.

Bit of a head scratcher!

michealespinola commented 2 years ago

Personally, I would contact Synology about this. I don't believe this is normal behavior.

In the meantime, I'm glad that you were able to work-around it. I run multiple user defined scripts in different languages, and I always have to include the application/interpreter as a part of the 'run command' field entry. I would be very curious to know what Synology support thinks of what you are experiencing. I'll leave this issue open for a bit for visibility and to see if anyone else can share in this experience.

I meant to previously ask: Which version of DSM7 are you running? I believe the latest is 'DSM 7.1-42661 Update 1'

liwillbiz commented 2 years ago

I am running the latest version of DSM, so shouldn't be a versioning issue. I'll contact their support team and see if they have anything to say about it. Not even sure if it's truly a bug or a feature at this point!

michealespinola commented 2 years ago

In this context, maybe, but I wouldn't consider this a feature. The task scheduler is essentially like a terminal on a timer - there should be no assumption or interpretation of how something should be run with whatever interpreter or apps you want to use.

bauzer714 commented 2 years ago

I don't run any of my scripts as suggested in the readme, including this one. I have a handful of scripts executed in the same way.

ReadMe: bash {pathtoscript}.sh

Actual: image

michealespinola commented 2 years ago

The purpose of specifying the interpreter is to make certain that the script is executed as properly and securely as possible. While it's not necessary in some instances, it is a sort of rule of thumb that some admins follow to not allow a direct file association for script execution. By specifying bash in this context, this prevents the task from likely breaking from future security modifications or from possibly running the wrong executable.

OP's problem is a bit different where they are saying that the Synology is inserting an additional bash into the script execution - or at least this is how I am understanding it.

liwillbiz commented 2 years ago

I think we can close this one out. Synology got back to me and says they haven't changed anything on their end. Truthfully have no idea why this is happening, but no harm no foul here :)

michealespinola commented 2 years ago

So, oddly enough, I just had this issue happen to me on DSM7 with a scheduled task calling a bash script. Similar to you, my other scripted task stopped responding to the execution via bash, even though it worked normally still in the terminal via ssh.

Thankfully, rebooting my NAS cleared the issue and the task again worked normally/as-expected. I believe the issue was that in the Synology system environment, it thought the script was already executing. I wish I could specifically recreate it, but at one point I actually saw a message that said that - which is what ultimately prompted me to reboot.

This happened when I was testing a completely different script, but executing it the same way we run syno.plexsupdate. But, since I was testing it, I was running it repeatedly in rather quick succession while making script tweaks. I believe the quick and repeated executions of the task led to the glitch.

Hopefully this anecdote is of some use to you as well.

edit: If the same thing is/was happening to you, a notice that the script is already should be observable in the system logs - logged as an error.