Package Details: radarr-bin 5.14.0.9383-9

Git Clone URL: https://aur.archlinux.org/radarr-bin.git (read-only, click to copy)
Package Base: radarr-bin
Description: Movie organizer/manager for usenet and torrent users
Upstream URL: https://radarr.video
Licenses: GPL-3.0-or-later
Groups: servarr-bin
Conflicts: radarr
Provides: radarr
Submitter: txtsd
Maintainer: txtsd (fryfrog)
Last Packager: txtsd
Votes: 56
Popularity: 0.88
First Submitted: 2024-10-15 08:17 (UTC)
Last Updated: 2024-11-15 10:20 (UTC)

Dependencies (21)

Required by (17)

Sources (8)

Pinned Comments

txtsd commented on 2024-10-21 03:38 (UTC) (edited on 2024-10-30 12:50 (UTC) by txtsd)

Alternate versions

radarr (source version of this package)
radarr-develop (develop branch)
radarr-develop-bin (binary version of the develop branch)
radarr-nightly-bin (nightly builds)

Latest Comments

« First ‹ Previous 1 2 3 4 5 6 7 Next › Last »

zynex commented on 2021-08-22 18:38 (UTC) (edited on 2021-08-22 18:39 (UTC) by zynex)

You need to add environment strings to the systemd service. For non english locale the service will fail, https://github.com/Radarr/Radarr/issues/5454.

Environment="LANG=en_GB.UTF-8"
Environment="LANGUAGE=en_GB:en"

Adding those made the service working for me as stated in the GitHub issue.

johnny12 commented on 2021-08-04 10:43 (UTC)

Thanks for your quick reply!

You're right that there is a comment in those files (which is how I found out what was going on eventually) but I didn't bother to look in them initially because I wasn't aware of .tmpfiles and how it works at all. For me the most logical place to inform users would be in the official Sonarr/Radarr installation docs (https://sonarr.tv/#downloads-v3-linux-archlinux) as an optional step 4 maybe?

Also I'm not 100% sure that running the software as a different user is the best way to go but because I also use FUSE mounts as that user this way all the software can access the mountpoints without any permission and ownership issues at all, this has simply always worked for me.

fryfrog commented on 2021-08-03 23:28 (UTC)

I think it is mainly because the other big way of doing it is w/ an .install file which creates and sets ownership of that folder. It isn't part of the package itself, since its all runtime stuff.

What would have helped you figure it out quicker? There is a #comment at the top of the tmpfile. Maybe an additional comment at the top of the service file?

Are you sure running it as a different user is the right move for you? A typical setup would probably override the Group= and UMask= so that your whole setup runs each software as its own user, but a shared group.

You're the first I know of across all the automation packages to really have this concern, but I don't mind improving things. I probably won't move away from .sysusers and .tmpfiles, but am always open to suggestions.

johnny12 commented on 2021-08-03 23:18 (UTC)

@fryfrog I'm using a systemd override.conf (through systemctl edit radarr) to run Radarr (and Sonarr) as a different user. But because of the current tmpfiles with your package the file ownership is changed back to user radarr on system boot. To fix this for now I created a symbolic link called radarr.conf in /etc/tmpfiles.d/ linking to /dev/null as recommended in systemd man pages.

Is this how you would recommend users of your packages to fix this as well? And what's the use of setting permissions and ownership on /var/lib/radarr on every boot anyways? Once the package is installed I wouldn't expect something else to make changes to ownership/permissions. I never heard of tmpfiles and how to override them before so to me it was quite a puzzle solving this and I'm guessing more users might run into this.

fryfrog commented on 2021-01-02 16:40 (UTC)

@codeswhite, could you file a GitHub issue on Radarr? This is actually just a binary package. In the issue, it is worth mentioning that lidarr and readarr probably have the same issue.

codeswhite commented on 2021-01-02 16:17 (UTC)

Hi, i've noticed that the binary is compiled without the recommended exploit protection:

$ sudo checksec --proc=Radarr
...snip...
         COMMAND    PID RELRO           STACK CANARY            SECCOMP          NX/PaX        PIE                     FORTIFY
          Radarr    123 Partial RELRO   Canary found            No Seccomp       NX enabled    No PIE                  No

Those Partial RELRO and No PIE will result in a much easier arbitrary code execution exploit in the Radarr binary.

fryfrog commented on 2020-12-14 20:05 (UTC)

@jlanzobr: You can see radarr.service right up there in Sources and see that it is not using the mono binary. So instead, you need to stop using your custom service and use the one from the package. And you should switch to using a systemd override via systemctl edit when you want to modify parts of a .service file.

jlanzobr commented on 2020-12-14 19:54 (UTC)

The systemd init file needs to be updated. The path (/usr/bin/mono --debug /usr/lib/radarr/bin/Radarr -nobrowser -data=/var/lib/radarr) is no longer correct.

fryfrog commented on 2020-07-20 06:28 (UTC)

@emphire: I'll probably never do a script because I find it annoying to control options in two places. But before tmpfiles, all my packages used the .install file. The systemd tmpfiles seemed like the suggested way, but I'll have another look. I don't care either way about that, would go w/ which ever is the "Arch" way there. You can do so much w/ tmpfiles, like links and folders and ownership and ... seems like its original intent doesn't match its capabilities. :)

emphire commented on 2020-07-20 02:35 (UTC)

Thanks for the response @fryfrog. Sorry it took me a while to get back. In the first line of the docs (https://www.freedesktop.org/software/systemd/man/tmpfiles.d.html), it says it's for volatile and temporary files. Using tmpfiles works but feels a bit hacky for this reason. I find the script file is handy to have for troubleshooting and running it manually instead of as a service. Thanks for maintaining the package.