Hi, thanks for your reply.
On Tue, Oct 22, 2019 at 5:45 AM Peter Wiersig <pe...@friesenpeter.de> wrote: > 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. > > Like Greg says, systemd units are really much simpler. > Thank you for your opinion. I'm sure it is fully true in your context. > 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. > Not sure if on topic, but I what is needed to guess, it should run the scripts in order of their rcX/Snn number? I though the difficulty would be to use a suited nn number (and in fact, if my init.d script would get started at all it won't work because of a missing user as it is started before pam ldap - this are places where I expect problems, not at the attempt to run or not at all). it's documentation with Debian 9 (stretch) is in > "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." > In my case, the script does exist and I can call it manually. The problem is that it sources lsb functions that source "hooks" which includes some s40systemd-wrapper (or such) which calls "exit 0" instead of letting the sourcing script continue. Unless DPKG_MAINTSCRIPT_PACKAGE is set. > 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. > Technically it is clear, because some sourced systemd script calls some exit 0, since sourced, it does not terminate the sourced script, but also the calling script. Maybe it is a bug that it exits. Maybe it is a bug that it exits in my situation. I noticed that it does not exits when DPKG_MAINTSCRIPT_PACKAGE is set. This suggests me that there must be some trick (even if fragile). (Since its not most recent and systemd I think it makes no sense to file a bug report, I just tried to understand and get it working). >> 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. > (These places were mentioned as points where to read, I just told that I read them but still did not understand whats happening and especially if it is a bug, or what kind of bug I'm facing) So although systemd is assumed to be simple, my issue "just start a script" still isn't solved, even with all the help from this list, so I think under the hood things are more complex than they seem to be. > 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". > Yes, it was. I patched the gitlab-runner script to set DPKG_MAINTSCRIPT_PACKAGE, and installed a gitlab-runner2 without that. > > 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. systemd is from 2010, so in Debian 8 it should be somewhat stable already I think. > 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) > (...) > I think in Debian 8 / Jessie it looks the same, IF it works. Here my problem is, that it does NOT work :( But as already said, maybe with systemd its impossible to get init.d script running correclty so that I need to write such a unit file (using Devuan is no option here). > 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. > This sounds like a way where I possibly should dig in deeper? > Did you install gitlab as whole from packages or from source? well... it's complicated... Let's take "gitlab-runner" as a placeholder (I better had replaced it by "myscript"). > Where did you get the init.d file from? Can you put it in a gist or > pastebin? > I don't have access to this server at the moment (too many firewalls in front :)), but I think a script like: --------------------- ### BEGIN INIT INFO # Provides: scriptname # Required-Start: $remote_fs $syslog # Required-Stop: $remote_fs $syslog # Default-Start: 2 3 4 5 # Default-Stop: 0 1 6 # Short-Description: Start daemon at boot time # Description: Enable service provided by daemon. ### END INIT INFO . /lib/lsb/init-functions echo "$0 called with $@" --------------------- should be sufficient, because the " . /lib/lsb/init-functions" leads to a call to exit which terminates the whole script before the "echo". 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 Yes, this might be the case, however this requires a very huge binary to be ran as root on a system where it is not wanted. Also, just in case someone is interested, this gitlab-runner then runs as root (not as user, even if using "install --user gitlabrunner"), which in my particular case is also considered wrong. But I think all this actually is off-topic, I just tried to understand how to run an init.d script, because I assumed this is possible as systemd documentation suggests. Of course now I'm beyond the time needed to otherwise solve the issue, but I'm curious and tried to understand what I observe and especially the role of the environment variable DPKG_MAINTSCRIPT_PACKAGE, which seems to deeply change the effects but apparently is undocumented. I read in the scripts what happens but I fail to see why. Steffen
