Steffen Dettmer <steffen.dett...@gmail.com> writes: > So you propose not to use init.d scripts. I usually prefer a simple shell > script that is easy to test, systemd is just way to complex. But probably > for Debian you are right, if I understood correctly, newer versions do not > even support init.d / LSB anymore, so using systemd units seems to be > required there.
Like Greg says, systemd units are really much simpler. The thing with the compatibility mode is that that part has do *guess* what the init.d tries to call and adapt that to its inner working and can fail. it's documentation with Debian 9 (stretch) is in man:systemd-sysv-generator(8), but it's also so short that it would probably not help. furthermore quoting from "man systemd.service": NOTES 1. Incompatibilities with SysV http://www.freedesktop.org/wiki/Software/systemd/Incompatibilities and from the referenced doc: "If your distribution removes SysV init scripts in favor of systemd unit files typing "/etc/init.d/foobar start" to start a service will not work, since the script will not be available. Use the more correct "/sbin/service foobar start" instead, and your command will be forwarded to systemd." There are many more details on that page and maybe buried in there is a hint why the init.d you have does not work. > About your gitlab-runner.service failure: >> >> https://wiki.debian.org/systemd#Failed_units >> HINT: Extensive debugging information about systemd is on this >> FreeDesktop page. https://freedesktop.org/wiki/Software/systemd/Debugging/ > > > I didn't find anything about init.d or DPKG_MAINTSCRIPT_PACKAGE in these > pages. Correct, as they are about systemd units/services/timers etc. > Only I found using "status", but this does not help either: > > root@node17-0:/etc/init.d# systemctl status gitlab-runner2.service > - gitlab-runner2.service > Loaded: not-found (Reason: No such file or directory) > Active: inactive (dead) Was the ...-runner2 intentional? Your other quoted error showed "gitlab-runner.service". > funny that it does not even tell WHICH file was not found and why it was > loaded anyway. Yeah, that's probably jessies ancient systemd at fault. Newer output is more detailed and looks like that: server:/etc/apt/sources.list.d# systemctl status atd.service ● atd.service - Deferred execution scheduler Loaded: loaded (/lib/systemd/system/atd.service; enabled; vendor preset: enabled) Active: active (running) since Wed 2019-07-24 04:48:30 CEST; 2 months 29 days ago Docs: man:atd(8) Main PID: 570 (atd) (...) > There is no such file "gitlab-runner.service" (I tried "find /etc" and > "locate"). > It seem that some systemd magic applies here. Maybe, if its content is > needed for technical reasons, systemd creates some "virtual unit" on the > fly, who knows. There is also a possible gitlab-runner@.service file to check, for the indeed rather magic stuff from systemd. Did you install gitlab as whole from packages or from source? Is the gitlab-runner version compatible to the other parts? Did you use the gitlab runner packages from the gitlab repo? https://docs.gitlab.com/runner/install/linux-repository.html Debian 8 should be jessie, so supported until summer if i get that page correctly, and remember the codename to version number correct. Where did you get the init.d file from? Can you put it in a gist or pastebin? Hmm, strange apparently there is a correct runner service in play when the installer parts find systemd: https://docs.gitlab.com/runner/configuration/init.html " The system services of GitLab Runner GitLab Runner uses the Go service library to detect the underlying OS and eventually install the service file based on the init system. Note: service will install / un-install, start / stop, and run a program as a service (daemon). Currently supports Windows XP+, Linux/(systemd | Upstart | SysV), and macOS/Launchd. Once GitLab Runner is installed, the service file will be automatically be created: systemd: /etc/systemd/system/gitlab-runner.service upstart: /etc/init/gitlab-runner" Annoying that those are generated and not packaged. Try to share them with us also, so we may to look for errors in there Peter