-
-
Notifications
You must be signed in to change notification settings - Fork 3.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add systemd user service #20871
base: master
Are you sure you want to change the base?
Add systemd user service #20871
Conversation
The qbittorrent-nox@.service was introduced by e00c96d. This system-level unit uses User= to change into a specific user, and qbittorrent will access cache and database files in that user's home. This is a very bad design, because systemd offers a better solution called systemd-user. It makes units specific to the current user run completely under the user service manager, so there is no need to do User= in the system unit anymore. The current approach breaks service dependencies because my home directory is dynamically mounted by systemd-homed upon logon, which is unavailable when qbittorrent-nox@.service was started, rendering the service to dump its core. By moving the unit to systemd-user, systemd handles all dependencies perfectly since the user unit is only going to be started when the home directory is mounted. This patch preserves compatibility with existing setups as it does not delete the previous qbittorrent-nox@.service. Signed-off-by: Yuuta Liang <yuuta@yuuta.moe>
if (SYSTEMD_FOUND AND "${SYSTEMD_USER_SERVICES_INSTALL_DIR}" STREQUAL "") | ||
execute_process(COMMAND ${PKG_CONFIG_EXECUTABLE} | ||
--variable=systemduserunitdir systemd | ||
OUTPUT_VARIABLE SYSTEMD_USER_SERVICES_INSTALL_DIR) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Missing SYSTEMD_USER_SERVICES_INSTALL_DIR
at line 6.
@@ -21,6 +21,17 @@ elseif (NOT SYSTEMD_FOUND AND SYSTEMD_SERVICES_INSTALL_DIR) | |||
defined, but we can't find systemd using pkg-config") | |||
endif() | |||
|
|||
if (SYSTEMD_FOUND AND "${SYSTEMD_USER_SERVICES_INSTALL_DIR}" STREQUAL "") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You should merge the new code to the if
at line 13. For example:
if (SYSTEMD_FOUND)
if ("${SYSTEMD_SERVICES_INSTALL_DIR}" STREQUAL "")
# ...
endif()
if ("${SYSTEMD_USER_SERVICES_INSTALL_DIR}" STREQUAL "")
# ....
endif()
elseif (NOT SYSTEMD_FOUND)
if (SYSTEMD_SERVICES_INSTALL_DIR)
# ...
endif()
if (SYSTEMD_USER_SERVICES_INSTALL_DIR)
# ...
endif()
endif()
[Service] | ||
Type=simple | ||
PrivateTmp=false | ||
ExecStart=/usr/bin/qbittorrent-nox |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ExecStart=/usr/bin/qbittorrent-nox | |
ExecStart=@EXPAND_BINDIR@/qbittorrent-nox |
I'm not familiar with the features so bear with me with the beginner questions. |
TBH this is a very bad idea. You cannot switch to user systemd unitfiles on a headless server. Please note that the service will no start automatically UNLESS you login. Edit: the qbittorrent user is a system user. You usually do not login with that user after everything is setup. |
I use a custom user service on my server right now. One big advantage is that you can control (start/stop/enable/disable/etc) it and access its journal under that user without priviledge escalation.
With
You totally can. Systemd has a linger function to start user services without requiring user to actually log in. |
[Unit] | ||
Description=qBittorrent-nox service | ||
Documentation=man:qbittorrent-nox(1) | ||
Wants=network-online.target |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
network-online.target
doesn't work for user services unfortunately. There are some workarounds though.
I still do not understand why you would login to the server with a user in the first place.
Yep, unfortunately I had issues with that in the past. Maybe they fixed it since then. However, I still believe that for a headless server a user service is the wrong approach. I agree with you when you talk about a workstation that you login to locally. I could even imagine using user services on a server that has proper users that work on that server. Please, whatever you do, do not replace the current service. Add the user service as a choice, but do not get rid of the current implementation. |
The same reason you don't run the service with root priviledges. Even if you don't care, it could be useful if:
I didn't face any issues with it.
Of course not. Both system and user services are useful and have their advantages. This MR only adds a new service file, it does not remove the existing one. I don't see any reason not to ship both. |
That I understand. However, when administering a server manually, I hardly use a user and run all commands with
Nice. This is good news.
Perfect. Thanks. |
Some more thoughts regarding this:
|
Well, you can use the service on desktop instead of a "dumb" autostart. But this scenario is probably uncommon.
It is not our job to explain how systemd works imo, it has its own documentation. Could be mentioned somewhere like the wiki page though.
There is no difference between system and user services in this regard. Both need to be enabled after install, both need to be reloaded on update. |
I'd argue that there is a certain practice in providing a systemd service example with stuff like qBittorrent without a lot of additional documentation since these service files are nearly always system based service files. So you can somewhat expect a user to know about daemon-reloading, enabling a new service and be done with it. It's common practice. In my view this changes when you introduce a user based service file. Not a lot of users will have heard about systemd lingering, how to enable it and the required If we agree that most users will use systemd service files with qBittorrent to enable automatic startup at boot, introducing this new service example on its own without additional details would not help a lot. One could argue, why then provide a service example for this in the first place? If we expect the user to learn about this by themselves, they might as well write the service file too :-) |
I guess it is more for users wanting a user service specifically for some reason. They probably know what they are doing at this point.
That's also true. People who understand systemd services are also probably capable of writing their own. I would say this is a "why not" thing. |
It will makes a lot of common sense to offer a default systemd.service template file, even if the user(s) might be able to write there own. They a no reasons to reinvent the wheel twice, and if their/when some things changes, you only need to make the change in one place rather than for n installations. I vote for this MR as I have two cases where I find the system vs the users systemd useful. The ~/.config/systemd is useful eg. when you are using shared storage I would ensure the u|gid on the files are equal over the network for eg shared drives. |
The qbittorrent-nox@.service was introduced by
e00c96d. This system-level unit uses User= to change into a specific user, and qbittorrent will access cache and database files in that user's home.
This is a very bad design, because systemd offers a better solution called systemd-user. It makes units specific to the current user run completely under the user service manager, so there is no need to do User= in the system unit anymore.
The current approach breaks service dependencies because my home directory is dynamically mounted by systemd-homed upon logon, which is unavailable when qbittorrent-nox@.service was started, rendering the service to dump its core. By moving the unit to systemd-user, systemd handles all dependencies perfectly since the user unit is only going to be started when the home directory is mounted.
This patch preserves compatibility with existing setups as it does not delete the previous qbittorrent-nox@.service.