On 06/10/2016 07:54 AM, Andrew McGlashan wrote:
> I want the script to run once only at bootup, before exim4 and also
> before dovecot, it isn't a service; but I've moulded the script to
> appear like one in order to achieve the desired result. And there is no
> need to run it ever again after startup and there is nothing to do at
> shutdown.
Well, then your script is far too complicated in a sense.
You could easily do the following:
-----------------------------------------------------------------------
#!/bin/sh
# LSB header stuff (what you have now)
case "$1" in
start) ;;
stop|status|restart|force-reload) exit 0 ;;
*) echo "Usage: $SCRIPTNAME start" >&2; exit 3 ;;
esac
set -x
# now your actual script, without all the other stuff
-----------------------------------------------------------------------
The log_daemon_msg is just to show a pretty message at boot (if the
verbosity level is set correctly), you don't _need_ that for an init
script, you can also just echo stuff in there (which you appear to be
doing anyway). And you can drop the other stuff from the init script
template.
The template just makes sure that the init script fits nicely into
Debian's typical scheme for services (with the messages having a
uniform look and feel at boot), but the absolute minimum actual
requirements for an init script (in Debian) are:
- have an LSB header
- properly treat the arguments start, stop, status, restart and
force-reload
So as long as your script does just that, it will work, once you
install it via update-rc.d defaults.
> I couldn't use /etc/rc.local as that would act after everything was up
> and running normally. Probably I really should have the script
> somewhere else, but I'm not sure where exactly would be best. Hence why
> it ended up in the initscript area. Perhaps people have some other
> suggestions? I would be happy to hear them here.
Well, I would maybe put in in /usr/local/sbin, and have the init script
call the script itself. Then the init script is just the glue to make
it work (see my above example, where after set -x you could just call
the script in /usr/local/sbin) and rather easy to understand (because
it's short), whereas the actual script you call an own script that you
can test separately.
That way, you separate out program logic (what you want to do) and
configuration (when you want to do it). I do the same for cron jobs: I
create a script in /usr/local/sbin, and have the cron job call that
script instead of writing it directly into the crontab.
> On 10/06/2016 7:29 AM, Christian Seiler wrote:
>> The main problem with this scheme alone is that the numbers are
>> actually really arbitrary, so it's not immediately clear which ones to
>> use when writing an init script.
>
> Not arbitrary... I numbered them according to the desired sequence,
> knowing myself which processes needed to be started before others.
Well sure, but whether you should give exim4 the number 20 or 25 is
arbitrary, as long as the number is higher than e.g. your syslog
implementation's number, etc.
So from the point of view of someone writing a service that is supposed
to work on multiple systems (e.g. Debian), the number is arbitrary to a
large extent - until you have a new service that creates an additional
dependency between two previously unrelated services.
> So, by design of the chosen numbers and script names, I was previously
> able to run scripts in the order that I knew was required by my own
> resolve and dependencies were not complex enough to require /special/
> processing outside my own resolve.
Sure, if you want to create all the symlinks in the correct ordering on
your very own, that will work. Especially if you have to modify the
default because the Debian ordering doesn't suite your needs - and
update a lot of symlinks. But I actually don't care about any specific
numbers in front of stuff, I care about the real order stuff is
executed in.
And for me at least (and for very many other people, which is why
Debian moved to dep-based booting with Squeeze), it's _much_ more
logical to declare dependencies and have the system then decide for
itself about ordering. As I said in my earlier mail: anything that
doesn't properly support dependencies isn't worth my time in looking
at it, because they make life _so_ much easier.
Btw. if you want to override the ordering of scripts that come with
Debian without modifying the scripts themselves, you can actually place
JUST the entire LSB header of a script in /etc/insserv/overrides, for
example /etc/insserv/overrides/exim4. Then, insserv will use that
header INSTEAD of the one found in the init script to calculate
dependencies. This is great if you need to introduce a new ordering
constraint between services that Debian doesn't know about. [1]
> I still have low numbers, but done the correct way via insserv.
So I figured out why on the wheezy box I looked at the numbers were
higher: there, rpcbind and nfs-common were installed, which were
installed into both rcS and rc[2345]. This means that they synchronize
the numbers between both directories, and leave a large gap in rc[2345]
(because most stuff there is ordered after $remote_fs, which is ordered
after nfs-common). But on a system without these packages (e.g. my
Jessie desktop), the numbers are again lower in rc[2456].
So the low numbers were not the problem, but something else. Possibly
the fact that you didn't implement the status argument AND used
startpar, but I'm not sure.
Regards,
Christian
[1] Caveat though for other readers: if you use systemd, that will only
work in Jessie, not in Stretch anymore. systemd uses the LSB
headers in init scripts to determine dependencies between services
itself. However, upstream systemd doesn't support reading overrides
though. The Debian systemd maintainers were kind enough to merge a
patch to support that for Jessie for compatibility reasons, but
said they didn't want to support that patch indefinitely. And since
systemd provides its own means to override dependencies, you will
need to use those instead of /etc/insserv/overrides to do so when
using systemd in Stretch onwards. As more and more services now
have a systemd service file in addition to their init script, this
is required anyway, because even in Jessie the overrides are only
considered for init scripts that don't have a corresponding systemd
service. sysvinit+initscripts in Stretch still fully supports these
types of overrides, though.
Attachment:
signature.asc
Description: OpenPGP digital signature