Update not applying

FlangeMonkey · October 19, 2015, 6:48pm

Hi Guys,

I wonder if someone can help, update goes through the process, everything look ok with no error in the GUI log. However I’ve found the following error in the update log:

15-10-19 19:36:46.2|Info|UpdateApp|Starting Sonarr Update Client
15-10-19 19:36:46.4|Info|UpdateApp|Updating Sonarr to version 2.0.0.3527
15-10-19 19:36:46.5|Info|AppFolderInfo|Data directory is being overridden to [/usr/local/etc/sonarr]
15-10-19 19:36:46.6|Debug|UpdateApp|NzbDrone process ID: 16255
15-10-19 19:36:46.6|Debug|UpdateApp|Arguments:
15-10-19 19:36:46.6|Debug|UpdateApp| 16255
15-10-19 19:36:46.6|Debug|UpdateApp| /tmp/nzbdrone_update
15-10-19 19:36:46.6|Debug|UpdateApp| /usr/local/sonarr/NzbDrone/NzbDrone.exe
15-10-19 19:36:46.6|Debug|UpdateApp| /data=/usr/local/etc/sonarr
15-10-19 19:36:46.6|Debug|UpdateApp| /nobrowser
15-10-19 19:36:46.6|Debug|UpdateApp|Using executing application: /usr/local/sonarr/NzbDrone/NzbDrone.exe
15-10-19 19:36:46.6|Debug|UpdateApp|Executable location: /usr/local/sonarr/NzbDrone/NzbDrone.exe
15-10-19 19:36:46.6|Info|UpdateApp|Starting update process. Target Path:/usr/local/sonarr/NzbDrone
15-10-19 19:36:46.6|Info|InstallUpdateService|Verifying requirements before update…
15-10-19 19:36:46.6|Debug|ProcessProvider|Finding process with Id:16255
15-10-19 19:36:46.6|Fatal|UpdateApp|An error has occurred while applying update package.

System.NotSupportedException: This system does not support EnumProcesses
at (wrapper managed-to-native) System.Diagnostics.Process:GetProcesses_internal ()
at System.Diagnostics.Process.GetProcesses () [0x00000] in /wrkdirs/usr/ports/lang/mono/work/mono-4.0.3/mcs/class/System/System.Diagnostics/Process.cs:840
at NzbDrone.Common.Processes.ProcessProvider.GetProcessById (Int32 id) [0x00023] in m:\BuildAgent\work\6c3239faf2b92630\src\NzbDrone.Common\Processes\ProcessProvider.cs:75
at NzbDrone.Common.Processes.ProcessProvider.Exists (Int32 processId) [0x00000] in m:\BuildAgent\work\6c3239faf2b92630\src\NzbDrone.Common\Processes\ProcessProvider.cs:58
at NzbDrone.Update.UpdateEngine.InstallUpdateService.Verify (System.String targetFolder, Int32 processId) [0x0005c] in m:\BuildAgent\work\6c3239faf2b92630\src\NzbDrone.Update\Upda
teEngine\InstallUpdateService.cs:67
at NzbDrone.Update.UpdateEngine.InstallUpdateService.Start (System.String installationFolder, Int32 processId) [0x00000] in m:\BuildAgent\work\6c3239faf2b92630\src\NzbDrone.Update
\UpdateEngine\InstallUpdateService.cs:79
at NzbDrone.Update.UpdateApp.Start (System.String[] args) [0x00020] in m:\BuildAgent\work\6c3239faf2b92630\src\NzbDrone.Update\UpdateApp.cs:59
at NzbDrone.Update.UpdateApp.Main (System.String[] args) [0x00042] in m:\BuildAgent\work\6c3239faf2b92630\src\NzbDrone.Update\UpdateApp.cs:43

This is on a flavor of freebsd and Mono 4.0.3. Any ideas?

Cheers

markus101 · October 19, 2015, 8:48pm

Not sure if this issue is fixed in mono 4.0.4 as it looks similar to the issue on QNAP devices that was fixed in 4.0.4.

The issue is a known issue:

Which was introduced in in mono 4.0 and later fixed.

FlangeMonkey · October 19, 2015, 9:02pm

Thanks for the pointer… I’m going to update and test it. I’ll let you know if that fixes it.

Thank you,

FlangeMonkey · October 20, 2015, 3:13pm

I cannot upgrade to 4.0.4 due to ports and pkg being 4.0.3. I could go outside this management but I understand other problems can transpire. Therefore does anyone know how to manually update sonarr?

AlVal · November 24, 2015, 10:41pm

today a freebsd ports update updated mono

I’m now at

Mono JIT compiler version 4.2.1 (Stable 4.2.1.102/6dd2d0d Tue Nov 24 21:59:25 UTC 2015)

but the issue still persists.

AlVal · November 25, 2015, 7:45am

one of the freebsd mono port maintainers did provide me this response though, when showing him the error.

"The NotSupported error is in a mono wrapper around native functions. I have run into similar issues around DirectoryWatchers trying to use kqueue and wrappers around native “internal” commands for copying/moving files. And like the error you are seeing, someone thought they had already patched the kqueue issue and it has subsequently broken again.

I would be interested in seeing the change list between 4.0.3 and 4.0.4 that supposedly fixes this. I’m super busy right now so I don’t have time to drill in, but it looks like you have all the debug information here to resolve the issue if you felt like fixing mono!"

he also agreed it may be worth looking into whether its an issue unique to jails, so it may be helpful if people encountering it on freebsd/freenas etc can state whether they’re in a jail or not

Taloth · November 25, 2015, 1:35pm

I checked, I was a bit confused with a problem that popped up on qnap.
which was broken in this commit and fixed in this one, but that was specific to qnap. FreeBSD does NOT use that code at all, coz the KERN_PROC and KERN_PROC2 sysctl calls seem to be linux specific. On OSX and BSD, mono will fallback to using /proc (see these lines).
The only problem for FreeBSD that I remember atm was that procfs wasn’t properly mounted.

Ideally, a implementation should be made for FreeBSD that uses the freebsd sys calls available for getting processes. Of course, this requires familiarity with both C coding and FreeBSD.

I do suspect that the inability to get the processes from /proc is related to the jail, but fixing that is a workaround, the ideal solution remains implementing the appropriate syscall, if possible.

jlweatherly · November 30, 2015, 3:45pm

I also am having this issue with FreeBSD, until a fix is ready, can anyone point me to a set of instructions to manually update Sonarr? (FlangeMonkey also asked this, but no one replied to it…)

Thanks
-J

FlangeMonkey · November 30, 2015, 4:05pm

Hi J,

I did it on the latest update recently. The process may vary and its very similar in how you deployed it. My config files are in a different location, so it was safe for me, but I did the install manually. So I did the following:

stopped the service
renamed the existing sonarr folder for backup and backed up my config folder
used wget to download “http://update.sonarr.tv/v2/master/mono/NzbDrone.master.tar.gz”
extracted this file to my originally named sonarr folder
started the service

Like I say if you used something like git or a repository, I would suggest a different process.

jlweatherly · November 30, 2015, 5:07pm

Thanks! I am now successfully running Version 2.0.0.3594. My config directory was in a separate location so it turned out to be rather easy.

AppData directory    /home/_sabnzbd/.config/NzbDrone
Startup directory    /usr/local/NzbDrone

Following your steps I did the following:

root@localhost:/home/_sabnzbd # service nzbdrone stop
Stopping nzbdrone.
Waiting for PIDS: 18813, 18813.
root@localhost:/home/_sabnzbd # cd /usr/local
root@localhost:/usr/local # mv /usr/local/NzbDrone /usr/local/NzbDrone.backup
root@localhost:/usr/local # wget http://update.sonarr.tv/v2/master/mono/NzbDrone.master.tar.gz
<snipped>
root@localhost:/usr/local # tar xvzf NzbDrone.master.tar.gz
<snipped>
root@localhost:/usr/local # mv NzbDrone.master.tar.gz ~

Restart Sonarr:

root@localhost:/usr/local # service nzbdrone start
Starting nzbdrone.

Got an error about Startup Dir not being writable, so update couldn’t apply (that should no longer be needed), did the following:

root@localhost:/usr/local # chown -R _sabnzbd:_sabnzbd NzbDrone
root@localhost:/usr/local # rm -rf /tmp/nzbdrone_update/
root@localhost:/usr/local # service nzbdrone stop
Stopping nzbdrone.
Waiting for PIDS: 12279, 12279.
root@localhost:/usr/local # service nzbdrone start
Starting nzbdrone.

Then made sure the original backup can’t be touched by anything other than root (I’m paranoid, could probably just delete it safely…):

root@localhost:/usr/local # chown -R root:wheel NzbDrone.backup/
root@localhost:/usr/local # chmod 700 NzbDrone.backup/

This could have been trimmed down a little if I’d remembered to cleanup the /tmp/nzbdrone_update dir before starting it the first time.

Long story short, this seemed to work for me. Thanks again!

system · January 29, 2016, 5:07pm

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.