_For new Package Requests, see the guidelines_
_Package Name: Sickrage
_Package Version: 20170829-4
_NAS Model: DS413
_NAS Architecture: Freescale QorIQ P1022
_DSM version: DSM 6.1.3-15152 Update 3
Package should start
After succesfully installing, selecting Action -> Run should start the package.
Instead it gives the following error: "Failed to run the package service."
_1._Install package
_2._Run package
_3._
The log is empty ("No data")
I used Sickrage for more than a year now; never had this issue before.
Having the same issue on an 1815+ running DSM 5.2-5644. Updated Sickrage to the latest last night and now the package won't run at all.
@echel0n May you please provide support to diagnose this issue ?
The problem is two folded.
The only solution is to remove the package and install the correct one.
Please use the package Sickbeard Custom to install the correct package.
If you running on DSM 6 you can download a packages I have created that runs on DSM 6 and can be downloaded here and do a manual install.
https://github.com/BenjV/SYNO-packages/blob/master/SickRage%20DSM%206%20noarch%20V1.0.spk
I am in the process of creating a standard package environment for DSM 6 which I will make available to the SynoCommunity so they can use it to make the packages DSM 6 capable.
@BenjV that's not entirely correct
The only __change__ to the package is that it'll check if you installed echel0ns version of SickRage and if you did install the requirements and stuff.
The 2. part was verry important to me because like you said, a lot of people including me don't use ech's SickRage Version but a custom one. For more info see: https://github.com/SynoCommunity/spksrc/pull/2858 also the SickRage Package always defaulted to ech's Repo as i stated here: https://github.com/SynoCommunity/spksrc/pull/2835#issuecomment-317349704 and a couple of times in this issue here: https://github.com/SynoCommunity/spksrc/issues/1989
Regarding DSM 6 Support: There is already a Branch which has DSM 6 support for some Packages here https://github.com/SynoCommunity/spksrc/tree/dsm6 but the Repo Backend need's an update and if i remember correctly there still was something not working as expected. But if you are willing to put some effort in that you're more than welcome :)
EDIT: TL;DR: Most Packages won't run on DSM > 5 as of right now.
We do have a SPK packaged for DSM6 already located at https://git.sickrage.ca/SiCKRAGE/sickrage-synology/raw/dsm6/sickrage.spk
@cytec I can update the sickrage package on the DSM6 branch and submit it for a merge as well if that's ok ?
Just tested and yes if you already have sickrage installed and update to this package then it does not run afterwards however if you uninstall then re-install from community packages it runs fine and this was tested on DSM6+
OK. By the way, for users comfort, if you have clues of a way to implement a seamless upgrade, please try to provide it.
Still not working here.
Running on DS415+, DSM 6.1.3-15152 Update 3
Did a uninstall and re-install, but still won't run.
Ok, with the file from https://git.sickrage.ca/SiCKRAGE/sickrage/wikis/Sickrage-installation-packages it's running.
I'm running now version 9.1.5-1 and get a message there's a new version available 20170829-4
@Birdie68 that's our OFFICIAL custom package created off the DSM5 branch so if that's working the SynoCommunity package should work as well so long as you have GIT installed as well
Just ignore the update message and the package will self-update on its own internally via PIP
@echel0n sure go ahead.
Regarding the upgrade: i think that should be fixed if possible. re-installing will force the user to re-setup everything afterwards which is not really userfriendly :/
@cytec reason the upgrade issue is happening is previous installs where done via PIP completely not just for the requirements and now that I've had to switch to using GIT it broke the upgrade but only when transitioning from the previous PIP install package or from our custom spk I host on my own git server.
Only real way around this will be for me to switch my custom package to use GIT as well and change the versioning scheme to match this ones via using dates instead of majors.minors.patch
OK so I've updated my self-hosted custom SPK to use GIT instead of PIP so that along with it having a newer version value should combat this issue if anyone is to use it down the road.
Same issue here with 20170829-4 on DS713+
What should I do to correct this without loosing everything ? Should I install this https://git.sickrage.ca/SiCKRAGE/sickrage/wikis/Sickrage-installation-packages ?
edit : 20170903-3 not working, same error :(
I tried installing it on a DS416Play with DSM 6.1.3, but package 20170829-4 fails to run. The messages log notes:
```2017/09/30 21:53:42 start sickrage: begin to start version 20170829-4
2017/09/30 21:53:42 start sickrage 20170829-4 Begin pre-load apparmor
2017/09/30 21:53:42 start sickrage 20170829-4 End pre-load apparmor ret=[0]
2017/09/30 21:53:42 start sickrage 20170829-4 Begin start-stop-status start
Starting sickrage ...
su: Permission denied
2017/09/30 21:53:43 start sickrage 20170829-4 End start-stop-status start ret=[1]
2017/09/30 21:53:43 (system) trigger sickrage 20170829-4 Begin start-stop-status stop
sickrage is not running
2017/09/30 21:53:43 (system) trigger sickrage 20170829-4 End start-stop-status stop ret=[0]
2017/09/30 21:53:43 (system) trigger sickrage 20170829-4 Begin unload apparmor
2017/09/30 21:53:43 (system) trigger sickrage 20170829-4 End unload apparmor ret=[0]
2017/09/30 21:53:44 stop sickrage: begin to stop version 20170829-4
2017/09/30 21:53:45 stop sickrage: stop version 20170829-4 successfully, result 0
2017/09/30 21:53:45 start sickrage: start version 20170829-4 failed, result 1
Tried to install the manual version from the wiki (the file at: https://git.sickrage.ca/SiCKRAGE/sickrage-synology/raw/master/sickrage.spk). This is version 20170903-3 and it also failes. Messages log below:
```2017/09/30 21:58:33 install sickrage 20170903-3 Begin preinst
2017/09/30 21:58:33 install sickrage 20170903-3 End preinst ret=[0]
2017/09/30 21:58:33 install sickrage 20170903-3 Begin /bin/mv -f /volume1/@tmp/pkginstall/package /volume1/@appstore/sickrage
2017/09/30 21:58:33 install sickrage 20170903-3 End /bin/mv -f /volume1/@tmp/pkginstall/package /volume1/@appstore/sickrage ret=[0]
2017/09/30 21:58:33 install sickrage 20170903-3 Begin /bin/rm -rf /var/packages/sickrage
2017/09/30 21:58:33 install sickrage 20170903-3 End /bin/rm -rf /var/packages/sickrage ret=[0]
2017/09/30 21:58:34 install sickrage 20170903-3 Begin /bin/mkdir -p /var/packages/sickrage
2017/09/30 21:58:34 install sickrage 20170903-3 End /bin/mkdir -p /var/packages/sickrage ret=[0]
2017/09/30 21:58:34 install sickrage 20170903-3 Begin /bin/mv -f /volume1/@tmp/pkginstall/INFO /var/packages/sickrage/INFO
2017/09/30 21:58:34 install sickrage 20170903-3 End /bin/mv -f /volume1/@tmp/pkginstall/INFO /var/packages/sickrage/INFO ret=[0]
2017/09/30 21:58:34 install sickrage 20170903-3 Begin /bin/rm -rf /var/packages/sickrage/scripts
2017/09/30 21:58:34 install sickrage 20170903-3 End /bin/rm -rf /var/packages/sickrage/scripts ret=[0]
2017/09/30 21:58:34 install sickrage 20170903-3 Begin /bin/mv -f /volume1/@tmp/pkginstall/scripts /var/packages/sickrage/scripts
2017/09/30 21:58:34 install sickrage 20170903-3 End /bin/mv -f /volume1/@tmp/pkginstall/scripts /var/packages/sickrage/scripts ret=[0]
2017/09/30 21:58:34 install sickrage 20170903-3 Begin /bin/rm -rf /var/packages/sickrage/WIZARD_UIFILES
2017/09/30 21:58:34 install sickrage 20170903-3 End /bin/rm -rf /var/packages/sickrage/WIZARD_UIFILES ret=[0]
2017/09/30 21:58:34 install sickrage 20170903-3 Begin /bin/mv -f /volume1/@tmp/pkginstall/WIZARD_UIFILES /var/packages/sickrage/WIZARD_UIFILES
2017/09/30 21:58:34 install sickrage 20170903-3 End /bin/mv -f /volume1/@tmp/pkginstall/WIZARD_UIFILES /var/packages/sickrage/WIZARD_UIFILES ret=[0]
2017/09/30 21:58:34 install sickrage 20170903-3 Begin /bin/rm -rf /var/packages/sickrage/conf
2017/09/30 21:58:34 install sickrage 20170903-3 End /bin/rm -rf /var/packages/sickrage/conf ret=[0]
2017/09/30 21:58:34 install sickrage 20170903-3 Begin /bin/mv -f /volume1/@tmp/pkginstall/conf /var/packages/sickrage/conf
2017/09/30 21:58:34 install sickrage 20170903-3 End /bin/mv -f /volume1/@tmp/pkginstall/conf /var/packages/sickrage/conf ret=[0]
2017/09/30 21:58:34 install sickrage 20170903-3 Begin postinst
2017/09/30 22:00:10 install sickrage 20170903-3 End postinst ret=[0]
2017/09/30 22:00:10 install sickrage 20170903-3 Begin /bin/rm -rf /volume1/@tmp/pkginstall
2017/09/30 22:00:10 install sickrage 20170903-3 End /bin/rm -rf /volume1/@tmp/pkginstall ret=[0]
2017/09/30 22:00:10 install sickrage 20170903-3 successfully
2017/09/30 22:00:11 install sickrage: begin to start version 20170903-3
2017/09/30 22:00:11 install sickrage 20170903-3 Begin pre-load apparmor
2017/09/30 22:00:11 install sickrage 20170903-3 End pre-load apparmor ret=[0]
2017/09/30 22:00:11 install sickrage 20170903-3 Begin start-stop-status start
Starting sickrage ...
su: Permission denied
2017/09/30 22:00:12 install sickrage 20170903-3 End start-stop-status start ret=[1]
2017/09/30 22:00:12 (system) trigger sickrage 20170903-3 Begin start-stop-status stop
sickrage is not running
2017/09/30 22:00:12 (system) trigger sickrage 20170903-3 End start-stop-status stop ret=[0]
2017/09/30 22:00:12 (system) trigger sickrage 20170903-3 Begin unload apparmor
2017/09/30 22:00:12 (system) trigger sickrage 20170903-3 End unload apparmor ret=[0]
2017/09/30 22:00:13 stop sickrage: begin to stop version 20170903-3
2017/09/30 22:00:13 stop sickrage: stop version 20170903-3 successfully, result 0
2017/09/30 22:00:13 install sickrage: start version 20170903-3 failed, result 1
Okay, so I got it running by manually creating the "sickrage" user through the DSM interface and changing the owner on the package folder to that new user. It looks like 'su' fails because the acccount created during package installation is a local Linux user and not a "DSM user". Don't know why, the only difference I could find is that the user created by the package itself isn't in the /etc/shadow file.
can you check and see if there was a existing sickrage user already present ?
what I found is on package removal it never seems to remove the user it creates at least that's what I found for DSM6 when I tried
There was a "sickrage" user, but this is what the package creates when it is installed right? The NAS itself is new. I just got it today, so there was no old stuff in there. Maybe from a few earlier attempts, because I did uninstall and reinstall the package a few times. But looking at the install script it seems to create the user. That's how I figured it needed it.
What I did notice was that the user created by the package was low UID (100), while the one I created through th DSM interface was much higher (10000+) and the package created user had no password setup (which is probably why it wasn't in the shadow file?). I think that is what caused the failure of the 'su' command.
Well the issue I found was because the sickrage user existed on install the package failed to complete the install as it couldn't create the user cause it already existed so by manually removing the user then attempting the install it worked.
Not sure why the user was never removed to start with but if this issue persists I'll add code in to check if the sickrage user does exist and if so skip attempting to re-create the user and continue with the install which should resolve this whole problem.
Feel free to test this out for your self if you wish
I uninstalled sickrage, manually verified there is no sickrage user present. I also made sure no left-overs of the package were there.
Reinstalled the community version -> Fail.
Uninstalled the community version, manual verification of clean-up again.
Reinstalled the manual download version from the sickrage git -> Fail.
So the package installer does have a problem with setting up the sickrage user. I get the same error, "su: persmission denied".
Is there a sickrage group ? think if that's still present it needs to be removed as well
Not as far as I could see in the groups view from the DSM interface, but I didn't manually check. As I never needed to mess with groups to get it working I doubt that's the problem.
But I actually switched to another Sickrage distribution, because I noticed this one doesn't have a Telegram notifier, and that is an absolute must for me.
you would need to manually check for the group I believe.
I'll add in telegram support today for yeah :)
Telegram notification support has been added in
Nice to see you "borrowed" this telegram module from the fork you tried to shutdown on GitHub with a DCMA notice because they did not put your name on some of the code.
You also labeled this module as code of your own.
It always amaze me that see people are using different norms for others as for themselves.
Sickrage version 20180120-39 does not start on synology DS213+ with DSM 6.1.4-15217 Update 5 installed. Git and python updated.
I'll look into it thanks
On Jan 22, 2018 3:00 AM, "exxie" notifications@github.com wrote:
Sickrage version 20180120-39 does not start on synology DS213+ with DSM
6.1.4-15217 Update 5 installed. Git and python updated.—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/SynoCommunity/spksrc/issues/2897#issuecomment-359390512,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABE2VgK0Qxsj50efO1hqQ1nimPyfP8Dlks5tNGo8gaJpZM4PHsvf
.
DSM6 compatible version of the package is expected to be released soon. It can already be installed by downloading it from here #3138.
After the official release on SynoCommunity, the package will auto-update from the official release.
Most helpful comment
Nice to see you "borrowed" this telegram module from the fork you tried to shutdown on GitHub with a DCMA notice because they did not put your name on some of the code.
You also labeled this module as code of your own.
It always amaze me that see people are using different norms for others as for themselves.