mirror of
https://github.com/qbittorrent/qBittorrent.git
synced 2026-03-02 22:57:32 -05:00
Support systemd socket activation #2927
Labels
No labels
Accessibility
AppImage
Bounty
Build system
CI
Can't reproduce
Code cleanup
Confirmed bug
Confirmed bug
Core
Crash
Data loss
Discussion
Docker
Documentation
Duplicate
Feature
Feature request
Feature request
Feature request
Filters
Flatpak
GUI
Has workaround
I2P
Invalid
Libtorrent
Look and feel
Meta
NSIS
Network
Not an issue
OS: *BSD
OS: Linux
OS: Windows
OS: macOS
PPA
Performance
Project management
Proxy/VPN
Qt bugs
Qt6 compat
RSS
Search engine
Security
Temp folder
Themes
Translations
Triggers
Waiting diagnosis
Waiting info
Waiting upstream
Waiting web implementation
Watched folders
WebAPI
WebUI
autoCloseOldIssue
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/qBittorrent#2927
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @fsateler on GitHub (Aug 11, 2015).
As noted in #554, currently qbittorrent-nox can be currently exited from the web ui, but this means that one needs to ssh in to the server to restart the service if I exit the program.
This could be improved by leveraging the socket activation for the web ui port. Systemd can start a service when a connection is received on a given port, and then passes the service the open socket. This would enable starting the program by just accessing the Web UI url.
See this post, example 3 for a simple example implementation with support for both socket and normal activation.
I suggest setting a special parameter to
--webui-port(eg,inherit) to allow qbittorrent to detect if it should try to use the socket activation, and to fail if it is not received (to prevent qbittorrent from racing with systemd for the port).@depau commented on GitHub (Aug 26, 2015):
I would like this feature added too. It works this way for CUPS and other headless servers as well.
@fsateler commented on GitHub (Nov 15, 2015):
I have taken a stab at implementing this. Unfortunately, I cannot present a full PR because I did not manage to navigate qmake to conditionally link to libsystemd. But the code change itself is very small:
A bit of explanation.
sd_listen_fdsreturns the number of file descriptors systemd is listening on for us. If we have exactly 1 socket, then use that instead of opening our own port. This effectively ignores the webui port configuration. The parameter is 0 so that if a WebUI class is reinstantiated we still get the systemd-activated fd. This can be changed so that only the first instance inherits the fd by setting it to 1, then future calls will return 0.SD_LISTEN_FDS_STARTis always the first socket passed via activation. Other sockets would be pased asSD_LISTEN_FDS_START+1, etc, but we only care about one.Systemd does not care if the socket is closed when the program exits.
To use, you can add the following socket file:
@fsateler commented on GitHub (Feb 18, 2016):
ping. If you can give me some guidance on how to make qmake detect if a library is available and add appropriate defines in that case, I can prepare a PR for this.
thanks
@zeule commented on GitHub (Jan 11, 2017):
@fsateler qmake can not do that, that is why it is used with autotools.
You can add a switch to
configure.acor cmake files, or use the existing one for systemd. Then inconfigure.acappend library toLIBSvariable (see boost example).@sledgehammer999 commented on GitHub (Oct 29, 2020):
This issue has been closed and locked for being too old, and thus either most likely resolved in recent versions or no longer applicable.
If you experience the reported problem or similar in the latest version, please open a new issue report with the requested information in the issue template.
A new issue report with relevant updated data gathered from the latest version is preferable to necroing an old report with a comment like "still happens in version x.y.z", even if you think the bug is the same, or suspect of a regression.
Due to the changes made to the qBittorrent code and its dependencies over time, the exact cause of your problem could be totally different than the original one, despite the visible symptoms of the bug being similar.
Thus, providing relevant updated information is crucial to find and fix the root cause of a recurrent problem or regression.
Thank you for your contributions.