Steffen Dettmer <steffen.dettmer@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