search

MichaIng / DietPi

Lightweight justice for your single-board computer!
https://dietpi.com/
GNU General Public License v2.0
4.9k stars 499 forks source link

Radarr update fails the second time #7251

Open Arghh opened 1 month ago

Arghh commented 1 month ago

After updating Radarr over the Web-UI to latest version (from 5.11.0.9244 to 5.12.2.9335 Radarr stopped working.

After reinstalling with: dietpi-software reinstall 145 the problem still exist.

I uninstalled radarr over dietpi-software menu and installed it again over the same menu. Now it works.

Reporting this issue because this seems to happen now every time radarr has an update.

Service error: [FAILED] DietPi-Services | × radarr.service - Radarr (DietPi) Loaded: loaded (/etc/systemd/system/radarr.service; enabled; preset: enabled) Active: failed (Result: exit-code) since Sat 2024-10-19 14:03:56 CEST; 6min ago Duration: 182ms Process: 28742 ExecStart=/opt/radarr/Radarr -nobrowser -data=/mnt/dietpi_userdata/radarr (code=exited, status=154) Main PID: 28742 (code=exited, status=154) CPU: 538ms

In journal I see: Oct 19 14:03:56 DietPi4 systemd[1]: Failed to start radarr.service - Radarr (DietPi). Oct 19 14:11:47 DietPi4 systemd[1]: Started radarr.service - Radarr (DietPi). Oct 19 14:11:47 DietPi4 Radarr[30499]: The application to execute does not exist: '/opt/radarr/Radarr.dll'. Oct 19 14:11:47 DietPi4 systemd[1]: radarr.service: Main process exited, code=exited, status=154/n/a

Update log: Oct 19 14:03:49 DietPi4 Radarr[9168]: [Error] CommandExecutor: Error occurred while executing task ApplicationUpdate Oct 19 14:03:49 DietPi4 Radarr[9168]: [v5.11.0.9244] System.IO.IOException: Directory not empty : '/tmp/radarr_update/' Oct 19 14:03:49 DietPi4 Radarr[9168]: at System.IO.FileSystem.RemoveDirectoryInternal(DirectoryInfo directory, Boolean recursive, Boolean throwOnTopLevelDirectoryNotFound) Oct 19 14:03:49 DietPi4 Radarr[9168]: at System.IO.FileSystem.RemoveDirectory(String fullPath, Boolean recursive) Oct 19 14:03:49 DietPi4 Radarr[9168]: at System.IO.Directory.Delete(String path, Boolean recursive) Oct 19 14:03:49 DietPi4 Radarr[9168]: at NzbDrone.Common.Disk.DiskProviderBase.DeleteFolder(String path, Boolean recursive) in ./Radarr.Common/Disk/DiskProviderBase.cs:line 304 Oct 19 14:03:49 DietPi4 Radarr[9168]: at NzbDrone.Core.Update.InstallUpdateService.InstallUpdate(UpdatePackage updatePackage) in ./Radarr.Core/Update/InstallUpdateService.cs:line 121 Oct 19 14:03:49 DietPi4 Radarr[9168]: at NzbDrone.Core.Update.InstallUpdateService.Execute(ApplicationUpdateCommand message) in ./Radarr.Core/Update/InstallUpdateService.cs:line 289 Oct 19 14:03:49 DietPi4 Radarr[9168]: at NzbDrone.Core.Messaging.Commands.CommandExecutor.ExecuteCommand[TCommand](TCommand command, CommandModel commandModel) in ./Radarr.Core/Messaging/Commands/CommandEx> Oct 19 14:03:49 DietPi4 Radarr[9168]: at CallSite.Target(Closure , CallSite , CommandExecutor , Object , CommandModel ) Oct 19 14:03:49 DietPi4 Radarr[9168]: at System.Dynamic.UpdateDelegates.UpdateAndExecuteVoid3[T0,T1,T2](CallSite site, T0 arg0, T1 arg1, T2 arg2) Oct 19 14:03:49 DietPi4 Radarr[9168]: at CallSite.Target(Closure , CallSite , CommandExecutor , Object , CommandModel ) Oct 19 14:03:49 DietPi4 Radarr[9168]: at NzbDrone.Core.Messaging.Commands.CommandExecutor.ExecuteCommands() in ./Radarr.Core/Messaging/Commands/CommandExecutor.cs:line 44 Oct 19 14:03:53 DietPi4 systemd[1]: radarr.service: Main process exited, code=killed, status=9/KILL Oct 19 14:03:53 DietPi4 systemd[1]: radarr.service: Failed with result 'signal'. Oct 19 14:03:53 DietPi4 systemd[1]: radarr.service: Unit process 28684 (Radarr.Update) remains running after unit stopped. Oct 19 14:03:53 DietPi4 systemd[1]: radarr.service: Consumed 1h 1min 48.364s CPU time. Oct 19 14:03:54 DietPi4 systemd[1]: radarr.service: Scheduled restart job, restart counter is at 1. Oct 19 14:03:54 DietPi4 systemd[1]: Stopped radarr.service - Radarr (DietPi). Oct 19 14:03:54 DietPi4 systemd[1]: radarr.service: Consumed 1h 1min 48.595s CPU time. Oct 19 14:03:54 DietPi4 systemd[1]: radarr.service: Found left-over process 28684 (Radarr.Update) in control group while starting unit. Ignoring. Oct 19 14:03:54 DietPi4 systemd[1]: This usually indicates unclean termination of a previous run, or service implementation deficiencies. Oct 19 14:03:54 DietPi4 systemd[1]: Started radarr.service - Radarr (DietPi). Oct 19 14:03:54 DietPi4 Radarr[28738]: The application to execute does not exist: '/opt/radarr/Radarr.dll'. Oct 19 14:03:54 DietPi4 systemd[1]: radarr.service: Main process exited, code=exited, status=154/n/a Oct 19 14:03:54 DietPi4 systemd[1]: radarr.service: Failed with result 'exit-code'. Oct 19 14:03:54 DietPi4 systemd[1]: radarr.service: Unit process 28684 (Radarr.Update) remains running after unit stopped. Oct 19 14:03:54 DietPi4 systemd[1]: radarr.service: Scheduled restart job, restart counter is at 2. Oct 19 14:03:54 DietPi4 systemd[1]: Stopped radarr.service - Radarr (DietPi). Oct 19 14:03:54 DietPi4 systemd[1]: radarr.service: Found left-over process 28684 (Radarr.Update) in control group while starting unit. Ignoring. Oct 19 14:03:54 DietPi4 systemd[1]: This usually indicates unclean termination of a previous run, or service implementation deficiencies. Oct 19 14:03:54 DietPi4 systemd[1]: Started radarr.service - Radarr (DietPi).

Required Information

Additional Information (if applicable)

Expected behaviour

Radarr should update without problems.

MichaIng commented 3 weeks ago

Thanks for your report. There was a similar case sone week ago. The update seems to abort in the middle. Maybe this can happen if memory or /tmp is full. I'll they to replicate.

Arghh commented 3 weeks ago

Thank you. I also think I could start the Update twice over the UI. Start it and than after about 30 seconds start it again. Maybe that is something. But my main problem is the broken state this leaves the software. Reinstall should fix this or not?

MichaIng commented 3 weeks ago

Yeah, we implemented the reinstall conservatively, not touching an existing install, but only install dependencies, service file and stuff around, printing a hint to use the web UI updater instead. That message also gives that hint to remove /opt/radarr manually for a repair. But that conservative approach causes more issues than it solves, as the web UI updater does not thing else when what we would do, all migration steps are done afterwards on first start with new executables. And the message is easily overseen by the wall of other messages. I'll adjust this for the Servarr install options. Our docs point to web UI updater already, so it makes sense to have a reinstall doing an actual reinstall, repairing broken installs as well OOTB.