Radarr can not update anymore under DSM 7.1

[synofan]

Is this a new Bug?

• I checkd that the bug hasn't been reported before

Package Name

Radarr

Package Version

4.0.5.5981

Device Model

DS1621+ and virtual DSM 7.1

Device Architecture

x86_64

Firmware Version

7.1

What happened?

Tracelog Radarr DSM 7_1.txt

Access to tmp directory is denied, update fails

Reproduction steps

1. under virtual dsm 7.0 update succesfull
2. under virtual dsm 7.1 update fails
3. this is the same for native DSM 7.1
...

Install Log

not available

Service Log

No response

Other Logs

No response

[synofan]

additional info : update log is not created

[john5du]

Same issues.

[kunude]

you can down this spk files @ https://github.com/SynoCommunity/spksrc/suites/6174998010/artifacts/217575879

[synofan]

Works like a charm THX

[bakerboy448]

The root cause appears to be that /tmp is no longer executable on DSM7.1

the alt tmp dir flag in the package is required, but it appears due to other unrelated breaking changes in the commit that added that flag that package (Oct 2021) is not available for most? All? Users

[BenjV]

What do you mean by no longer executable, /tmp is a folder and is and was never executable.
And if you ment accessible instead of executable, that is also not the case.
On DSM 7.1 the /tmp folder still has 1777 permissions zetting so accessible for everybody.

[bakerboy448]

It's been confirmed by the Radarr Team that synology DSM 7.1 does not allow executing apps/files from /tmp anymore.

The Updater fails to run.

[ta264]

On DSM 7.1 the /tmp folder still has 1777 permissions zetting so accessible for everybody.

Yes, this is true, but DSM won't allow Radarr to execute files downloaded to /tmp. A custom build with an alternative TMPDIR functions correctly. I don't know how DSM is doing this, but it is.

I am working on forking spksrc to produce working *arr packages for v4 and DSM 7.1 - I think it's probably easier to keep it under our control so that we can make the fixes required by .NET upgrades without having to bother you guys every time.

Once I've got something that's working I can work with you guys to upstream my fixes if you're interested.

[hgy59]

@ta264 I can easyly update the radarr package with use of alternate tmp dir (it uses SYNOPKG_PKGTMP i.e. /var/packages/radarr/tmp), but I am not aware whether the package update must prevent to downgrade radarr binaries that might be updated by internal updater (similar to #5181 for syncthing).
Another open issue in #5211 states that all user data is lost on update.

[hgy59]

Created #5252 to finally publish radarr with alternate TMPDIR.

To test:

• validate package update after radarr internal update
• validate content user data (var folder) is not lost on update

[ta264]

Thanks @hgy59

There were some other changes made to the radarr spk around the same time as the TMPDIR fix which broke user data.

In any case it looks like the glibc version on DSM 6 and some DSM 7 archs is too old to support .NET 6 natively. I am working on a chroot-style solution to let us run Radarr inside a debian 10 rootfs. Initial results are promising.

If you're up for assisting it would be great to have your input - most of the development chat is on our discord.

[ta264]

PS the WIP is here: https://github.com/Servarr/spksrc

[hgy59]

In any case it looks like the glibc version on DSM 6 and some DSM 7 archs is too old to support .NET 6 natively. I am working on a chroot-style solution to let us run Radarr inside a debian 10 rootfs. Initial results are promising.

We have already published a .NET 6 runtime package. For DSM 6 the package contains a newer stdlibc++ and patches the dotnet executable to use the library in the package. For DSM 7 (except probably comcerto2k archs) the stdlibc++ of the system is usable by .NET 6.

[ta264]

I don't think the stdlibc++ fix works in my testing on older arm arches any more - this fix was already in the existing Radarr package and stopped working when users update to Radarr v4 (hence all the issues relating to that).

In any case, we don't want to rely on an externally supplied runtime - we publish all our apps as standalone only so that we can control the runtime version in use.

My approach fixes it on comcerto DSM7 so I would expect it works on DSM6 too.

[synofan]

See a new version of Radarr in package Centre, made a backup (lucky me) applied the update from Package Centre, it starts, but no movies with message displayed about faulty language (dont have exact message anymore) decided to remove package (fully) reinstalled looked at system info...ha there is an update, executed the update. This time flawless with a generated update log. restored the backup and voila, works like a charm. THX for all the hard work :-). Big thumbs up.

[synofan]

by the way version seen is v20220510-16 at this moment.

[ta264]

@hgy59 there's some sort of bug in the synocommunity Radarr package where the switch from the old to new style PKGVAR isn't handled properly. I think this is part of the reason the update got pulled last time.

[synofan]

FYI Have to say i had the temporary fix package running https://github.com/SynoCommunity/spksrc/suites/6174998010/artifacts/217575879 so dont know if that was making the problems. Anyhow with a backup and a clean reinstall it works great.

[hgy59]

finally fixed with #5268