Sonarr version (exact version): 20170106-9 Mono version (if Sonarr is not running on Windows): 4.6.2-0095 OS: Synology DSM
Description of issue:
Good night Sonarr users,
I have been using Sonarr for three months. Last night I came home from a four week trip through Sweden. I saw that there was a new update in the Sonarr system tab. This morning I updated to the latest version. When I open the UI, I am greeted with the hazy message:
{
“message”: “NotFound”
}
The Synology application is running. Stopping and restarting the application does not change this message. Somehow it seems that the update removes certain paths (hence the ‘not found’ message).
Who can help me out with this, it seems like something that must have happened before.
There could be several things failing and resulting in that message, we’ll need to see ((log files)) from Sonarr right now, as well as the update log files.
It may be easiest to reinstall the package, but before you uninstall it, ((backup)) Sonarr, if you uninstall the config will be removed (this is something that Synology does).
Thanx for your reply, but I did not activate logging when I installed Sonarr. Thus there are no logs to download and share. When I check the package in Synology and the logs on the package, it is just a simple installation log from three months ago. When I check the system’s AppData folder there are just these folders:
App
Bin
Lib
Share
Var
And the files cert.pem and openssl.cnf.
According to the wiki pages, there should be a config.xml file but that isn’t there as well. I have a feeling that the system deleted several of it’s core files while upgrading, then encountered some fatal error. Obviously I don’t know this for sure but it smells like an install gone bad.
Sonarr always logs something, more logging can be enabled, but it can’t be completely disabled.
Sonarr has it’s own folder, which is referred to as the App Data folder, if you look at this wiki page (linked from the log files wiki page): https://github.com/Sonarr/Sonarr/wiki/AppData-Directory it lists some common locations, including on synology.
Okay, I can understand the need to share logs, but I do feel you are a bit aggressive about this. Remember, we’re not all proficient in these matters and command line access is not ‘snap you fingers and poof’.
I dug deeper into the folders and files. I have copied the logs and I have read them. Now, please tell me which log you would like to have exactly. I have downloaded roughly 15 logs. The primary update log reads like a series of errors though after the update started. Primarily:
17-8-26 21:11:22.0|Trace|SymbolicLinkResolver|Checking path /tmp/nzbdrone_update/nzbdrone_backup/UI/Content/zero.clipboard.swf for symlink returned error ENOENT, assuming it’s not a symlink.
The log is filled with these. Trace -> debug, hundreds of lines. Then SymbolicLinkResolver, because of the same error. If you want I can copy these, but they are essentially all the same as the line above, just looking for another file / link. The log ends with the statement:
17-8-26 21:11:24.7|Info|TerminateNzbDrone|Killing all running processes
17-8-26 21:11:25.7|Debug|ProcessProvider|Found 0 processes with the name: NzbDrone.Console
17-8-26 21:11:25.7|Debug|ProcessProvider|Found 0 processes to kill
17-8-26 21:11:26.7|Debug|ProcessProvider|Found 0 processes with the name: NzbDrone
17-8-26 21:11:26.7|Debug|ProcessProvider|Found 0 processes to kill
17-8-26 21:11:26.7|Info|ProcessProvider|[15063]: Killing process
17-8-26 21:11:26.7|Info|ProcessProvider|[15063]: Waiting for exit
17-8-26 21:11:26.7|Info|ProcessProvider|[15063]: Process terminated successfully
17-8-26 21:11:26.7|Info|InstallUpdateService|Waiting for external auto-restart.
17-8-26 21:11:27.6|Info|UpdateApp|Starting Sonarr Update Client
17-8-26 21:11:28.0|Debug|ProcessProvider|Found 0 processes with the name: NzbDrone
17-8-26 21:11:28.2|Debug|UpdateApp|NzbDrone process ID: 15063
17-8-26 21:11:28.2|Debug|UpdateApp|Arguments:
17-8-26 21:11:28.2|Debug|UpdateApp| 15063
17-8-26 21:11:28.2|Debug|UpdateApp| /tmp/nzbdrone_update
17-8-26 21:11:28.2|Debug|UpdateApp| /volume1/@appstore/nzbdrone/share/NzbDrone/NzbDrone.exe
17-8-26 21:11:28.2|Debug|UpdateApp|Using executing application: /volume1/@appstore/nzbdrone/share/NzbDrone/NzbDrone.exe
17-8-26 21:11:28.2|Debug|UpdateApp|Executable location: /volume1/@appstore/nzbdrone/share/NzbDrone/NzbDrone.exe
17-8-26 21:11:28.2|Info|InstallUpdateService|Installation Folder: /volume1/@appstore/nzbdrone/share/NzbDrone
17-8-26 21:11:28.2|Info|InstallUpdateService|Updating Sonarr from version 2.0.0.4949 to version 2.0.0.4949
17-8-26 21:11:28.2|Info|InstallUpdateService|Verifying requirements before update…
17-8-26 21:11:28.3|Debug|ProcessProvider|Finding process with Id:15063
17-8-26 21:11:28.3|Warn|ProcessProvider|Unable to find process with ID 15063
17-8-26 21:11:29.3|Debug|ProcessProvider|Found 0 processes with the name: NzbDrone
17-8-26 21:11:30.6|Debug|ProcessProvider|Found 0 processes with the name: NzbDrone
17-8-26 21:11:32.0|Debug|ProcessProvider|Found 0 processes with the name: NzbDrone
17-8-26 21:11:33.4|Debug|ProcessProvider|Found 0 processes with the name: NzbDrone
17-8-26 21:11:33.7|Debug|ProcessProvider|Found 0 processes with the name: NzbDrone
17-8-26 21:11:33.7|Info|StartNzbDrone|Starting NzbDrone
17-8-26 21:11:33.7|Info|StartNzbDrone|Starting NzbDrone.exe
17-8-26 21:11:33.7|Debug|ProcessProvider|Starting mono --debug /volume1/@appstore/nzbdrone/share/NzbDrone/NzbDrone.exe /nobrowser
17-8-26 21:11:33.7|Info|UpdateApp|Update completed successfully
17-8-26 21:11:28.3|Fatal|UpdateApp|An error has occurred while applying update package.
[v2.0.0.4949] System.ArgumentException: Process with ID doesn’t exist 15063
at NzbDrone.Update.UpdateEngine.InstallUpdateService.Verify (System.String targetFolder, System.Int32 processId) [0x000c3] in M:\BuildAgent\work\b69c1fe19bfc2c38\src\NzbDrone.Update\UpdateEngine\InstallUpdateService.cs:78
at NzbDrone.Update.UpdateEngine.InstallUpdateService.Start (System.String installationFolder, System.Int32 processId) [0x00032] in M:\BuildAgent\work\b69c1fe19bfc2c38\src\NzbDrone.Update\UpdateEngine\InstallUpdateService.cs:85
at NzbDrone.Update.UpdateApp.Start (System.String[] args) [0x00010] in M:\BuildAgent\work\b69c1fe19bfc2c38\src\NzbDrone.Update\UpdateApp.cs:58
at NzbDrone.Update.UpdateApp.Main (System.String[] args) [0x00031] in M:\BuildAgent\work\b69c1fe19bfc2c38\src\NzbDrone.Update\UpdateApp.cs:43
17-8-26 21:11:30.2|Debug|X509CertificateValidationPolicy|Certificate validation for https://sentry.sonarr.tv/api/11/store/ failed. RemoteCertificateChainErrors
It seems that the update service is looking for several things that are not in the system, or not in the system at the location the service wants them to be.
The update log from the latest update and the last log file (sonarr.txt) from the regular logs. Either upload the files to dropbox/google drive/something similar and post the links here or copy the contents to pastebin/hastebin/something similar and post the links here.
Markus, I can do this but everything of note that is in those logs I have already posted above. The update log is the one with hundreds of lines of essentially the same error and trying to resolve that error. It ends with the statement pasted in my post already. There is nothing besides that in the logfile.
The Sonarr log contains several errors which I have pasted below. The first errors are unrelated to the update; the last two errors are related to the update but if I were to hazard a guess that is because the update itself failed and caused a critical error in the application.
Please post the logs on another site and link them here, that way formatting is not mangled and there aren’t pages to scroll through to read the actual conversation here.
Please post the full logs. not snippets of them.
The log file before this update log would also be helpful, since it look like the updater was already run (and possibly the reason for the problem as 17-8-26 21:11:28.2|Info|InstallUpdateService|Updating Sonarr from version 2.0.0.4949 to version 2.0.0.4949 was logged).
Obviously a cascade might have happened. But reading the logs, that seems strange. Also, the previous update did not fail or perform a sanity check in it’s own eco system, otherwise it would have prevented the update from actually overwriting the existing software. The last update does seem to make some rather strange calls, it almost seems as if an update was executed for the wrong system, hence the continuous failures in the update logs.
I have checked the Synology system updates, but there is nothing there that would reflect back on Sonarr. The fact that it can’t find / resolve / repair symlinks is odd. It might be a rights issue. No rights were changed on the service by the Synology system though.
It’s only checking if it is a symlink, whether it is or not is doesn’t matter in this case (but in some cases when it is Sonarr has to treat the file differently to avoid issues). This is the reason why these messages are logged at the Trace level instead of Warn or Error, they’re only really important when troubleshooting.
What it looks like here is two updates were triggered at roughly the same time (they started 12 seconds apart), the first update seems to be successful based on the logs and the second one failed because the update process had already stopped Sonarr. One issue with the update is I don’t see the UI being updated, so that is possibly the issue.
If the UI is missing that would explain the Not Found message, but the logs don’t confirm that because they don’t log anything at the info level for requests to the web server, just debug/trace.
There are a couple ways to resolve this issue, but first you need to make a ((backup)) of Sonarr (you can grab the latest backup files from the same folder where the log files were (just up one folder).