We need a systemd service’s unit file to start/stop misc/background_jobs_worker.pl, like we do with the debian packages in debian/scripts/koha-worker
I'll add it to my TODO list :D
(In reply to David Cook from comment #1) > I'll add it to my TODO list :D Move it up please ;)
(In reply to Jonathan Druart from comment #2) > Move it up please ;) Noted! Exciting!
Created attachment 111262 [details] [review] Bug 26363: Provide a systemd unit file for koha-worker for source installs This patch adds a systemd unit file which gets rewritten according to the configuration specified by Makefile.PL. This can be linked or copied to systemd directories for running a systemd service for background_jobs_worker.pl Test plan: 1. perl Makefile.PL 1a. Choose "single" installation 1b. Choose "/opt/koha" for a file path 2. make 3. vi blib/KOHA_CONF_DIR/koha-worker.service 4. Verify that PERL5LIB, KOHA_CONF, ExecStart, and SyslogIdentifier all appear to be correctly filled in
Created attachment 111263 [details] [review] Bug 26363: Provide a systemd unit file for koha-worker in package installs While the packages already have a koha-zebra script that creates a service using the 'daemon' utility, this unit file template provides an alternative. Note that currently you'd have to start the service using the following: ```systemctl start koha-worker@NAME.service``` Where NAME is the name of your Koha instance. The systemctl enable/start commands could be automated more with helper scripts in debian/scripts, but this is a first step.
Probably will need to do something like https://bugs.koha-community.org/bugzilla3/page.cgi?id=splinter.html&bug=20582&attachment=111374 to remove the systemd unit file for source installs when doing packaging...
(In reply to David Cook from comment #5) > Created attachment 111263 [details] [review] [review] > Bug 26363: Provide a systemd unit file for koha-worker in package installs > To test this on koha-testing-docker, you should be able to do something like the following: ```cp debian/templates/koha-worker@.service /etc/systemd/system/.``` ```systemctl start koha-worker@kohadev.service```
(In reply to David Cook from comment #7) > (In reply to David Cook from comment #5) > > Created attachment 111263 [details] [review] [review] [review] > > Bug 26363: Provide a systemd unit file for koha-worker in package installs > > > > To test this on koha-testing-docker, you should be able to do something like > the following: > > ```cp debian/templates/koha-worker@.service /etc/systemd/system/.``` > ```systemctl start koha-worker@kohadev.service``` Except that won't work because koha-testing-docker is a Docker container without the systemd init system. You should be able to do this using kohadevbox though or some other Linux environment.
Created attachment 113450 [details] [review] Bug 26363: Provide a systemd unit file for koha-worker for source installs This patch adds a systemd unit file which gets rewritten according to the configuration specified by Makefile.PL. This can be linked or copied to systemd directories for running a systemd service for background_jobs_worker.pl Test plan: 1. perl Makefile.PL 1a. Choose "single" installation 1b. Choose "/opt/koha" for a file path 2. make 3. vi blib/KOHA_CONF_DIR/koha-worker.service 4. Verify that PERL5LIB, KOHA_CONF, ExecStart, and SyslogIdentifier all appear to be correctly filled in Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
Here is one patch signed off at least ^^
Created attachment 113461 [details] [review] Bug 26363: Provide a systemd unit file for koha-worker in package installs While the packages already have a koha-zebra script that creates a service using the 'daemon' utility, this unit file template provides an alternative. Note that currently you'd have to start the service using the following: ```systemctl start koha-worker@NAME.service``` Where NAME is the name of your Koha instance. The systemctl enable/start commands could be automated more with helper scripts in debian/scripts, but this is a first step. Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net>
It works!
Note: I think Victor needed to update his kohadevbox to use koha_use_custom_repo so that it would use the koha-staging apt repo that is used by default in koha-testing-docker
Indeed, I forgot to post the info Here was custom config for my devbox koha_custom_repo_origin: debian.koha-community.org koha_custom_repo: "[trusted=yes] http://{{ koha_custom_repo_origin }}/koha-staging dev" koha_custom_repo_has_key: no koha_custom_repo_key: koha_custom_repo_distribution: stretch koha_use_custom_repo: yes There was a bit of guesswork, not sure if had to use koha_custom_repo. So likely not a clean way. Issue reported: https://gitlab.com/koha-community/kohadevbox/-/issues/309
We really need this part of 20.11 IMO
(In reply to Jonathan Druart from comment #15) > We really need this part of 20.11 IMO Agreed.
1. Those 2 lines are not equivalent: debian/templates/koha-worker@.service:SyslogIdentifier=koha-worker_%i etc/koha-worker.service:SyslogIdentifier=koha-worker-__DB_NAME__ 2. Should not it be $instance-koha-worker instead, to match what we have in: debian/scripts/koha-functions.sh: if daemon --name="$instancename-koha-worker" \
(In reply to Jonathan Druart from comment #17) > 1. Those 2 lines are not equivalent: > debian/templates/koha-worker@.service:SyslogIdentifier=koha-worker_%i > etc/koha-worker.service:SyslogIdentifier=koha-worker-__DB_NAME__ > That's because koha-worker@.service is a template file. When invoked using ```systemctl start koha-worker@NAME.service```, %i will have NAME in it. This could be used by koha-create. For source installs, I was thinking that people would just copy or symlink the built file from the Koha installation directory to /etc/systemd/system, so they'd want to have the name hard-coded into the unit file. We could use a systemd template for source installs too and then just given an instruction to copy the template to /etc/systemd/system and then use ```systemctl start koha-worker@NAME.service```. It would make things more consistent. > 2. Should not it be $instance-koha-worker instead, to match what we have in: > debian/scripts/koha-functions.sh: if daemon > --name="$instancename-koha-worker" \ I don't understand the question. What do you mean by "it" in your question? The SyslogIdentifier could be done like $instancename-koha-worker, but not the systemd unit. It needs to start with a set name. Here's an example that I use locally already: systemctl status "koha-mq*" ● koha-mq-scheduler@EXAMPLE.service - Koha Message Queue Work Scheduler Loaded: loaded (/etc/systemd/system/koha-mq-scheduler@.service; indirect; vendor preset: enabled) Active: active (running) since Sun 2020-11-22 19:33:35 AEDT; 3 days ago Main PID: 23226 (mq_scheduler.pl) Tasks: 1 (limit: 4915) CGroup: /system.slice/system-koha\x2dmq\x2dscheduler.slice/koha-mq-scheduler@EXAMPLE.service └─23226 /usr/bin/perl /usr/share/koha/bin/prosentient/mq_scheduler.pl -v Nov 22 19:33:35 koha1911 systemd[1]: Started Koha Message Queue Work Scheduler. At the moment, I only have one koha-mq-scheduler unit running on that server, but if there were others, that systemctl command would've listed them all.
(In reply to David Cook from comment #18) > (In reply to Jonathan Druart from comment #17) > > 2. Should not it be $instance-koha-worker instead, to match what we have in: > > debian/scripts/koha-functions.sh: if daemon > > --name="$instancename-koha-worker" \ > > I don't understand the question. What do you mean by "it" in your question? $instancename-koha-worker vs koha-worker-__DB_NAME__
(In reply to Jonathan Druart from comment #19) > (In reply to David Cook from comment #18) > > (In reply to Jonathan Druart from comment #17) > > > 2. Should not it be $instance-koha-worker instead, to match what we have in: > > > debian/scripts/koha-functions.sh: if daemon > > > --name="$instancename-koha-worker" \ > > > > I don't understand the question. What do you mean by "it" in your question? > > $instancename-koha-worker vs koha-worker-__DB_NAME__ But in what context? Is it just in terms of the following? debian/templates/koha-worker@.service:SyslogIdentifier=koha-worker_%i etc/koha-worker.service:SyslogIdentifier=koha-worker-__DB_NAME__ If so, it would be trivial to do "__DB_NAME__-koha-worker" and "%i_koha-worker" instead, if that's what you mean?
Should this be "In discussion" or "Failed QA" or...?
(In reply to David Cook from comment #20) > (In reply to Jonathan Druart from comment #19) > > (In reply to David Cook from comment #18) > > > (In reply to Jonathan Druart from comment #17) > > > > 2. Should not it be $instance-koha-worker instead, to match what we have in: > > > > debian/scripts/koha-functions.sh: if daemon > > > > --name="$instancename-koha-worker" \ > > > > > > I don't understand the question. What do you mean by "it" in your question? > > > > $instancename-koha-worker vs koha-worker-__DB_NAME__ > > But in what context? Is it just in terms of the following? > > debian/templates/koha-worker@.service:SyslogIdentifier=koha-worker_%i > etc/koha-worker.service:SyslogIdentifier=koha-worker-__DB_NAME__ > > If so, it would be trivial to do "__DB_NAME__-koha-worker" and > "%i_koha-worker" instead, if that's what you mean? Yes, it is what I meant. Do you agree?
(In reply to Jonathan Druart from comment #22) > > If so, it would be trivial to do "__DB_NAME__-koha-worker" and > > "%i_koha-worker" instead, if that's what you mean? > > Yes, it is what I meant. Do you agree? I don't really care, so that sounds fine to me.
(In reply to David Cook from comment #8) > Except that won't work because koha-testing-docker is a Docker container > without the systemd init system. > Actually, if we start the docker container as a privileged container, we should be able to launch using /lib/systemd/systemd but then we'd need to change the koha-testing-docker command but that would also be a hassle.
(In reply to David Cook from comment #24) > (In reply to David Cook from comment #8) > > Except that won't work because koha-testing-docker is a Docker container > > without the systemd init system. > > > > Actually, if we start the docker container as a privileged container, we > should be able to launch using /lib/systemd/systemd but then we'd need to > change the koha-testing-docker command but that would also be a hassle. Note that I've never actually used systemd in a Docker container except for when using Red Hat's ubi8 ubi-init image: https://catalog.redhat.com/software/containers/ubi8/ubi-init/5c359b97d70cc534b3a378c8?container-tabs=dockerfile There's more interesting reading here about trying to run systemd without a privileged container: https://developers.redhat.com/blog/2016/09/13/running-systemd-in-a-non-privileged-container/
Created attachment 114831 [details] [review] Bug 26363: Change SyslogIdentifier to match koha-worker script style This patch changes the SyslogIdentifier so that it matches the style used by koha-worker.
Created attachment 116203 [details] [review] Bug 26363: Provide a systemd unit file for koha-worker for source installs This patch adds a systemd unit file which gets rewritten according to the configuration specified by Makefile.PL. This can be linked or copied to systemd directories for running a systemd service for background_jobs_worker.pl Test plan: 1. perl Makefile.PL 1a. Choose "single" installation 1b. Choose "/opt/koha" for a file path 2. make 3. vi blib/KOHA_CONF_DIR/koha-worker.service 4. Verify that PERL5LIB, KOHA_CONF, ExecStart, and SyslogIdentifier all appear to be correctly filled in Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net> Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Created attachment 116204 [details] [review] Bug 26363: Provide a systemd unit file for koha-worker in package installs While the packages already have a koha-zebra script that creates a service using the 'daemon' utility, this unit file template provides an alternative. Note that currently you'd have to start the service using the following: ```systemctl start koha-worker@NAME.service``` Where NAME is the name of your Koha instance. The systemctl enable/start commands could be automated more with helper scripts in debian/scripts, but this is a first step. Signed-off-by: Victor Grousset/tuxayo <victor@tuxayo.net> Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Created attachment 116205 [details] [review] Bug 26363: Change SyslogIdentifier to match koha-worker script style This patch changes the SyslogIdentifier so that it matches the style used by koha-worker. Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
I'll admit, I'm not an expert in this area.. However, the unit files look as I would expect and work as I would expect.. I think we will only uncover edge cases at this point if we push them... So.. Passing QA
Pushed to master for 21.05, thanks to everybody involved!
koha-worker will run as root. Shouldn't we run as koha user for package install, as www-data for dev install ?
Pushed to 20.11.x for 20.11.04
(In reply to Fridolin Somers from comment #32) > koha-worker will run as root. > Shouldn't we run as koha user for package install, as www-data for dev > install ? Good call.. can't believe I didn't spot that!
(In reply to Martin Renvoize from comment #34) > (In reply to Fridolin Somers from comment #32) > > koha-worker will run as root. > > Shouldn't we run as koha user for package install, as www-data for dev > > install ? > > Good call.. can't believe I didn't spot that! I added to koha-worker.service : [Service] User=www-data
Also maybe needs Type=forking ? https://www.freedesktop.org/software/systemd/man/systemd.service.html#Type=
(In reply to Fridolin Somers from comment #36) > Also maybe needs Type=forking ? > > https://www.freedesktop.org/software/systemd/man/systemd.service.html#Type= I don't think so since it doesn't fork when it starts.
(In reply to Martin Renvoize from comment #34) > (In reply to Fridolin Somers from comment #32) > > koha-worker will run as root. > > Shouldn't we run as koha user for package install, as www-data for dev > > install ? > > Good call.. can't believe I didn't spot that! Good catch, Frido. Yes, the package install should be "%i-koha". As for a source/dev install, I'm not 100% sure what it should be. I suppose it depends on what the background worker needs to do. In theory, www-data shouldn't be needed, but I suppose there might be something that the web server has written as www-data which the background worker needs to manage?
(In reply to David Cook from comment #38) > As for a source/dev install, I'm not 100% sure what it should be. I suppose > it depends on what the background worker needs to do. In theory, www-data > shouldn't be needed, but I suppose there might be something that the web > server has written as www-data which the background worker needs to manage? Source/dev installs require extra work anyway so that one might be solved by documentation...
(In reply to David Cook from comment #39) > (In reply to David Cook from comment #38) > > As for a source/dev install, I'm not 100% sure what it should be. I suppose > > it depends on what the background worker needs to do. In theory, www-data > > shouldn't be needed, but I suppose there might be something that the web > > server has written as www-data which the background worker needs to manage? > > Source/dev installs require extra work anyway so that one might be solved by > documentation... I agree. Keep in mind that some files will be used by both koha-worker and starman. Like tempate cache or sessions in temporary files.
Created attachment 117630 [details] [review] Bug 26363: Remove tmp file during package build (follow-up)
follow-up pushed to master.
(In reply to Jonathan Druart from comment #42) > follow-up pushed to master. hi Frido, can you push to 20.11 too
(In reply to Mason James from comment #43) > (In reply to Jonathan Druart from comment #42) > > follow-up pushed to master. > > hi Frido, can you push to 20.11 too Bug 26363: Remove tmp file during package build (follow-up) Pushed to 20.11.x for 20.11.04
Missing dependency, not pushed to 20.05.