Flexget added daemon support from version 1.2. This patch aims to control Flexget daemon adding init.d support. There are two files: 1) flexget-1.2.31: init.d script to control Flexget daemon, should be copied in $PORTAGE_DIR/net-misc/flexget/files 2) flexget-1.2.31.ebuild.patch: patch to apply to the current ebuild.
Created attachment 367792 [details] Flexget init.d script
Created attachment 367794 [details, diff] Flexget-1.2.31 ebuild patch
Sounds like a good idea.
This init script would start flexget as root, which is a really bad idea. I'm not really sure it makes sense to create a dedicated "flexget" user either; most people probably run flexget under their own user account and the configuration lives in $HOME/.flexget.
I don't know how most of the users have it configured, but I was wondering if this could be a good aproach: - Create user flexget - Create symbolic link of configuration file to /etc/conf /home/flexget/.flexget/config.yml -> /etc/conf.d/flexget or /home/flexget/.flexget/config.yml -> /etc/flexget/config.yml - Modify the current init script to run as user flexget If most of the users run it from their own user (instead of via flexget), could we post a non-complete init script or is this solution a little bit dirty. I mean to post the init script modified to be run as user nobody and modify the ebuild to post a message at the end, telling the user to modify it if he/she wants to use the init script to handle flexget daemon.
(In reply to Peter from comment #5) I think I would prefer the second option (incomplete init script). We could just have the init script error out if a user name has not been set in a variable in /etc/conf.d/flexget.
Created attachment 367886 [details] Flexget init.d script Updated version of init.d script to support custom user/configuration
Created attachment 367888 [details] Flexget conf.d script Basic configuration file needed to run the init.d script
Created attachment 367890 [details, diff] Flexget-1.2.31 ebuild patch Added conf.d file as well as a message to let know the user he/she needs to edit the configuration file before using the init.d script.
(In reply to Mike Gilbert from comment #6) Ok, I think with the actual patches and new files it should work as intended: - The init.d script won't start with the actual conf.d file (unconfigured) - The user can configure the conf.d file to start the daemon with the correct user/configuration. Of course, any feedback is always welcome.
