Internal updater of Radarr doesn't work to update to 4.x versions

[thyeestes]

Is this a new Bug?

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

Package Name

Radarr

Package Version

20210311-15

Device Model

DS216Play

Device Architecture

ARMv7

Firmware Version

6.2.4-25556 Update 3

What happened?

2022-01-20 03:28:18.9|Info|InstallUpdateService|Deleting old update files
2022-01-20 03:28:19.8|Info|InstallUpdateService|Downloading update 4.0.2.5836
2022-01-20 03:29:06.8|Info|InstallUpdateService|Verifying update package
2022-01-20 03:29:09.3|Info|InstallUpdateService|Update package verified successfully
2022-01-20 03:29:09.3|Info|InstallUpdateService|Extracting Update package
2022-01-20 03:29:37.9|Info|InstallUpdateService|Update package extracted successfully
2022-01-20 03:29:37.9|Info|BackupService|Starting Backup
2022-01-20 03:29:40.7|Info|InstallUpdateService|Preparing client
2022-01-20 03:29:43.9|Info|InstallUpdateService|Starting update client /volume1/@appstore/radarr/tmp/radarr_update/Radarr.Update
2022-01-20 03:29:43.9|Info|InstallUpdateService|Radarr will restart shortly.

Neither debug or trace log show additional information not errors

Reproduction steps

1.Open Radarr
2. Go to System - Updates - Install latest
3. Update starts but always ends with Radarr will restart shortly which it never does.

I tried resizing /tmp as suggested in https://github.com/SynoCommunity/spksrc/issues/4621

Install Log

Sun Nov 28 12:31:13 CET 2021
===> Step preinst. USER=radarr GROUP=sc-download SHARE_PATH=
Sun Nov 28 12:31:20 CET 2021
===> Step postinst. USER=radarr GROUP=sc-download SHARE_PATH=
Installing service configuration /var/packages/radarr/conf/radarr.sc
Adding 'sc-radarr' to 'sc-download'
Group Name: [sc-download]
Group Type: [AUTH_LOCAL]
Group ID:   [65536]
Group Members: 
0:[plex]
1:[sc-medusa]
2:[sc-nzbget]
3:[thyestes]
4:[sc-radarr]
Invoke service_postinst
Granting 'sc-radarr' unix ownership on /volume1/@appstore/radarr/var/.config

Service Log

2022-01-20 03:28:18.9|Info|InstallUpdateService|Deleting old update files
2022-01-20 03:28:19.8|Info|InstallUpdateService|Downloading update 4.0.2.5836
2022-01-20 03:29:06.8|Info|InstallUpdateService|Verifying update package
2022-01-20 03:29:09.3|Info|InstallUpdateService|Update package verified successfully
2022-01-20 03:29:09.3|Info|InstallUpdateService|Extracting Update package
2022-01-20 03:29:37.9|Info|InstallUpdateService|Update package extracted successfully
2022-01-20 03:29:37.9|Info|BackupService|Starting Backup
2022-01-20 03:29:40.7|Info|InstallUpdateService|Preparing client
2022-01-20 03:29:43.9|Info|InstallUpdateService|Starting update client /volume1/@appstore/radarr/tmp/radarr_update/Radarr.Update
2022-01-20 03:29:43.9|Info|InstallUpdateService|Radarr will restart shortly.

Other Logs

No response

[BenjV]

As you said in the title, this is an internal update, so you have to ask this on the Radarr developers not the SynoCommunity.

[thyeestes]

Hi BenjV, that depends. The previous issue with the internal updater of ARR applications were related the Syno packages, e.g. /tmp folder being to small. I don't have the expertise to investigate or assess the issue, that's why I reported it here, looking for help.

[BenjV]

I don't know what the issue was but an application should never write substantial amount of data to a /tmp folder because a /tmp folder is for the OS not for applications.
Secondly a /tmp folder being to small could never be fixed by the SynoCommunity, because when a /tmp folder is to small the system partition of DSM is full and that could only be fixed by Synology.

And if a package update was not possible because the system partition was full even then that could never be fixed by the SynoCommunity.

Besides all that, version 4 of Radarr is "as far as I know" only in development and not yet released and there is no SynoCommunity package for that version.

[bakerboy448]

I don't know what the issue was but an application should never write substantial amount of data to a /tmp folder because a /tmp folder is for the OS not for applications.

• The update tarball is ~100mb
• Extracted it is ~200mb
• Radarr also backups the existing binaries in case a rollback is needed
• Thus +- ~500mb is required
• Certain synology NASes do not have a /tmp that can facilitate that

Secondly a /tmp folder being to small could never be fixed by the SynoCommunity, because when a /tmp folder is to small the system partition of DSM is full and that could only be fixed by Synology.

• It was. Certain Synology's have a tmp folder that was too small; so an alt temp directory was used 5a174ae

And if a package update was not possible because the system partition was full even then that could never be fixed by the SynoCommunity.

• see above

Besides all that, version 4 of Radarr is "as far as I know" only in development and not yet released and there is no SynoCommunity package for that version.

v4 of Radarr is in develop (beta) and will be coming to master (stable) "soon"(tm)

If the SynoCommunity wishes to not have Radarr internally update then they should disable the updater using the package_info.

---

@thyeestes

• This is highly likely to be a Synology specific issue & not a Radarr issue nor Radarr bug.
• Check the Updater Log - https://wiki.servarr.com/radarr/troubleshooting#update-logs-location it'll tell you why the updater failed

[BenjV]

@bakerboy448
You don't seem to grasp what a Synology package is and what can be done with it.
Package is only a wrapper around an existing application to be able to install it on a Synology Nas.
Changing anything within those application is not possible, so preventing the internal update to function can only be done by the Radarr developers and not by the Synocommunity.

And backing up the binaries by Radarr should never be a problem unless they back it up to a /tmp and that can also only be fixed by the Radarr developers (unless they use something like and environment var or a commandline var to backup to)

So you are barking to the wrong tree.

[bakerboy448]

Changing anything within those application is not possible, so preventing the internal update to function can only be done by the Radarr developers and not by the Synocommunity.

this is incorrect. The *Arrs all have a method available for package maintainers to block internal updating with package_info. The SynoCommunity can add to package_info file and set the updater to external and which stops internal updating. However, given the lack of resources to keep Radarr up to date and based on last year's updates - that would mean users would be on old versions for the better part of half a year due to SynoComm's extremely limited resources. I think it was several months last year to take users from 3.0.2 to 3.2.2 - and about 4 months 3.2.2 was released before it was on SynoCommunity

And backing up the binaries by Radarr should never be a problem unless they back it up to a /tmp and that can also only be fixed by the Radarr developers (unless they use something like and environment var or a commandline var to backup to)

/tmp is used

/tmp will not be changed App side.

I have no idea what you're rambling about though because SynoCommunity has already changed the Package to use a different TMP directory in the commit I linked. Are you saying that change should be reverted to then intentionally break installations for SynoComm's user base? That seems - to be blunt - idiotic to intentionally regress functionality in production environments.

Based on your comments and logic - all of these apps need the alt temp directory bool removed and it's all the fault of the app developers - who do not create the Synology Packages - to not use /tmp for anything? That doesn't make much sense.

https://github.com/SynoCommunity/spksrc/search?q=USE_ALTERNATE_TMPDIR&type=

@BenjV in other words you think @hgy59 alt tmp dir commits need to all be reverted?

[BenjV]

The use USE_ALTERNATE_TMPDIR has nothing to do with this..
That USE_ALTERNATE_TMPDIR is only for packages when upgrading a package via the package center to store for example data from the application during upgrading, not for upgrading from within an application, the package has no control at all over such upgrading.
And in the scripts of the Radarr package there is no reference to it other then a definition of it, but no use of it at all.
So you conclusion is simply wrong.

And why would the SynoCommunity wants to block the internal update of an application, as long as the end user understand that users cannot expect support from the SynoCommunity for such an upgrade any user can do what he wish.

[bakerboy448]

@BenjV I don't see the point in further discussion. You fail to read the commits and linked issues that added that bool which causes the package to not use /tmp for both package installation and application runtime.

You clearly have no idea what you're talking about and think you have more knowledge than the SynoComm developers.

Based on your statements then the previously linked commit would have not fixed the issue of Radarr's internal updater failing due to /tmp being out of space and yet reality directly contradicts your statements.

This is directly from the code on Git

# USE_ALTERNATE_TMPDIR (optional) with USE_ALTERNATE_TMPDIR=1 TMD_DIR is defined to use a package specific temp
# folder at intallation and runtime.

[BenjV]

If you say so.

[AnonTester]

Hi all.

I doubt this has anything to do with the tmp folder - at least not any more.

Radarr updated happily on my system up until version 4.0.0.5503, at some version afterwards something changed and both the updater exe itself as well as the radarr exe segfault when started.

The internal updater downloads the update, backs up everything, then tries to apply it, but then segfaults and doesn't complete. I tried copying the files into the main radarr directory, but it segfaults as well. This is on a Synology DS414 with ArmadaXP cpu.
The same is happening with the Prowlarr package.

I'm happy to provide further details if someone can tell me where to find or how to create any core dumps or further logs to figure out what's going wrong.

[bakerboy448]

Synology DS414 with ArmadaXP

Known dotnet bug with your processor
dotnet/runtime#56706

There is no solution. The package should be updated to indicate that processor is not supported if possible

[gingerbeardman]

Just run the develop branch to get v4.

Radarr > Settings > General > Show Advanced (toolbar) > Updates > Branch > develop

[bakerboy448]

Just run the develop branch to get v4.

Radarr > Settings > General > Show Advanced (toolbar) > Updates > Branch > develop

Not needed at all. V4 is on master.

Develop should only be used by beta testers.

This issue is the SynoCommunity Package falsely claims the NAS is supported, but the NAS Hardware is not compatible with dotnet.

[bakerboy448]

beta servarr packages may or may not work for users of this nas

https://wiki.servarr.com/synology-packages

[gingerbeardman]

Not needed at all. V4 is on master.

It was the only way I could get to V4.

YMMV, as they say

[bakerboy448]

Again, v4 has been on master. Develop should only be used for users who wish to be in the beta branch.

[gingerbeardman]

Indeed, I did move to Master when V4 became available on it.

[mreid-tt]

@thyeestes, one of the major changes in the update to Radarr 4.x was the "Upgrade to .NET 6" in v4.0.0.5745. Based on this #5574 (comment), "Glibc on dsm6 for that arch is too old for .net 6". This is the challenge I was exploring in #5574 -- ARMv7 archs running dotNET 6 core apps. Based on the feedback thus far, this is the likely reason you are unable to update to Radarr 4.x on a monaco arch.

Now there are a few options you may consider...

1. If you are willing to consider upgrading to DSM7, some users have indicated that their *arr apps which include dotNET 6 seem to function under the newer DSM version. If you have already done this, please leave me some feedback
2. If you are unable to move from DSM6, the folks over at Servarr have released some packages which can be manually installed on older CPUs. These packages include a special wrapper that contains "new enough system libraries" to work with dotNET 6

[gingerbeardman]

FWIW I'm running V4 on DSM6, see earlier in the thread to see how I arrived at this.

• Radarr 4.3.2.6857
• Package x64-6.1_20220515-18 by Team Radarr
• .NET 6.0.8

"If it ain't broke don't fix it" is my philosophy, so I won't be changing this setup.

[mreid-tt]

@gingerbeardman, thanks for sharing. Yes, Radarr v4 can run on DSM6 but not on ARMv7 archs. You have an x64 arch based on your package name so you should have no issues with the current dotNET 6.x builds.

[gingerbeardman]

Ah, there we go! I missed that. Cheers

[mastervol]

I can confirm that the internal updater does also not work on DSM7, the application radarr works.
I know this issue entry is focused on DSM6 by op.

However if I install the latest known version from synocommunity a manual update works (overwriting old files).
Therefore I created a script to take care of the update procedure in the meantime (in radarr settings: Updates/Scrip path).

DSM-Version: DSM 7.1.1-42962 Update 1
Model name: DS216play
CPU: STM Monaco STiH412

What is currently shown in Radarr:
Version
4.3.2.6857
Package Version
armv7-7.0_20220515-18 by [Team Radarr](https://radarr.video/)
.NET
Yes (6.0.8)
DB Migration
214
Database
Sqlite 3.34.1
AppData directory
/volume1/@appdata/radarr/.config/Radarr
Startup directory
/volume1/@appstore/radarr/share/Radarr/bin
Mode
Console
Uptime

[mreid-tt]

I can confirm that the internal updater does also not work on DSM7

@mastervol, thanks so much for your feedback. This does seem to conflict a bit with my expectations for running dotNET 6 core apps on monaco. Can you elaborate on what happens in your service log or in the application log?

DSM-Version: DSM 7.1.1-42962 Update 1
Model name: DS216play
CPU: STM Monaco STiH412

Separate from this, if you are willing, I don't have any direct testing with your platform for clean installs of dotNET 6 packages. It would be very much appreciated if you can take a look at the ARMv7 test packages (labelled (DSM7) armv7-7.1 in #5574) and leaving a comment with your findings.

EDIT: Thanks for confirming that the internal updater does in fact work on your platform (#5574 (comment)).

[thyeestes]

@thyeestes, one of the major changes in the update to Radarr 4.x was the "Upgrade to .NET 6" in v4.0.0.5745. Based on this #5574 (comment), "Glibc on dsm6 for that arch is too old for .net 6". This is the challenge I was exploring in #5574 -- ARMv7 archs running dotNET 6 core apps. Based on the feedback thus far, this is the likely reason you are unable to update to Radarr 4.x on a monaco arch.

Now there are a few options you may consider...

1. If you are willing to consider upgrading to DSM7, some users have indicated that their `*arr` apps which include dotNET 6 seem to function under the newer DSM version. If you have already done this, please leave me some feedback

2. If you are unable to move from DSM6, the folks over at [Servarr](https://github.com/Servarr) have released some [packages](https://github.com/Servarr/spksrc/releases) which can be manually installed on older CPUs. These packages include a special wrapper that contains "_new enough system libraries_" to work with dotNET 6

Thanks. I've sold my NAS, so I'm no longer able to test or verify.

[mreid-tt]

Thanks. I've sold my NAS, so I'm no longer able to test or verify.

Thanks for the update, if no longer needed, please close the issue.