Radarr v3.2 dotnet5 binary / Radarr v4 dotnet6 binary

[FrankNAS]

radarrv3 is now on master! hopefully the port maintainer updates it at some point :D

 

[hertzsae]

v3 has been on master for a while now. Master updated to v3.1 a couple days ago on the 4th.
v3 never complained about mono. v3.1 gives the warning to upgrade to .NET Core.
I'm on mono6.8 (installed from ports) and it still appears to be working. Per their help page:

We will likely no longer be providing legacy mono builds after 3.1 is released.

I was glad to read the 'after' in that statement.

@FrankNAS I read the tail of that 6 year old github page. I'm hoping someone there can get your version of dotNet on ports before radarr moves on. Good to know I can install your version from github if that doesn't happen. Thanks for all the work you put in on this!

 

[FrankNAS]

making a pkg/port for the dotNET5 SDK isn't too hard. runtime tests pass. aspnetcore has a few failures that are currently in either depreciated or soon-to-be removed segments (e.g., libuv)

if you need a working SDK for FreeBSD right now you can look at crossbuilds:

https://github.com/Thefrank/dotnet-freebsd-crossbuild (bash script)
https://github.com/Servarr/dotnet-bsd (azure + prebuilt)

if you need a native built SDK for FreeBSD I publish those to my old mega account mainly because I haven't had the time to make suitable build script. It requires significantly more patches than a few `sed`-able lines of the crossbuilt ones...and a working crossbuilt SDK.

If you are currently producing dotNET things and want to target FreeBSD you will need the nuget packages and have to manually add in `freebsd-x64` into any current SDK as a suitable RID/host.

 

[FrankNAS]

Final(?) update posted.

Those in a panic over losing your mono variant of radarr, you have a while to move before it gets dropped (ETA: after v3.2).
Microsoft seems unlikely re-add FreeBSD to dotNET, it was dropped before 3.1 due to build failures :(
FreeBSD seems extremely unlikely to accept dotNET based on past attempts of others to do so :(

edit: clarity

 

[hertzsae]

It sounded like all versions of 3 will still support Mono and that support is being dropped with 4. So it's still going way soon, but we have longer than a month.

Bummer about MS and FreeBSD. I would be happy with a dotNet package in ports, but I'm guessing that's not likely anytime soon. In the meantime, I'm very grateful for the unofficial packages you have provided!

This has really emboldened my desire to move the SCALE when it becomes more reliable. I really like TrueNAS, but am fairly OS agnostic. There's just too many advantages to being on an OS that's treated by everyone as a first class citizen.

 

[FrankNAS]

yeah I didnt explain that clearly. 3.2 will be the last version with mono support. after that the people that will be without a version will only be those with very old FreeBSD bases (for this forum: FreeNAS any version) and very old armv5 Syno devices.

If you are just using FreeBSD/TrueNAS as a fileserver/NAS/minecraft server/otherplugin moving to SCALE would be a good idea as your zpools SHOULD move over cleanly and as its Deb based you will have much better software support and options. If you are using TrueNAS as some sort of workhorse hyper-scaling component; don't. Base FreeBSD is better at that and its much easier to track HEAD under FreeBSD for security and driver issues than TrueNAS (e.g., you can't build TrueNAS under TrueNAS)

edit RANT:
dotNET uses inotify for FreeBSD because no one was willing/able to get kqueue working... and linux variants already use inotify. inotify under FreeBSD is handled via a shim port (libinotify) that is still missing a number of features. This can cause major issues in software (not radarr) that needs to monitor large number of files (e.g. lidarr, jellyfin). This alone is likely enough to get it blocked from coming into ports. It also means I have to put warnings on packages I make letting people know that things need to be disabled otherwise bad things can happen.

 

[danb35]

Forgive what is doubtless a dumb question here, but I'm having trouble getting Radarrv3 to work With the updates as of now to the OP, it looks like I should be able to create a new FreeBSD 12.2 jail, download the package file from GitHub into that jail, and pkg install that file. Then sysrc radarr_enable=YES; service radarr start, and be on my way.

But that isn't working, and I'm not finding any logs showing where the error might be. The only contents of /usr/local/radarr are .pid files (and when I look for those processes, the daemon process is running, but the child process isn't). There are no log files in that directory, and nothing in the system that's relevant (the last entries there are for the package installation). Doubtless I'm missing something simple, but having trouble tracking it down. Suggestions?

Edit: Missed the README on GitHub (also linked further up-thread), and hadn't enabled raw sockets or mlock. Now it works.

 

[FrankNAS]

Edit: Missed the README on GitHub (also linked further up-thread), and hadn't enabled raw sockets or mlock. Now it works.

yeap, all dotNET 5+ binaries need to use mlock otherwise you get odd errors...or in this case an errorlog-less failure state as it never makes to the "log errors" part of radarr launching

 

[Mannekino]

I just upgraded to the latest version of Radarr and I now get an error that Mono no longer will be supported starting from the next version. Is the information in this thread still usable? Can I change to .NET Core inside a jail? I never worked with an "TXZ" file before.

 

[FrankNAS]

there should not be any issues with this afaik. edits/updates are at the end of OP so you might want to read the whole thing before downloading/installing/changing things :)

 

[sretalla]

I created the rc file and it starts the service but Ombi still does not operate unless I run:
root@ombi:/usr/local/share/Ombi # ./Ombi

When I run it like that, I get

Shared object "libe_sqlite3" not found

Which points to a bug that seems to have been solved in the interactive version here: https://github.com/dotnet/interactive/issues/743 in February.

I installed the Radarr package to get the DotNet components and then used @FrankNAS ' package for Ombi4 from the github. Unfortunately can't be more help than saying that I can get the service to start and report that it's running, but I see it's crashing and Restarting Ombi every 30 seconds or so, so no good results... I suppose with that same error... strange as the Radarr jail built with that same package works fine and as far as I can see uses sqlite just the same.

 

[FrankNAS]

so... SQLitePCLRaw (https://github.com/ericsink/SQLitePCL.raw) is e_sqlite3. I have been unable to build this under FreeBSD as it wants products as old as net2.1! The common version in ports on FreeBSD is sqlite3 which is from https://www.sqlite.org/index.html. libsqlite3 != libe_sqlite3 but are close enough that a symlink works...atleast for jellyfin and likely Ombi but ive only done minimal testing with Ombi)

Ombi has a number of problems that I have encountered with it:
- "singlefile" does not correctly add the libs needed so I can't build with it. This is a dotnet issue and not really an Ombi issue but because azure builds of Ombi use singlefile im calling it an Ombi issue lol
- the functions that it uses to find the *.json files it needs to start up seem to return non-sense locations like path where called not path where binary is located. dotnet's built in code analysis points this out during building (CA#### warn/err) but its suggested replacement function has the same behavior *shrug*
-tying Ombi into something like daemon likely wont work because it can only chroot to / which causes the above functions to look for the *.json files in / which is not correct

 

[mistermanko]

Any news on wether one can switch to the dotNET version? pkg still provides version 3.x.x bundled with mono 5.20. There is no reason to manually install mono6.8 if this still works, but when is the dotNET version ready for FreeBSD?

 

[sretalla]

when is the dotNET version ready for FreeBSD?

Now. Follow the instructions in the first post.

 

[FrankNAS]

Any news on wether one can switch to the dotNET version? pkg still provides version 3.x.x bundled with mono 5.20. There is no reason to manually install mono6.8 if this still works, but when is the dotNET version ready for FreeBSD?

If you mean when can you just `pkg install radarr` and get it from ports/pkg? That would be up to the FreeBSD team allowing NO_BUILD ports AND allows dotNET in. If you want it from the TrueNAS GUI the same applies as it just pulls the pkg and sets up the jail auto-magically for you.

late night rant on:

This product (radarr) has until EOL of dotNET5 anyways as the next LTS version of dotNET is 6. Nothing past dotNET6 preview 2 (March-ish 2021) works under FreeBSD and SOS/Diagnostics don't build under FreeBSD. The last mention of a working debugger for dotNET under FreeBSD was back in 2018

EOL on 5 is ~8months away
EOL on 3.1 is ~ 14months away

late night rant off.

enjoy this while it lasts, it wont be forever :)

 

[mistermanko]

If you mean when can you just `pkg install radarr` and get it from ports/pkg? That would be up to the FreeBSD team allowing NO_BUILD ports AND allows dotNET in. If you want it from the TrueNAS GUI the same applies as it just pulls the pkg and sets up the jail auto-magically for you.

late night rant on:

This product (radarr) has until EOL of dotNET5 anyways as the next LTS version of dotNET is 6. Nothing past dotNET6 preview 2 (March-ish 2021) works under FreeBSD and SOS/Diagnostics don't build under FreeBSD. The last mention of a working debugger for dotNET under FreeBSD was back in 2018

EOL on 5 is ~8months away
EOL on 3.1 is ~ 14months away

late night rant off.

enjoy this while it lasts, it wont be forever :)

I'm pretty happy with radarr3 like it is pushed via pkg right now. It works well enough for me. Anything I will miss from the recent dotNET implementation?

 

[sretalla]

EOL on 5 is ~8months away

OK, point taken, but it won't explode and stop working on that date.

 

[FrankNAS]

I'm pretty happy with radarr3 like it is pushed via pkg right now. It works well enough for me. Anything I will miss from the recent dotNET implementation?

The dotNET version runs a bit faster as its native code, requires far fewer dependences, and the latest versions of radarr are always built with the latest versions of dotNET. The dotNET version does not remove anything but the issues with the mono version is that a) it requires an absolute massive list of dependences b) being IL it can be slower than native code and c) it runs a very old, very vulnerable version of mono (5.10/5.20).

It does not use a "file monitor" so it won't run into `libinotify` issues that other things (e.g., lidarr and jellyfin) do.

3.2.x is the last version that will be published with a mono variant. 4.0 is already in nightly. I suggest switching sooner rather than later if you want to keep using a new version of radarr.

OK, point taken, but it won't explode and stop working on that date.

True, but if the radarr team want to use anything that is dotNET6 specific with it, then it will explode...because they just wont build a FreeBSD target for the latest version anymore. More importantly however, it means that Microsoft won't be fixing security issues that might come up with it :(

 

[mistermanko]

I switched sucessfully to .NET but when I want to restart the service i get:
/usr/local/etc/rc.d/radarr: WARNING: failed to start radarr

My data dir is a mounting point pointed to /config if that's anything to do with it. I changed the rc.d/radarr file accordingly.
It works, the service restart itself even, when I restart the jail. So really no clue why it's saying it's failing to start radarr.

 

[sretalla]

Maybe permissions on the pid file(s) ?