-
Notifications
You must be signed in to change notification settings - Fork 39
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
Document how to run at startup / restart #4
Comments
For my contribution, it would be easier to ship the systemd unit file with the program, and add instructions on how to install the unit file, configuration files and how to use them. |
The possible problem if it is shipped with the program is that each user can extract/install it in a different path, use a different user/group, and/or put config file(s) in different paths. Therefore, it is difficult to provide a solution that fits all the use cases without requiring manual intervention. That's why I think that it is desirable to add the content in filebrowser/filebrowser#411 to the web page (probably in Installation -> systemd), and provide some additional references for users to tailor it to their needs. Alternatively, a default setup can be added to the one-step script ( |
The file in filebrowser/filebrowser#411 is concrete. It is supposed to be copied to the systemd unit directory (e.g. |
These three params in that file are concrete, but not portable:
More precisely, the default install path with the one-step script is Nevertheless, copying the file to |
The This file can be generated in the installation step by filling in the actual installation location and guessed Web server user and group using this template. The |
I also suggest to change to:
This way you don't need to specify |
|
Close filebrowser/filebrowser#411, filebrowser/filebrowser#418 and filebrowser/filebrowser#453.
In the issues referred above, and in the references in them, multiple alternatives are given:
--restart always
: Run in Start filebrowser#453 (comment)It'd be interesting to have a short section in the web page (or maybe some hints spread in existing ones) to summarize the suggested alternatives. I think that the most relevant for this use case are systemd, screen/tmux and docker.
@yurividal, @xcvista would you like to contribute?
The text was updated successfully, but these errors were encountered: