Linux startup, Wheezy -- a required script won't run on startup, but can run manually without any trouble

classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|

Linux startup, Wheezy -- a required script won't run on startup, but can run manually without any trouble

Andrew McGlashan
Hi,

In the Solaris world and most SYSV systems like it, there was a very
simple startup system; it was not systemd, nor is it the "modern day"
sysvinit.  It was much simpler and worked very, very well and extremely
reliably.  How can we get that back on modern Debian?


I mean simple, just like this:

 - when entering a run level (start passed to each script)

   - run all S scripts in alphanumeric order
     S02xxx before S03xxx and S02aaa before S02aab ...

 - when exiting a run level (stop passed to each script)

   - run all K scripts in alphanumeric order
     K02xxx before K03xxx and K02aaa before K02aab ...


The order of the scripts alone allowed for everything to be very, very
simple and no script relied upon any other; they were self dependent.
If you wanted something to be available before your script, you made
sure your numeric number after the S in the script name (or rather the
symlink name back to the /etc/init.d directory file) was higher.  It was
simple, it worked perfectly, it worked like a standard program would,
sequentially... as I understand it, each script ran in order and the
next script didn't run until the prior one was finished.  This doesn't
allow for streamlining, unless you backgrounded procesess in scripts,
but it was extremely simple and reliable just the same, it got the job
done (even if more slowly than some might like) -- the simpleness and
reliability were the major trump card featuress of the system.


Now I have sysvinit isntalled on wheezy, it is failing to run a simple
script during system boot (as part of a planed reboot) and I cannot work
out why.


# ls -l /etc/{init.d,rc*.d}/*archive*
-rwxr-xr-x 1 root root 1453 Jun  8 04:12 /etc/init.d/archive-system-mail
lrwxrwxrwx 1 root root   29 Jun  3 23:30
/etc/rc2.d/S02archive-system-mail -> ../init.d/archive-system-mail
lrwxrwxrwx 1 root root   29 Jun  4 03:06
/etc/rc3.d/S02archive-system-mail -> ../init.d/archive-system-mail
lrwxrwxrwx 1 root root   29 Jun  4 03:07
/etc/rc4.d/S02archive-system-mail -> ../init.d/archive-system-mail
lrwxrwxrwx 1 root root   29 Jun  4 03:08
/etc/rc5.d/S02archive-system-mail -> ../init.d/archive-system-mail


Now, I want the archiving script to run on system startup, I don't want
dovecot or exim4 to be running when the script starts, it simply needs
to have the /backup and /var file systems mounted to do it's required job.

My script is meant to create a log file in the /var/log directory.  If I
run the script manually, it works perfectly.  There are some generic
parts in the script, it is a fairly simple script, even if a little bit
over complicated.  What do I need to do to fix it?


Here is the script:

# cat /etc/init.d/archive-system-mail
#! /bin/sh
### BEGIN INIT INFO
# Provides:          mailarchive
# Required-Start:    $syslog
# Required-Stop:     $syslog
# Default-Start:     2 3 4 5
# Default-Stop:
# Short-Description: Save exim4 system_filter archive
### END INIT INFO

# Author: Andrew McGlashan <[hidden email]>

set -x

NAME=archive-system-mail
SCRIPTNAME=/etc/init.d/$NAME

do_cleanup()
{
        # Cleanup
        echo -e "\a\a\aPerforming cleanup"
        exit $1
}

error_exit()
{
        # Display error message and exit
        echo "${PROGNAME}: ${1:-"Unknown Error"}" 1>&2
        do_cleanup 1
}

get_archivedir()
{
        for x in a b c d e f g h i j k l m n o p q r s t u v w x y z
        do

ARCHIVE_DIR=/backup/mail/system_filter_all_mail/archive/${DATEX}${x}
                if [ ! -d $ARCHIVE_DIR ]; then VER=$x; return 0; fi
        done
        return 1
}

do_main()
{
        (
        get_archivedir || error_exit "Cannot get archive dir"

        if [ ! -d ${ARCHIVE_DIR} ];then /bin/mkdir $ARCHIVE_DIR;fi
        #/bin/mv /backup/mail/system_filter_all_mail/log--lots $ARCHIVE_DIR/
        #/bin/mv /backup/mail/system_filter_all_mail/Maildir   $ARCHIVE_DIR/
        /usr/bin/touch $ARCHIVE_DIR/log--lots.$$
        /bin/mkdir     $ARCHIVE_DIR/Maildir.$$
        )  2>&1 | /usr/bin/tee /var/log/${PROGNAME}--$(date
+%Y%m%d%H%M%S).log
}

# main
trap "do_cleanup 99" HUP INT TERM

# Global Variables
ARCHIVE_DIR=
DATEX=$(/bin/date +%Y%m%d)
PROGNAME=$(/usr/bin/basename $0)

case "$1" in
  start)
        do_main
        ;;
  *)
        echo "Usage: $SCRIPTNAME {start}" >&2
        exit 3
        ;;
esac

:




Thanks
AndrewM


signature.asc (201 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Linux startup, Wheezy -- a required script won't run on startup, but can run manually without any trouble

Dan Purgert
Andrew McGlashan wrote:

> Hi,
>
> In the Solaris world and most SYSV systems like it, there was a very
> simple startup system; it was not systemd, nor is it the "modern day"
> sysvinit.  It was much simpler and worked very, very well and extremely
> reliably.  How can we get that back on modern Debian?
>
>
> I mean simple, just like this:
>
>  - when entering a run level (start passed to each script)
>
>    - run all S scripts in alphanumeric order
>      S02xxx before S03xxx and S02aaa before S02aab ...
>
>  - when exiting a run level (stop passed to each script)
>
>    - run all K scripts in alphanumeric order
>      K02xxx before K03xxx and K02aaa before K02aab ...

That's pretty much sysvinit right there ... perhaps you're thinking of
"Upstart" as the "modern sysvinit"?

> Now I have sysvinit isntalled on wheezy, it is failing to run a simple
> script during system boot (as part of a planed reboot) and I cannot work
> out why.

What error messages (if any) are you getting?

> Now, I want the archiving script to run on system startup, I don't want
> dovecot or exim4 to be running when the script starts, it simply needs
> to have the /backup and /var file systems mounted to do it's required job

Looks like it might also need syslog running...
>
> My script is meant to create a log file in the /var/log directory.  If I
> run the script manually, it works perfectly.  There are some generic
> parts in the script, it is a fairly simple script, even if a little bit
> over complicated.  What do I need to do to fix it?

Not sure if this is an artifact of how you sent the mail to the group,
but your ARCHIVE_DIR is "3D/backup/[...]".  That's not a valid path.



--
|_|O|_| Registered Linux user #585947
|_|_|O| Github: https://github.com/dpurgert
|O|O|O|

Reply | Threaded
Open this post in threaded view
|

Re: Linux startup, Wheezy -- a required script won't run on startup, but can run manually without any trouble

Brian
In reply to this post by Andrew McGlashan
On Fri 10 Jun 2016 at 03:46:18 +1000, Andrew McGlashan wrote:

> In the Solaris world and most SYSV systems like it, there was a very
> simple startup system; it was not systemd, nor is it the "modern day"
> sysvinit.  It was much simpler and worked very, very well and extremely
> reliably.  How can we get that back on modern Debian?

Present such astoundandly good argumnents for all use cases that the
Debian developer community falls over themselves in admiration and
completely changes direction within hours of receiving your report.

(This is -user. If you have a problem with using stable, please state it
clearly; there are plenty of people who would chip in to help with it.
Otherwise, hobby-horses probably require a different venue. If you do
not have a problem please try to find somewhere which does not require
Debian support).

[...Lots of pseudo-technical stuff snipped...]

Reply | Threaded
Open this post in threaded view
|

Re: Linux startup, Wheezy -- a required script won't run on startup, but can run manually without any trouble

Andrew McGlashan
In reply to this post by Dan Purgert
Hi,

Thanks for your reply.

On 10/06/2016 5:06 AM, Dan Purgert wrote:

> Andrew McGlashan wrote:
>> In the Solaris world and most SYSV systems like it, there was a very
>> simple startup system; it was not systemd, nor is it the "modern day"
>> sysvinit.  It was much simpler and worked very, very well and extremely
>> reliably.  How can we get that back on modern Debian?
>>
>> I mean simple, just like this:
>>
>>  - when entering a run level (start passed to each script)
>>
>>    - run all S scripts in alphanumeric order
>>      S02xxx before S03xxx and S02aaa before S02aab ...
>>
>>  - when exiting a run level (stop passed to each script)
>>
>>    - run all K scripts in alphanumeric order
>>      K02xxx before K03xxx and K02aaa before K02aab ...
>
> That's pretty much sysvinit right there ... perhaps you're thinking of
> "Upstart" as the "modern sysvinit"?
That's what I thought, I have sysvinit.....

# dpkg-query -l|egrep -e '(sysvinit|systemd|upstart)'
ii  libsystemd-login0:amd64            44-11+deb7u4
amd64        systemd login utility library
ii  sysvinit                           2.88dsf-41+deb7u1
amd64        System-V-like init utilities
ii  sysvinit-utils                     2.88dsf-41+deb7u1
amd64        System-V-like utilities


>> Now I have sysvinit isntalled on wheezy, it is failing to run a simple
>> script during system boot (as part of a planed reboot) and I cannot work
>> out why.
>
> What error messages (if any) are you getting?

None, no log is created.  The machine runs within a Xen KVM.  I can't
see any evidence the script is run during startup.

>> Now, I want the archiving script to run on system startup, I don't want
>> dovecot or exim4 to be running when the script starts, it simply needs
>> to have the /backup and /var file systems mounted to do it's required job
>
> Looks like it might also need syslog running...

Perhaps, but why?  I'm not asking it to log anything to syslog; just to
create it's own log file in the /var/log directory.

>> My script is meant to create a log file in the /var/log directory.  If I
>> run the script manually, it works perfectly.  There are some generic
>> parts in the script, it is a fairly simple script, even if a little bit
>> over complicated.  What do I need to do to fix it?
>
> Not sure if this is an artifact of how you sent the mail to the group,
> but your ARCHIVE_DIR is "3D/backup/[...]".  That's not a valid path.

Weird artifcat of something (perhaps GPG due to signing?), my copy as
sent to the list is clean.  The script works perfectly if ran with an
interactive shell; right now the script isn't destructive, so I can run
it as many times as I like and it works fine.  The plan is to adjust the
script, I think you can see how, but not until it works as expected.

Kind Regards
AndrewM


signature.asc (201 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Linux startup, Wheezy -- a required script won't run on startup, but can run manually without any trouble

Andrew McGlashan
In reply to this post by Brian


On 10/06/2016 5:24 AM, Brian wrote:
> Otherwise, hobby-horses probably require a different venue. If you do
> not have a problem please try to find somewhere which does not require
> Debian support).

As per the subject, required script will NOT run and in my message:

<quote>
My script is meant to create a log file in the /var/log directory.  If I
run the script manually, it works perfectly.  There are some generic
parts in the script, it is a fairly simple script, even if a little bit
over complicated.  What do I need to do to fix it?
</quote>

Anyway, best to re-read the original message in full now... ;-)

Thanks
AndrewM


signature.asc (201 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Linux startup, Wheezy -- a required script won't run on startup, but can run manually without any trouble

Brian
On Fri 10 Jun 2016 at 05:29:59 +1000, Andrew McGlashan wrote:

>
>
> On 10/06/2016 5:24 AM, Brian wrote:
> > Otherwise, hobby-horses probably require a different venue. If you do
> > not have a problem please try to find somewhere which does not require
> > Debian support).
>
> As per the subject, required script will NOT run and in my message:
>
> <quote>
> My script is meant to create a log file in the /var/log directory.  If I
> run the script manually, it works perfectly.  There are some generic
> parts in the script, it is a fairly simple script, even if a little bit
> over complicated.  What do I need to do to fix it?
> </quote>
>
> Anyway, best to re-read the original message in full now... ;-)

Your premable was enough:

  In the Solaris world and most SYSV systems like it, there was a very
  simple startup system; it was not systemd, nor is it the "modern day
  sysvinit.  It was much simpler and worked very, very well and extremely
  reliably.  How can we get that back on modern Debian?

Is that the sort of introduction one expexts to see when technical help
is being sought. Stating a problem needn't start with a philosphical
statement.

Reply | Threaded
Open this post in threaded view
|

Re: Linux startup, Wheezy -- a required script won't run on startup, but can run manually without any trouble

Andrew McGlashan


On 10/06/2016 6:02 AM, Brian wrote:

> Your premable was enough:
>
>   In the Solaris world and most SYSV systems like it, there was a very
>   simple startup system; it was not systemd, nor is it the "modern day
>   sysvinit.  It was much simpler and worked very, very well and extremely
>   reliably.  How can we get that back on modern Debian?
>
> Is that the sort of introduction one expexts to see when technical help
> is being sought. Stating a problem needn't start with a philosphical
> statement.
Okay, but philosophical or not; what I had in the Solaris days worked,
it was very reliable.

What I have now is that with some extra "smarts" that stops the original
concept from working as intended.  The smarts is meant to allow for
faster startup and to tie in dependancies; to me, it is trying to be too
smart and that is where the problem lies.

I see within the /etc/init.d/ scripts that there is all this extra junk
at the top and there are .depend.* files in that directory too.  I am
thinking that these extras are the reason why it isn't running the
script at startup as expected.  Those extras weren't not part of the
more original sysv init setup; and, it may be why lots of Debian and
other people decided that the sysvinit was broken (due to the extras)...
and hence why we ended up with systemd.  In any case, I'm not right now
trying to argue for anything in particular even though I've done so in
the past.  Right now, all I want is my script to run as intended and I
need to know how it needs to be adjusted to work.

Thanks
AndrewM



signature.asc (201 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Linux startup, Wheezy -- a required script won't run on startup, but can run manually without any trouble

Dan Purgert
In reply to this post by Andrew McGlashan
Andrew McGlashan wrote:

> On 10/06/2016 5:06 AM, Dan Purgert wrote:
>> Andrew McGlashan wrote:
>>> [snip]
>>> Now, I want the archiving script to run on system startup, I don't
>>> want dovecot or exim4 to be running when the script starts, it
>>> simply needs to have the /backup and /var file systems mounted to do
>>> it's required job
>>
>> Looks like it might also need syslog running...
>
> Perhaps, but why?  I'm not asking it to log anything to syslog; just to
> create it's own log file in the /var/log directory.

Just going off the comments at the top -- states "required-start:
$syslog".  Although, I suppose that you could've just forgotten to
remove that bit.

> [snip]
> Weird artifcat of something (perhaps GPG due to signing?), my copy as
> sent to the list is clean.  The script works perfectly if ran with an
> interactive shell; right now the script isn't destructive, so I can run
> it as many times as I like and it works fine.  The plan is to adjust the
> script, I think you can see how, but not until it works as expected.

How are you calling it while logged in?  I'm starting to wonder if it's
a difference between [da]sh and bash (or whatever your standard login
shell is).  

Also, not entirely sure what the 'VER=$x" assignment is doing, as you
don't seem to read $VER anywhere else.

--
|_|O|_| Registered Linux user #585947
|_|_|O| Github: https://github.com/dpurgert
|O|O|O|

Reply | Threaded
Open this post in threaded view
|

Re: Linux startup, Wheezy -- a required script won't run on startup, but can run manually without any trouble

Andrew McGlashan


On 10/06/2016 6:17 AM, Dan Purgert wrote:
>> Perhaps, but why?  I'm not asking it to log anything to syslog; just to
>> create it's own log file in the /var/log directory.
>
> Just going off the comments at the top -- states "required-start:
> $syslog".  Although, I suppose that you could've just forgotten to
> remove that bit.

I'm sure it can be removed, I started off with the /etc/init.d/skeleton
and tried to work from there when the script didn't run at startup
without the extras at the top.

>> [snip]
>> Weird artifcat of something (perhaps GPG due to signing?), my copy as
>> sent to the list is clean.  The script works perfectly if ran with an
>> interactive shell; right now the script isn't destructive, so I can run
>> it as many times as I like and it works fine.  The plan is to adjust the
>> script, I think you can see how, but not until it works as expected.
>
> How are you calling it while logged in?  I'm starting to wonder if it's
> a difference between [da]sh and bash (or whatever your standard login
> shell is).  
# echo $SHELL
/bin/bash

# /etc/init.d/archive-system-mail start
+ NAME=archive-system-mail
+ SCRIPTNAME=/etc/init.d/archive-system-mail
+ trap do_cleanup 99 HUP INT TERM
+ ARCHIVE_DIR=
+ /bin/date +%Y%m%d
+ DATEX=20160610
+ /usr/bin/basename /etc/init.d/archive-system-mail
+ PROGNAME=archive-system-mail
+ do_main
+ date +%Y%m%d%H%M%S
+ /usr/bin/tee /var/log/archive-system-mail--20160610062530.log
+ get_archivedir
+ ARCHIVE_DIR=/backup/mail/system_filter_all_mail/archive/20160610a
+ [ ! -d /backup/mail/system_filter_all_mail/archive/20160610a ]
+ VER=a
+ return 0
+ [ ! -d /backup/mail/system_filter_all_mail/archive/20160610a ]
+ /bin/mkdir /backup/mail/system_filter_all_mail/archive/20160610a
+ /usr/bin/touch
/backup/mail/system_filter_all_mail/archive/20160610a/log--lots.23380
+ /bin/mkdir
/backup/mail/system_filter_all_mail/archive/20160610a/Maildir.23380
+ :


> Also, not entirely sure what the 'VER=$x" assignment is doing, as you
> don't seem to read $VER anywhere else.

Yes, it is useless there; copy and pasted the version part from another
script.  I noticed that when I read over my message to the list, but
whilst that is true, it shouldn't make any difference to the script
being able to run or not at start up.

The script does have #! /bin/sh at the top and /bin/sh does point to
/bin/dash as follows:

# ls -l /bin/sh
lrwxrwxrwx 1 root root 4 Feb 21 17:40 /bin/sh -> dash



Thanks
AndrewM


signature.asc (201 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Linux startup, Wheezy -- a required script won't run on startup, but can run manually without any trouble

Dan Purgert
Andrew McGlashan wrote:
>[snip]
> The script does have #! /bin/sh at the top and /bin/sh does point to
> /bin/dash as follows:
>
> # ls -l /bin/sh
> lrwxrwxrwx 1 root root 4 Feb 21 17:40 /bin/sh -> dash

Try running it as 'sh <yourscript>' or 'dash <yourscript>' -- you're
probably doing "bashisms" in there somewhere that're causing things to
fail.


--
|_|O|_| Registered Linux user #585947
|_|_|O| Github: https://github.com/dpurgert
|O|O|O|

Reply | Threaded
Open this post in threaded view
|

Re: Linux startup, Wheezy -- a required script won't run on startup, but can run manually without any trouble

Nicholas Geovanis-2
The Jessie Debian Handbook states:
"The two-figures number
that follows had historically been used to define the order in which services had to be started,
but nowadays the default boot system uses insserv , which schedules everything automatically
based on the scripts’ dependencies." on pg 188.

On Thu, Jun 9, 2016 at 3:56 PM, Dan Purgert <[hidden email]> wrote:
Andrew McGlashan wrote:
>[snip]
> The script does have #! /bin/sh at the top and /bin/sh does point to
> /bin/dash as follows:
>
> # ls -l /bin/sh
> lrwxrwxrwx 1 root root 4 Feb 21 17:40 /bin/sh -> dash

Try running it as 'sh <yourscript>' or 'dash <yourscript>' -- you're
probably doing "bashisms" in there somewhere that're causing things to
fail.


--
|_|O|_| Registered Linux user #585947
|_|_|O| Github: https://github.com/dpurgert
|O|O|O|


Reply | Threaded
Open this post in threaded view
|

Re: Linux startup, Wheezy -- a required script won't run on startup, but can run manually without any trouble

Mark Neyhart-2
In reply to this post by Dan Purgert
On 06/09/2016 12:17 PM, Dan Purgert wrote:

> Andrew McGlashan wrote:
>> On 10/06/2016 5:06 AM, Dan Purgert wrote:
>>> Andrew McGlashan wrote:
>>>> [snip]
>>>> Now, I want the archiving script to run on system startup, I don't
>>>> want dovecot or exim4 to be running when the script starts, it
>>>> simply needs to have the /backup and /var file systems mounted to do
>>>> it's required job
>>>
>>> Looks like it might also need syslog running...
>>
>> Perhaps, but why?  I'm not asking it to log anything to syslog; just to
>> create it's own log file in the /var/log directory.
>
> Just going off the comments at the top -- states "required-start:
> $syslog".  Although, I suppose that you could've just forgotten to
> remove that bit.
>
>> [snip]
>> Weird artifcat of something (perhaps GPG due to signing?), my copy as
>> sent to the list is clean.  The script works perfectly if ran with an
>> interactive shell; right now the script isn't destructive, so I can run
>> it as many times as I like and it works fine.  The plan is to adjust the
>> script, I think you can see how, but not until it works as expected.
>
> How are you calling it while logged in?  I'm starting to wonder if it's
> a difference between [da]sh and bash (or whatever your standard login
> shell is).  
>
> Also, not entirely sure what the 'VER=$x" assignment is doing, as you
> don't seem to read $VER anywhere else.
>
Something you might do just to see if the script is called at all is
to add a simple logging line right after the initial comments such as

echo $(date) mailarchive entered >>/tmp/mailarchive.log

If this proves that the script is called, then as Dan mentions, there
might be a shell incompatibility between what you use at the command
line and what the system shell is.  If so, add more echos until you
find the statement(s) which don't work.

Reply | Threaded
Open this post in threaded view
|

Re: Linux startup, Wheezy -- a required script won't run on startup, but can run manually without any trouble

Christian Seiler
In reply to this post by Andrew McGlashan
On 06/09/2016 07:46 PM, Andrew McGlashan wrote:
> The order of the scripts alone allowed for everything to be very, very
> simple and no script relied upon any other; they were self dependent.
> If you wanted something to be available before your script, you made
> sure your numeric number after the S in the script name (or rather the
> symlink name back to the /etc/init.d directory file) was higher.  It was
> simple, it worked perfectly,

(In the following, for the most part I'm only going to talk about
sysvinit, ignoring any other init system.)

I think you are suffering from quite a bit of confusion. You need to
separate a few concepts apart:

 - the S**/K** symlinks
 - how they are generated
 - startup parallelization

Since very old versions of Debian (I don't remember which), you could
create symbolic links for init scripts like this:

 - /etc/rcX.d/SYYname -> /etc/init.d/name
 - /etc/rcX.d/KYYname -> /etc/init.d/name

   YY being a number between 00 and 99 here.

When changing a runlevel, first all the K** links (in order) of the
_new_ runlevel are run and then all the S** links (in order), also of
the _new_ runlevel are run. [1]

The symlinks would be generated by calling update-rc.d, e.g. via:

  update-rc.d NAME start 42 2 3 4 5 . stop 75 0 1 6 .

This would generate /etc/rc[2345].d/S42NAME, /etc/rc[016].d/K75NAME.

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.

This lead to multiple problems, most importantly that if you had two
otherwise unrelated services A and B, that don't have any dependency
with each other, so they have the same number, e.g. 20. But then a
service C comes a long that needs to be started before B but after A,
then A and B need to have different numbers regardless. But the numbers
of these services are fixed in the Debian package scripts, so the
maintainer of the package containing service C needed to convince the
maintainers of services A and B to change their number (and if they in
turn depend on other scripts, those have to be adapted, too). And this
doesn't even leave any room for modifications by the admin, who might
need this for local scripts that will never be part of Debian: even if
they could convince the maintainers of the packages they'd need to
squeeze their own script in between, they'd still have to wait for the
next Debian release or do some extensive local modifications.

Which is why people had been working on a replacement for a number of
years (the Debian wiki claims since 2002, but the link doesn't work).
In 2008 an alternative was implemented that was designed to work across
distributions, and the LSB standard for init scripts was born. [2]
(This was way before systemd btw.)

The integration into Debian took a bit longer, and Squeeze was the
first Debian version to fully incorporate that. (Although you could
still choose to use old system in Squeeze IIRC, support for which was
dropped in Wheezy.) Instead of having the numbers fixed, they would be
calculated when services were enabled.

Now, each service has to declare in form of the so-called LSB header
its dependencies relative to other services. Then, when services are
enabled/disabled, these dependencies taken into account and the numbers
are generated accordingly. (Which is why they rarely exceed 30 now,
unless you have really many services.)

This now has the huge advantage that if you squeeze in a service
between others, the numbers will automatically get recalculated.

The following LSB headers are understood in Debian:

 * Provides:
     Alternative names for the service for dependency resolution. For
     example, /etc/init.d/networking has the values 'networking' and
     'ifupdown' in there; so anything that orders against either of
     them will order against networking.

 * Required-Start:
     Anything that must be started before this script. insserv and
     update-rc.d will fail if the required script doesn't exist or is
     not enabled. (It will not enable that script automatically though,
     it will just complain.)

 * Required-Stop:
     Same as Required-Start, but just that these services have to be
     kept around during shutdown. Commonly the same as Required-Start,
     but not necessarily.

 * Should-Start/Should-Stop:
     Same as the Required- version, but if the other script is not
     enabled or not installed, don't consider that to be an error.

 * X-Start-After:/X-Stop-Before:
     The inverse dependency, meaning that
        A: X-Start-After: B
     is equivalent to
        B: Should-Start: A

  * Default-Start:
     List of runlevels where the service should be started in
     by default. Typically 2 3 4 5

  * Default-Stop:
     Typically 0 1 6

To enable a service initially, you'd call

  update-rc.d defaults NAME

And to remove the links:

  update-rc.d remove NAME

Important: only the options defaults, remove, enable and disable for
update-rc.d will add/remove/change type of S/K symlinks for the service
specified. They will never touch the symlinks for other services, and
other options will never add/remove/change type. However, calling
insserv without parameters (which is what update-rc.d does internally)
will cause the existing symlinks to be reordered - so adding a link
S42foo somewhere might be renamed to S12foo later, depending on what
dependency-based resolution says the number should be.

So when you claim the old system where you just put some numbers in
there worked 'perfectly', I will disagree vehemently. The dependency-
based boot system of Squeeze was a *really* good idea. I remember
Gentoo from the mid-2000s once, and back then (before OpenRC) they were
using sysvinit + a bunch of bash scripts that were nothing like the
standard init scripts used on other distros - instead they'd declare
dependencies logically via bash functions. I clearly remember liking
that idea MUCH more than the numbered links I knew from other distros,
especially when you wanted to write your own script.

So to my view, the LSB init script standard is a clear advantage as
compared to what was going on before - because you can finally
logically declare the relations between services at startup. It's a bit
clumsy (comments that are parsed in init scripts), so it's not perfect,
but a vast improvement IMHO.

Ok, so now that we have dependency-base init script ordering, there's
an additional feature added to Debian, namely parallel startup of init
scripts. (With sysvinit.) This is done via the startpar binary that was
once part of the sysvinit-utils pacakge, but is since Jessie a separate
package on its own (named startpar).

The idea behind it is the following: if all scripts explicitly declare
their dependencies, any script with the same number as another will be
in no relation to that, so it's possible to start both in parallel. For
example, on a wheezy box I have here, the ntp, rsync and ssh have the
same number in /etc/rc3.d, so they can be started at the same time in
parallel - and once all 3 are complete, the next service can be
started.

You can indeed disable this via setting CONCURRENCY=none in the
/etc/default/rcS configuration file. Then the startup wil again be
completely serialized. (In Jessie and onwards, you can choose to remove
the startpar package instead, that will also do the trick.)

> Now I have sysvinit isntalled on wheezy, it is failing to run a simple
> script during system boot (as part of a planed reboot) and I cannot work
> out why.
>
> # ls -l /etc/{init.d,rc*.d}/*archive*
> -rwxr-xr-x 1 root root 1453 Jun  8 04:12 /etc/init.d/archive-system-mail
> lrwxrwxrwx 1 root root   29 Jun  3 23:30
> /etc/rc2.d/S02archive-system-mail -> ../init.d/archive-system-mail
> lrwxrwxrwx 1 root root   29 Jun  4 03:06
> /etc/rc3.d/S02archive-system-mail -> ../init.d/archive-system-mail
> lrwxrwxrwx 1 root root   29 Jun  4 03:07
> /etc/rc4.d/S02archive-system-mail -> ../init.d/archive-system-mail
> lrwxrwxrwx 1 root root   29 Jun  4 03:08
> /etc/rc5.d/S02archive-system-mail -> ../init.d/archive-system-mail
The low number for a non-rcS service is a very disconcerting, because
it could mean that your script isn't properly ordered against other
scripts that are started during boot, especially those that mount stuff
and such. This is likely caused due to a lack of dependencies. 02 is
typically at the point where udev is started, when the root filesystem
might still even be mounted read-only. (If you've configured it that
way.)

I believe that's your actual problem: I think either your script is
run, but far too early, or it's not run, because it has a really low
number in a non-rcS runlevel, and startpar doesn't cope with that
well. (Because rcS -> rc2 transition is not a runlevel transition in
Debian, so it's kind of special.)

And if I look at the script, there lies your very problem:

> Now, I want the archiving script to run on system startup, I don't want
> dovecot or exim4 to be running when the script starts, it simply needs
> to have the /backup and /var file systems mounted to do it's required job.

Ok, so if you depend on local or remote file systems, you need to
depend on $local_fs and $remote_fs, respectively. If all your file
systems are local, use $local_fs - otherwise $remote_fs (or both).

(Technically, $syslog might suffice, because all standard syslog
implementations provide $syslog via /etc/insserv.conf, and they
themselves depend on $local_fs at least, but IMHO it's better to
explicitly write out $remote_fs and $local_fs.)

> My script is meant to create a log file in the /var/log directory.  If I
> run the script manually, it works perfectly.  There are some generic
> parts in the script, it is a fairly simple script, even if a little bit
> over complicated.  What do I need to do to fix it?
>
> Here is the script:
>
> # cat /etc/init.d/archive-system-mail
> #! /bin/sh
> ### BEGIN INIT INFO
> # Provides:          mailarchive
> # Required-Start:    $syslog
> # Required-Stop:     $syslog
Required-Start: $local_fs $remote_fs $syslog
Required-Stop: $local_fs $remote_fs $syslog

Plus, maybe, if it is supposed to run _before_ exim4, you could also
add the following pseudo-headers:

X-Start-Before: exim4
X-Stop-After: exim4

After the modification, run insserv (without parameters) to have it
reorder the script with respect to numbering (it should get a higher
number now), verify that the numbers of your init scripts are now
reordered accordingly and everything should work. (Assuming the
script is executable.)

> case "$1" in
>   start)
>         do_main
>         ;;
>   *)
>         echo "Usage: $SCRIPTNAME {start}" >&2
>         exit 3
>         ;;
> esac

This is also not good, because Debian requires you to implement the
start, stop, status, restart and force-reload arguments. Maybe that's
also something that trips up the logic in your case. If you really
don't want them, please at least add something like

stop|status|restart|force-reload) exit 0 ;;

Regards,
Christian

[1] I remember really old versions of SuSE, from before 2000, that used
    a slightly different scheme, which would first run all K** scripts
    of the old runlevel (so a script would have S** and K** symlinks in
    the same runlevel) and then the S** scripts of the new runlevel,
    exluding things that match (so it doesn't stop things that are in
    both). But IIRC that was never in Debian, and I don't know what
    SuSE did with that afterwards.

[2] https://lists.debian.org/debian-devel-announce/2008/01/msg00004.html


signature.asc (817 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Linux startup, Wheezy -- a required script won't run on startup, but can run manually without any trouble

Christian Seiler
In reply to this post by Andrew McGlashan
On 06/09/2016 10:10 PM, Andrew McGlashan wrote:
> What I have now is that with some extra "smarts" that stops the original
> concept from working as intended.  The smarts is meant to allow for
> faster startup and to tie in dependancies; to me, it is trying to be too
> smart and that is where the problem lies.

Faster startup was never the initial goal of dependency-based boot,
that came afterwards. The main goal was always to describe startup
properly, because you want ordering to reflect what services actually
mean relative to another. And just pulling some arbitrary numbers out
of thin air was NEVER a good idea in my eyes.

> I see within the /etc/init.d/ scripts that there is all this extra junk
> at the top and there are .depend.* files in that directory too.

The .depend.* is for Makefile-based boot (startpar uses that
internally). You can still disable that and go back to a fully
serialized version with sysvinit.

> I am thinking that these extras are the reason why it isn't running the
> script at startup as expected.

No, the reason is that you appear to have pulled the number 02 out of
thin air and expect it to work, without giving a thought about what
you want to actually order it against. (See my other email.)

> Those extras weren't not part of the
> more original sysv init setup; and, it may be why lots of Debian and
> other people decided that the sysvinit was broken (due to the extras)...

No, in the contrary. When I first saw Gentoo's system in the mid 2000s,
which was based exclusively on dependencies (but still used scripts on
top of sysvinit), I thought: wow, this is SO much better than all the
other distros at that time.

To me, anything that doesn't allow me to have dependencies is not worth
my consideration. I've often had to write own services that hook into
the system startup at certain points. And being able to specify
dependencies is something absolutely essential here. Because then I
actually semantically describe why I want a service in a given position
in the boot sequence. Doing it in any other way is madness to me.

There's a reason why _every_ modern init system supports dependencies
(systemd, Solaris's SMF, nosh, OpenRC, ...), because in the modern
world, where so many things need to be taken care of at boot, it's
absolutely essential to be able to express the relations betwen all
the services that need to be started explicitly in form of
dependencies, otherwise you'd never be able to really tackle the
complexity.

> and hence why we ended up with systemd.

You're right and you're wrong here.

You're right in that the way dependency-based boot is handled in
sysvinit+initscripts-based systems is not really nice, because
dependencies are actually kind of implemented on top of an older model,
instead of being treated as a first-class citizen. (And it's not
complete, because the dependencies are only considered when booting,
not when manually starting/stopping services. [1])

You're wrong in the sense that nobody on the systemd side of the
argument wants to go back to non-dependency-based boot. So if you think
that had dependency-based boot never been added to the init script
logic, systemd wouldn't have been born or at least not have gained any
traction - it would be the complete opposite, some people would have
wanted something like systemd even moreso.

Regards,
Christian

[1] Gentoo's set of scripts actually already did that 10 years ago,
with the caveat that it didn't have proper state tracking, only an
emulation of that, which is why the 'zap' action existed (exists?)
there.



signature.asc (817 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Linux startup, Wheezy -- a required script won't run on startup, but can run manually without any trouble

Andrew McGlashan
In reply to this post by Christian Seiler
Hi,

I'm not sure my end solution is the best.

TLDR; -- I've now got the script working as desired, but I have more to
say below, including a thank you for Christian in particular.  And I do
have other queries.


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.

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.

On 10/06/2016 7:29 AM, Christian Seiler wrote:

> On 06/09/2016 07:46 PM, Andrew McGlashan wrote:
>> The order of the scripts alone allowed for everything to be very, very
>> simple and no script relied upon any other; they were self dependent.
>> If you wanted something to be available before your script, you made
>> sure your numeric number after the S in the script name (or rather the
>> symlink name back to the /etc/init.d directory file) was higher.  It was
>> simple, it worked perfectly,
>
> (In the following, for the most part I'm only going to talk about
> sysvinit, ignoring any other init system.)
>
> I think you are suffering from quite a bit of confusion. You need to
> separate a few concepts apart:
Yes.

>  - the S**/K** symlinks
>  - how they are generated
>  - startup parallelization
>
> Since very old versions of Debian (I don't remember which), you could
> create symbolic links for init scripts like this:
>
>  - /etc/rcX.d/SYYname -> /etc/init.d/name
>  - /etc/rcX.d/KYYname -> /etc/init.d/name
>
>    YY being a number between 00 and 99 here.
Yes, but if you did a simple: "ls -l S*" or "ls -l K*", then the order
was properly determined.

> 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.  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.

> To enable a service initially, you'd call
>
>   update-rc.d defaults NAME

After script adjustments....

# update-rc.d archive-system-mail remove
update-rc.d: using dependency based boot sequencing


# update-rc.d archive-system-mail defaults
update-rc.d: using dependency based boot sequencing

>> Now I have sysvinit isntalled on wheezy, it is failing to run a simple
>> script during system boot (as part of a planed reboot) and I cannot work
>> out why.
>>
>> # ls -l /etc/{init.d,rc*.d}/*archive*
>> -rwxr-xr-x 1 root root 1453 Jun  8 04:12 /etc/init.d/archive-system-mail
>> lrwxrwxrwx 1 root root   29 Jun  3 23:30
>> /etc/rc2.d/S02archive-system-mail -> ../init.d/archive-system-mail
>> lrwxrwxrwx 1 root root   29 Jun  4 03:06
>> /etc/rc3.d/S02archive-system-mail -> ../init.d/archive-system-mail
>> lrwxrwxrwx 1 root root   29 Jun  4 03:07
>> /etc/rc4.d/S02archive-system-mail -> ../init.d/archive-system-mail
>> lrwxrwxrwx 1 root root   29 Jun  4 03:08
>> /etc/rc5.d/S02archive-system-mail -> ../init.d/archive-system-mail
I still have low numbers, but done the correct way via insserv.

# ls -l /etc/{init.d,rc*.d}/*archive*
-rwxr-xr-x 1 root root 2402 Jun 10 15:19 /etc/init.d/archive-system-mail
lrwxrwxrwx 1 root root   29 Jun 10 15:38
/etc/rc0.d/K02archive-system-mail -> ../init.d/archive-system-mail
lrwxrwxrwx 1 root root   29 Jun 10 15:38
/etc/rc1.d/K02archive-system-mail -> ../init.d/archive-system-mail
lrwxrwxrwx 1 root root   29 Jun 10 15:38
/etc/rc2.d/S02archive-system-mail -> ../init.d/archive-system-mail
lrwxrwxrwx 1 root root   29 Jun 10 15:38
/etc/rc3.d/S02archive-system-mail -> ../init.d/archive-system-mail
lrwxrwxrwx 1 root root   29 Jun 10 15:38
/etc/rc4.d/S02archive-system-mail -> ../init.d/archive-system-mail
lrwxrwxrwx 1 root root   29 Jun 10 15:38
/etc/rc5.d/S02archive-system-mail -> ../init.d/archive-system-mail
lrwxrwxrwx 1 root root   29 Jun 10 15:38
/etc/rc6.d/K02archive-system-mail -> ../init.d/archive-system-mail

>> Now, I want the archiving script to run on system startup, I don't want
>> dovecot or exim4 to be running when the script starts, it simply needs
>> to have the /backup and /var file systems mounted to do it's required job.
>
> Ok, so if you depend on local or remote file systems, you need to
> depend on $local_fs and $remote_fs, respectively. If all your file
> systems are local, use $local_fs - otherwise $remote_fs (or both).
>
> (Technically, $syslog might suffice, because all standard syslog
> implementations provide $syslog via /etc/insserv.conf, and they
> themselves depend on $local_fs at least, but IMHO it's better to
> explicitly write out $remote_fs and $local_fs.)
>
>> My script is meant to create a log file in the /var/log directory.  If I
>> run the script manually, it works perfectly.  There are some generic
>> parts in the script, it is a fairly simple script, even if a little bit
>> over complicated.  What do I need to do to fix it?
>>
>> Here is the script:
Here is the script now, it seems to work correctly now:

# cat archive-system-mail
#! /bin/sh
### BEGIN INIT INFO
# Provides:          mailarchive
# Required-Start:    $local_fs $remote_fs $syslog
# Required-Stop:     $local_fs $remote_fs $syslog
# X-Start-Before:    exim4 dovecot
# X-Stop-After:      exim4 dovecot
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: Save exim4 system_filter archive
# Description:       This file should be ran at boot time before either
#                    exim4 or dovecot is started.  It saves mail that is
#                    created via rules within the /etc/system_filter and
#                    it's related log file.
### END INIT INFO

# Author: Andrew McGlashan <[hidden email]>

set -x

DESC="Save exim4 system_filter archive"
NAME=archive-system-mail
SCRIPTNAME=/etc/init.d/$NAME

# Read configuration variable file if it is present
[ -r /etc/default/$NAME ] && . /etc/default/$NAME

# Load the VERBOSE setting and other rcS variables
. /lib/init/vars.sh

# Define LSB log_* functions.
# Depend on lsb-base (>= 3.2-14) to ensure that this file is present
# and status_of_proc is working.
. /lib/lsb/init-functions

do_cleanup()
{
        # Cleanup
        echo -e "\a\a\aPerforming cleanup"
        exit $1
}

do_error_exit()
{
        # Display error message and exit
        echo "${PROGNAME}: ${1:-"Unknown Error"}" 1>&2
        do_cleanup 1
}

do_get_archivedir()
{
        for VER in a b c d e f g h i j k l m n o p q r s t u v w x y z
        do

ARCHIVE_DIR=/backup/mail/system_filter_all_mail/archive/${DATEX}${VER}
                if [ ! -d $ARCHIVE_DIR ]; then return 0; fi
        done
        return 1
}

do_main()
{
        (
        do_get_archivedir || do_error_exit "Cannot get archive dir"

        if [ ! -d ${ARCHIVE_DIR} ];then /bin/mkdir $ARCHIVE_DIR;fi
        /bin/mv /backup/mail/system_filter_all_mail/log--lots $ARCHIVE_DIR/
        /bin/mv /backup/mail/system_filter_all_mail/Maildir   $ARCHIVE_DIR/
        /usr/bin/touch $ARCHIVE_DIR/log--lots.$$
        )  2>&1 | /usr/bin/tee /var/log/${PROGNAME}--$(date
+%Y%m%d%H%M%S).log
}

# main
trap "do_cleanup 99" HUP INT TERM

# Global Variables
ARCHIVE_DIR=
VER=
DATEX=$(/bin/date +%Y%m%d)
PROGNAME=$(/usr/bin/basename $0)

case "$1" in
        start)
                [ "$VERBOSE" != no ] && log_daemon_msg "Running Startup
Script $DESC" "$NAME"
                do_main
                [ "$VERBOSE" != no ] && log_daemon_msg "Archive
Directory for $NAME" "$ARCHIVE_DIR" "$VER"
                ;;
        stop|status|restart|force-reload) exit 0 ;;
        *)
                echo "Usage: $SCRIPTNAME {start}" >&2
                exit 3
                ;;
esac

:



Thank you all, especially Christian for the excellent explanations and
helping me learn the errors of my ways.  And, like I said above, happy
to learn some more even though the script is now running as desired.

Kind Regards
AndrewM


signature.asc (201 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Linux startup, Wheezy -- a required script won't run on startup, but can run manually without any trouble

Christian Seiler
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.


signature.asc (817 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Linux startup, Wheezy -- a required script won't run on startup, but can run manually without any trouble

Mart van de Wege
In reply to this post by Christian Seiler
Christian Seiler <[hidden email]> writes:

>
> No, in the contrary. When I first saw Gentoo's system in the mid 2000s,
> which was based exclusively on dependencies (but still used scripts on
> top of sysvinit), I thought: wow, this is SO much better than all the
> other distros at that time.
>
> To me, anything that doesn't allow me to have dependencies is not worth
> my consideration. I've often had to write own services that hook into
> the system startup at certain points. And being able to specify
> dependencies is something absolutely essential here. Because then I
> actually semantically describe why I want a service in a given position
> in the boot sequence. Doing it in any other way is madness to me.
>
> There's a reason why _every_ modern init system supports dependencies
> (systemd, Solaris's SMF, nosh, OpenRC, ...), because in the modern
> world, where so many things need to be taken care of at boot, it's
> absolutely essential to be able to express the relations betwen all
> the services that need to be started explicitly in form of
> dependencies, otherwise you'd never be able to really tackle the
> complexity.
>

To use an analogy: there is a reason why programming languages switched
from line numbers to named subprograms.

Mart

--
"We will need a longer wall when the revolution comes."
    --- AJS, quoting an uncertain source.

Reply | Threaded
Open this post in threaded view
|

Re: Linux startup, Wheezy -- a required script won't run on startup, but can run manually without any trouble

Andrew McGlashan
In reply to this post by Christian Seiler
All good now:

# cat /etc/init.d/archive-system-mail
#! /bin/sh
### BEGIN INIT INFO
# Provides:          mailarchive
# Required-Start:    $local_fs $remote_fs $syslog
# Required-Stop:     $local_fs $remote_fs $syslog
# X-Start-Before:    exim4 dovecot
# X-Stop-After:      exim4 dovecot
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: Save exim4 system_filter archive
# Description:       This file should be ran at boot time before either
#                    exim4 or dovecot is started.  It saves mail that is
#                    created via rules within the /etc/system_filter and
#                    it's related log file.
### END INIT INFO

# Author: Andrew McGlashan <[hidden email]>

# set -x

#
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
DESC="Save exim4 system_filter archive"
NAME=archive-system-mail
DAEMON=/usr/local/sbin/$NAME
SCRIPTNAME=/etc/init.d/$NAME

# Exit if the package is not installed
[ -x "$DAEMON" ] || exit 0

# Read configuration variable file if it is present
[ -r /etc/default/$NAME ] && . /etc/default/$NAME

# Load the VERBOSE setting and other rcS variables
. /lib/init/vars.sh

# Define LSB log_* functions.
# Depend on lsb-base (>= 3.2-14) to ensure that this file is present
# and status_of_proc is working.
. /lib/lsb/init-functions

case "$1" in
        start)
                # Run the required script
                $DAEMON
                ;;
        stop|status|restart|force-reload)
                exit 0
                ;;
        *)
                echo "Usage: $SCRIPTNAME {start}" >&2
                exit 3
                ;;
esac

:



And the script itself:
# cat /usr/local/sbin/archive-system-mail
#! /bin/sh

do_cleanup()
{
        # Cleanup
        echo -e "\a\a\aPerforming cleanup"
        exit $1
}

do_error_exit()
{
        # Display error message and exit
        echo "${PROGNAME}: ${1:-"Unknown Error"}" 1>&2
        do_cleanup 1
}

do_get_archivedir()
{
        for VER in a b c d e f g h i j k l m n o p q r s t u v w x y z
        do

ARCHIVE_DIR=/backup/mail/system_filter_all_mail/archive/${DATEX}${VER}
                [ ! -d ${ARCHIVE_DIR} ] && return 0
        done
        return 1
}

# main
trap "do_cleanup 99" HUP INT TERM

# Global Variables
ARCHIVE_DIR=
DATEX=$(/bin/date +%Y%m%d)
PROGNAME=$(/usr/bin/basename $0)

[ -r /backup/mail/system_filter_all_mail/log--lots ] || do_error_exit
"Missing or unreadable SOURCE log--lots file"

(
        # Exit if the we cannot get a suitable archive directory
        do_get_archivedir       || do_error_exit "Cannot get archive dir"

        [ ! -d ${ARCHIVE_DIR} ] && /bin/mkdir ${ARCHIVE_DIR}
        [   -d ${ARCHIVE_DIR} ] || do_error_exit "The required archive
directory wasn't created as expected"

        (
        # Exit if the we cannot cd in to the archive directory
        cd ${ARCHIVE_DIR}       || do_error_exit "Cannot cd in to the
archive directory"

        /bin/mv /backup/mail/system_filter_all_mail/log--lots .
        [ -r log--lots ]        || do_error_exit "Missing or unreadable
archive copy of log--lots file"

        /bin/mv /backup/mail/system_filter_all_mail/Maildir   .
        [ -d Maildir ]          || do_error_exit "Missing archive of
Maildir folder"

        # Fix log--lots file to have only ONE line per record, in cases
where system_filter wrote multi-lines
        TMP_LOG_LOTS=${ARCHIVE_DIR}/log--lots.$$
        /usr/bin/touch -r log--lots $TMP_LOG_LOTS
        echo '' >> log--lots
        sed -i -e ':a' -e 'N' -e '$!ba' -e 's/\n[\t\ *]/\ /g' log--lots
        sed -i -e '/^$/d' log--lots
        /usr/bin/touch -r $TMP_LOG_LOTS log--lots

        /bin/ls -ladrt /backup/mail/system_filter_all_mail/log--lots
${ARCHIVE_DIR}/*
        )
)  2>&1 | /usr/bin/tee /var/log/${PROGNAME}--$(date +%Y%m%d%H%M%S).log



Cheers
AndrewM


signature.asc (201 bytes) Download Attachment