Search Criteria
Package Details: radarr 4.1.0.6175-1
Package Actions
Git Clone URL: | https://aur.archlinux.org/radarr.git (read-only, click to copy) |
---|---|
Package Base: | radarr |
Description: | Movie download automation for usenet and torrents. |
Upstream URL: | https://github.com/Radarr/Radarr |
Licenses: | GPL3 |
Submitter: | fryfrog |
Maintainer: | fryfrog (onedr0p) |
Last Packager: | fryfrog |
Votes: | 44 |
Popularity: | 0.115113 |
First Submitted: | 2016-12-29 18:44 (UTC) |
Last Updated: | 2022-04-15 02:36 (UTC) |
Dependencies (10)
- sqlite (sqlite-replication, sqlite-minimal-git, sqlite-fts3-parenthesis, sqlite-fossil)
- deluge (deluge-git, deluge2-stable-git, deluge1) (optional) – torrent downloader
- jackett (jackett-mono, jackett-bin) (optional) – torrent indexer proxy
- libgdiplus (optional) – provides a gdi+ compatible api
- nzbget (nzbget-git) (optional) – usenet downloader
- rtorrent (rtorrent-git, rtorrent-color, rtorrent-pyro-git, rtorrent-ps, rtorrent-ipv6, rtorrent-ps-ch, rtorrent-vi-color) (optional) – torrent downloader
- sabnzbd (sabnzbd-git) (optional) – usenet downloader
- transmission-cli (transmission-cli-git, transmission-noxunlei-cli, transmission-sequential-cli) (optional) – torrent downloader (CLI and daemon)
- transmission-gtk (transmission-csd-git, transmission-noxunlei-gtk, transmission-sequential-gtk, transmission-gtk-git) (optional) – torrent downloader (GTK+)
- transmission-qt (transmission-qt-git, transmission-qt-ssl-git, transmission-noxunlei-qt, transmission-sequential-qt) (optional) – torrent downloader (Qt)
Required by (6)
- ombi (optional)
- ombi-develop (optional)
- prowlarr (optional)
- prowlarr-nightly (optional)
- traktarr (optional)
- traktarr-git (optional)
Sources (7)
- https://github.com/Radarr/Radarr/releases/download/v4.1.0.6175/Radarr.master.4.1.0.6175.linux-core-arm.tar.gz
- https://github.com/Radarr/Radarr/releases/download/v4.1.0.6175/Radarr.master.4.1.0.6175.linux-core-arm64.tar.gz
- https://github.com/Radarr/Radarr/releases/download/v4.1.0.6175/Radarr.master.4.1.0.6175.linux-core-x64.tar.gz
- package_info
- radarr.service
- radarr.sysusers
- radarr.tmpfiles
Latest Comments
fryfrog commented on 2022-05-04 16:29 (UTC)
The
UMask=
only controls the permissions of files and folders created by the software, it has no effect on existing files/folders. For a user per software w/ a shared group setup, a umask of002
is appropriate, which results in folders w/ 775 and files 664. In a one user/group setup, using022
would result in 755 for folders and 644 for files. But again, that is only newly created ones. You'd need to usechown
andchmod
to fix existing files or perhaps change theUser=
andGroup=
that radarr runs as.You should hop on the Disord or /r/radarr sub-reddit and get real help, this is more appropriate for actual package issues.
alfzki commented on 2022-05-04 04:18 (UTC)
Could you guide me about which value should I use for UMask ? I tried 000 but Radarr still couldn't access nor read /home/user
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=
andUMask=
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 calledradarr.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:
Those
Partial RELRO
andNo 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 viasystemctl 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.
fryfrog commented on 2020-05-10 03:04 (UTC)
Hey @emphire, check out the radarr-aphrodite package which has done a little of what you're talking about.
They added a
package_info
that lets me disable the built in updater and display a message, so I've put/usr/lib/radarr
back toroot:root
which I think you'll appreciate. I'm waiting for that to come to the normal version, then I'll change it there too.I moved all my packages from doing it in the
.install
file to using tmpfiles, I believe based on feedback from #archlinux-aur. Do you have some packaging guidelines that talk about doing this as part of the package vs via tmpfiles? I mean, the name obviously implies it... but I prefer it over doing it in the install precisely because it'll fix permissions more often if needed. And can be easily overridden by the user, unlike doing it from the package.Finally, the script that runs mono that runs Radarr... that is one of the things that bugs me a little about the sonarr package I don't own, for some reason I just don't like it. Also, the next version of Radarr is dotnet core so doesn't even need Mono, you just run it directly. If you want to change some parameters, now you need to hunt down that file if they're
mono
options or edit the script if they're not... or don't edit the script because the package is going to blow it away, edit the.service
.Thanks for the feedback, if you can convince me of any of these specific changes, I'll be happy to make them and I'll then do it for all the packages I own. But at the very least, I think the most import part of it (the
root:root
ownership of/usr/lib/radarr
) is coming eventually. :)emphire commented on 2020-05-10 02:44 (UTC) (edited on 2020-05-10 02:45 (UTC) by emphire)
I made some tweaks to the package I was hoping you could include in the next release.
Here is the git diff: http://ix.io/2lup
The changes are:
The /usr/lib/radarr directory and its contents was owned by the radarr user. It's more secure to have it owned by root so radarr has readonly access to it so that variable data can be restricted to /var/lib/radarr.
tmpfiles.d is intended for temporary and volatile files. I moved the directory permissions setting into an install file - this also means that the permissions won't get set on every boot (just on install).
I added /usr/bin/radarr so it can be run in browser mode from the commandline as a regular user if desired (untested). It also cleans-up the .service file a little.
Here are the changed files if the diff is hard to read: PKGBUILD: http://ix.io/2luu radarr.install: http://ix.io/2luq radarr.service: http://ix.io/2lur radarr.sh: http://ix.io/2lus radarr.tmpfiles: http://ix.io/2lut
Thanks!
fryfrog commented on 2019-11-26 04:49 (UTC)
It didn't seem worth bumping pkgrel for, but if you refresh you'll get it. I did it to sonarr-develop, radarr-develop, sonarr-phantom and lidarr too. But radarr-aphrodite and lidarr-develop have switched to dotnet core so they don't need it.
Thanks for the great idea.
fryfrog commented on 2019-11-26 04:41 (UTC)
@joehillen: Great idea, will do! :)
joehillen commented on 2019-11-26 04:36 (UTC)
Could you set SyslogIdentifier=radarr in the service file? Otherwise it shows as "mono" in the journal.
fryfrog commented on 2019-07-08 17:40 (UTC)
The
mono
command has the--debug
option, not Radarr. You should post on reddit or get help in Discord to figure out what is going on, it doesn't do that on my system. Or you're welcome to just over ride theExecStart=
command via normal systemd methods.Good luck.
carbolymer commented on 2019-07-08 17:12 (UTC) (edited on 2019-07-08 17:13 (UTC) by carbolymer)
Why radar has --debug flag in its command? It floods my system journal with 100000 log entries daily....
gee commented on 2019-05-06 17:58 (UTC)
Whoops sorry I had not seen your reply.
Thank you very much!
fryfrog commented on 2019-03-12 05:26 (UTC)
At the top of the
radarr.tmpfiles
file is a comment,# Override this file with a modified version in /etc/tmpfiles.d/
which tells you how to over ride the file/folder ownership and links.You've probably already figured out how to override the
.service
file, right?gee commented on 2019-03-12 05:20 (UTC)
Hello,
I'm using radarr with this PKGBUILD, but I have an issue.
I set radarr to use another user in the systemd service file, but the /usr/lib/radarr and /usr/var/radarr folders keep resetting to radarr:radarr. What do I need to change to fix this?
Thank you!
fryfrog commented on 2018-11-14 17:31 (UTC)
In the radarr.service file,
Restart=on-failure
is supposed to deal w/ that.How do you make it happen? Using the restart built into Radarr? Or using the built in updater? I never use either, personally.
uint2048_t commented on 2018-11-14 17:15 (UTC) (edited on 2018-11-14 17:19 (UTC) by uint2048_t)
Any way to keep this from happening? Seems to happen when radarr tries to use it's built-in restarting mechanism rather than the systemd service:
Which causes the logs to fill up with messages that the IP radarr is using is already in use.
onedr0p commented on 2018-11-14 02:31 (UTC)
Thanks man!
fryfrog commented on 2018-11-13 21:16 (UTC) (edited on 2018-11-13 21:23 (UTC) by fryfrog)
The files had two versions in their name. I talked to @gallileo and he'll flip them from draft -> pre-release when they're ready. :)
Edit: File names are fixed now at least!
onedr0p commented on 2018-11-13 21:08 (UTC)
No worries, I haven't done a release here in awhile so I didn't want to break things. The only difference I see it not saying develop in the package name.
fryfrog commented on 2018-11-13 17:10 (UTC)
@onedr0p, the release up on github is a draft and weirdly named. I'm going to see what @gallileo says about it before updating. :/
fryfrog commented on 2018-09-09 21:51 (UTC)
@nicoulaj: Seems reasonable, updated this package and radarr-develop as well as a couple of the sonarr packages.
nicoulaj commented on 2018-09-09 16:11 (UTC) (edited on 2018-09-09 16:11 (UTC) by nicoulaj)
I think the service starts too early at boot, I can see this stack trace with the sonarr package that uses the exact systemd service file:
It is followed by NetworkManager startup traces. I think the correct way is:
fryfrog commented on 2018-05-28 21:46 (UTC)
@RenVilo: Are you... running Arch Linux on your QNAP?
RenVilo commented on 2018-05-28 21:41 (UTC)
I'm running a QNAP NAS with QMono, SABNZBD, Sonarr and Radarr. Everything boots up and is fine except that in Sonarr and Radarr I can't add an Indexer to www.nzbfinder.ws or any other provider. I've tested this from my PC's version and it works fine. I've read that you have to add "Environment=MONO_TLS_PROVIDER=legacy" but I have no idea how to do this and seems Mono vs QMono might have a different file structure. I can't find "sonarr.service" or the path "usr/lib/systemd/system"
Info on my versions:
Sonarr: V2.0.0.5163 QMono: V5.12.0.266 (of TS-X19 but have tried other previous releases of V5. No V4 available) OS: QNAP Version 4.3.3.0546
https://www.dropbox.com/s/xiwzpfgj87mbibx/sonarr.debug.txt?dl=0
https://www.dropbox.com/s/y09dkbz5yq2nw02/sonarr.trace.txt?dl=0
Please can someone assist.
fryfrog commented on 2018-04-29 21:41 (UTC)
@pezz: That is great! I'll add that as a #comment in the file, thanks for figuring it out, it is sure to help someone in the future. And it's okay that your idea of correct isn't correct! ;)
pezz commented on 2018-04-29 15:38 (UTC)
Heh, your idea of "more correct" is different to mine.
Anyway, I deleted my previous comment as I did some reading up on tmpfiles and anything in /etc/tmpfilles.d overrides anything the package puts in /usr/lib so I can easily make my own setup permanent.
So it's a non-issue now, apologies for the noise.
fryfrog commented on 2018-04-29 14:20 (UTC)
@pezz, I haven't forgot about your plight... but I still think it is better for most users to have the directories owned correctly. I'm trying to think of a good way to support your use case too. I tried simply modifying the tmpfiles.d file locally, but it gets over written. I could go back to some logic in the install file, but using tmpfiles really simplified all the packages I maintain. Have you considered just doing your install the more correct way? You could also just modify the tmpfile and make it immutable, but that is a poor solution. :/
Also, I can't see your most recently reply here. :/
fryfrog commented on 2018-04-19 14:53 (UTC)
True, Sonarr's AUR package doesn't and I don't see many instances of users w/ permissions issues.
That said, you totally can (and should) setup your environment so daemons run as their own users and files are owned the right way. You just use a shared group like
media
and a file permission of umask 002 which is 775 for folders and 664 for files. My Radarr runs asradarr
, Sonarr assonarr
, NZBGet asnzbget
, rTorrent asrtorrent
and Plex asplex
. I do use systemd unit over rides to change the group, they're all in a shared group, all setup to create files and folders w/ the right permissions. You need to start off w/ the right permissions, so achown
andchmod
to get things sorted at the start. I use something likefind /path -type f -exec chmod 664 '{}' ';'
to fix files,d
and775
to fix folders.pezz commented on 2018-04-19 14:08 (UTC)
I have Sonarr, Radarr, Kodi and some other things that all run as the same user so that they can interact with the media and storage directories.
Can't have 2 things (especially in the case of Sonarr and Radarr) run as 2 different users and expect them all to have a good time, I expect many people do the same.
Sonarr does not change the permissions of /var/lib/sonarr after a package update.
fryfrog commented on 2018-04-19 12:18 (UTC)
@pezz, I added the ownership of /usr/lib and /var/lib recently, mainly to fix most users setups. Though I think it still did it as part of post upgrade. Can you tell me a little about why you run as a different user? I'd like this package to work well for most people and I'm not sure which route would be better. Do more people bone their permissions and have issues or do more people run it as another user? :/
pezz commented on 2018-04-19 03:07 (UTC)
I'd like to see /var/lib/radarr removed from tmpfiles.
Some of us run Radarr as a different user and it fails to start because of it chowning that directory back to the radarr user.
Perhaps set the initial permissions in post.install but then repsect the user's choice from then on.
Cheers.
fryfrog commented on 2018-04-19 02:19 (UTC)
@smmalis37, have you tested Radarr w/o libgdiplus? It was probably just part of Sonarr's PKGBUILD when I copied it to use for Radarr. If you've tested and know it isn't needed, I can remove it. Otherwise, I'll test in the next few days and see what I find.
smmalis37 commented on 2018-04-18 20:41 (UTC)
libgdiplus is a dependency of mono, not sonarr/radarr directly. There's already an issue on the mono package to move libgdiplus to an optional dependency (https://bugs.archlinux.org/task/46961?project=1&string=mono).
fryfrog commented on 2017-07-05 15:30 (UTC)
jack.mitchell commented on 2017-07-05 12:22 (UTC)
fryfrog commented on 2017-07-02 02:46 (UTC)
T0t0 commented on 2017-07-02 01:28 (UTC)
fryfrog commented on 2017-05-15 16:28 (UTC)
fryfrog commented on 2017-05-15 16:24 (UTC)
zepar commented on 2017-05-15 16:08 (UTC)
fryfrog commented on 2017-05-15 03:18 (UTC)
Abzie commented on 2017-01-15 22:16 (UTC)
onedr0p commented on 2017-01-10 02:50 (UTC)
fryfrog commented on 2017-01-08 15:42 (UTC)
fryfrog commented on 2016-12-29 19:10 (UTC)