This file would allow for the creation of needed directories that jellyfin otherwise has to create at runtime. When I installed and ran jellyfin, i needed to create /var/cache/jellyfin, and set it's owner to the jellyfin user/group, as my system did not allow jellyfin to do so itself.
I don't think a tmpfiles.d file is necessary. The systemd service has: CacheDirectory=jellyfin See: https://github.com/gentoo/gentoo/blob/011652b793f7e3263694f93ca0f54d839657d033/www-apps/jellyfin/files/jellyfin.service#L11 Per the documentation at https://www.freedesktop.org/software/systemd/man/systemd.exec.html#RuntimeDirectory= > If set, when the unit is started, one or more directories by the specified names will be created (including their parents) below the locations defined in the following table. Therefore, the systemd service already creates the /var/cache/jellyfin directory and the ownership is set correctly to jellyfin:jellyfin. I tested this behavior, and as far as I can tell, it's working correctly. Therefore, I can't reproduce the problem you're reporting. Is there more information you can provide that could help me reproduce the issue so we can determine a fix for it?
My use case involves mounting /var/ read only with only /var/cache/jellyfin writable. If the image is generated without having run jellyfin for the first time, then /var/cache/ can't have jellyfin created. The specific situation i ran into is using a systemd-nspawn container to run the jellyfin service, with the nspawn configuration file at the end of the comment. But the problem is more generic. Relying on runtime .service files to be able to create directories that the package will *always* use is incompatible with a variety of deployment scenerios, and would then require additional work by the end user. The most robust way to solve this would be to have the ebuild install a .keep file in /var/cache/jellyfin. Slightly less robust, but perhaps a bit more convenient would be to use tmpfiles.d, as it's reasonable to expect an image generator to run the tmpfiles service to create needed directory entries prior to building a read-only image. Least robust is expecting systemd to have the write permissions to create things just prior to running the service in question. mimir /etc/systemd/nspawn # cat jellyfin.nspawn [Exec] MachineID=7c3deb84640b9bcb48281be463a51bf1 ResolvConf=replace-stub PrivateUsers=false LinkJournal=false Ephemeral=true [Files] BindReadOnly=/usr/ BindReadOnly=/var/ BindReadOnly=/etc/ BindReadOnly=/opt/ BindReadOnly=/dev/null:/etc/fstab BindReadOnly=/media/raid/machines/jellyfin-state/etc/hosts:/etc/hosts BindReadOnly=/media/raid/machines/jellyfin-state/etc/hostname:/etc/hostname Bind=/media/raid/machines/jellyfin-state/var/log/:/var/log/ ## # This is the line that fails, if jellyfin is never run on the host. systemd-nspawn can't bind-mount a folder that doesn't exist. ## Bind=/media/raid/machines/jellyfin-state/var/cache/jellyfin/:/var/cache/jellyfin/ Bind=/media/raid/machines/jellyfin-state/var/lib/jellyfin/:/var/lib/jellyfin/ Bind=/media/raid/machines/jellyfin-state/etc/jellyfin/:/etc/jellyfin/ Bind=/media/raid/machines/jellyfin-state/etc/systemd/system/:/etc/systemd/system/ TemporaryFileSystem=/home/ TemporaryFileSystem=/var/tmp/ TemporaryFileSystem=/var/lib/machines/ BindReadOnly=/media/raid/multimedia/ [Network] MACVLAN=general
Is there any reason you can't bind to /var/cache instead of /var/cache/jellyfin? The default directories is just sane defaults; you can also overload the service file to point the cache directory to wherever you want. I do this to collect all jellyfin runtime under a single directory for easy zfs snapshotting (although I use openrc instead of systemd). If the cache directory had been in some non-standard location I guess it may make sense, but I think it's unreasonable to create a tmpfiles.d configuration by default just in case /var/cache is not writable.
A tmpfiles entry would be useful for openrc, fwiw.
(In reply to Fredrik Eriksson from comment #3) > Is there any reason you can't bind to /var/cache instead of > /var/cache/jellyfin? Yes, the jellyfin process has no business accessing the rest of /var/cache/. > The default directories is just sane defaults; you can also overload the > service file to point the cache directory to wherever you want. I do this to > collect all jellyfin runtime under a single directory for easy zfs > snapshotting (although I use openrc instead of systemd). Then why make the defaults different than what you use yourself? > If the cache directory had been in some non-standard location I guess it may > make sense, but I think it's unreasonable to create a tmpfiles.d > configuration by default just in case /var/cache is not writable. There's more to tmpfiles.d than just working around /var/cache/ not being writable. Image creation, runtime security by only allowing tmpfiles.d to create directories on boot, various other things. It's a reasonable request that causes no harm to other users, but enables new use-cases.
(In reply to Michael Jones from comment #5) > (In reply to Fredrik Eriksson from comment #3) > > Is there any reason you can't bind to /var/cache instead of > > /var/cache/jellyfin? > > Yes, the jellyfin process has no business accessing the rest of /var/cache/. > I'm not familiar with nspawn, so maybe I'm missing some important detail, but what I ment was that maybe changing this line: > Bind=/media/raid/machines/jellyfin-state/var/cache/jellyfin/:/var/cache/jellyfin/ To this: > Bind=/media/raid/machines/jellyfin-state/var/cache:/var/cache Would make /var/cache writeable in the container and solve your problem? Since you bind it to a dedicated directory it would not mix with cache files for other services. > Then why make the defaults different than what you use yourself? Because it would be confusing, against the FHS, and I recognize that my use case is not representative for the average jellyfin user. > There's more to tmpfiles.d than just working around /var/cache/ not being > writable. Image creation, runtime security by only allowing tmpfiles.d to > create directories on boot, various other things. > > It's a reasonable request that causes no harm to other users, but enables > new use-cases. From the manpage of tmpfiles.d: > The advantages are that the configuration required by the unit is centralized in > one place, and that the lifetime of the directory is tied to the lifetime of the service itself. Similarly, > StateDirectory=, CacheDirectory=, LogsDirectory=, and ConfigurationDirectory= should be used to create directories under > /var/lib/, /var/cache/, /var/log/, and /etc/. tmpfiles.d should be used for files whose lifetime is independent of any > service or requires more complicated configuration. I think that makes it pretty clear that tmpfiles.d is *not* the correct way to configure the cache-directory when using systemd. That said, as Sam pointed out there is nothing equivalent in openrc (although the current init-script would create the directory in a similar way) and, as you say, the change is probably mostly harmless. I created a PR for a new revision that adds a tmpfiles.d configuration.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=447ca26e88e5d17cef04b440000917daed7b07a5 commit 447ca26e88e5d17cef04b440000917daed7b07a5 Author: Fredrik Eriksson <feffe@fulh.ax> AuthorDate: 2023-02-12 07:42:46 +0000 Commit: Joonas Niilola <juippis@gentoo.org> CommitDate: 2023-02-25 09:11:43 +0000 www-apps/jellyfin: Add tmpfiles.d configuration Closes: https://bugs.gentoo.org/888097 Signed-off-by: Fredrik Eriksson <feffe@fulh.ax> Closes: https://github.com/gentoo/gentoo/pull/29554 Signed-off-by: Joonas Niilola <juippis@gentoo.org> www-apps/jellyfin/jellyfin-10.8.9-r1.ebuild | 65 +++++++++++++++++++++++++++++ 1 file changed, 65 insertions(+)
