Re: Linux startup, Wheezy -- a required script won't run on startup, but can run manually without any trouble
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
# 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
Description: OpenPGP digital signature
Re: Linux startup, Wheezy -- a required script won't run on startup, but can run manually without any trouble
Christian Seiler 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.
Re: Linux startup, Wheezy -- a required script won't run on startup, but can run manually without any trouble
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 installe
Re: Linux startup, Wheezy -- a required script won't run on startup, but can run manually without any trouble
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 mi
Re: Linux startup, Wheezy -- a required script won't run on startup, but can run manually without any trouble
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 Description: OpenPGP digital signature
Re: Linux startup, Wheezy -- a required script won't run on startup, but can run manually without any trouble
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
Re: Linux startup, Wheezy -- a required script won't run on startup, but can run manually without any trouble
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.
Re: Linux startup, Wheezy -- a required script won't run on startup, but can run manually without any trouble
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 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 ' or 'dash ' -- 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| > >
Re: Linux startup, Wheezy -- a required script won't run on startup, but can run manually without any trouble
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 ' or 'dash ' -- 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|
Re: Linux startup, Wheezy -- a required script won't run on startup, but can run manually without any trouble
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 Description: OpenPGP digital signature
Re: Linux startup, Wheezy -- a required script won't run on startup, but can run manually without any trouble
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|
Re: Linux startup, Wheezy -- a required script won't run on startup, but can run manually without any trouble
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 Description: OpenPGP digital signature
Re: Linux startup, Wheezy -- a required script won't run on startup, but can run manually without any trouble
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: > > > 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? > > > 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.
Re: Linux startup, Wheezy -- a required script won't run on startup, but can run manually without any trouble
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: 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? Anyway, best to re-read the original message in full now... ;-) Thanks AndrewM signature.asc Description: OpenPGP digital signature
Re: Linux startup, Wheezy -- a required script won't run on startup, but can run manually without any trouble
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:amd6444-11+deb7u4 amd64systemd login utility library ii sysvinit 2.88dsf-41+deb7u1 amd64System-V-like init utilities ii sysvinit-utils 2.88dsf-41+deb7u1 amd64System-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 Description: OpenPGP digital signature
Re: Linux startup, Wheezy -- a required script won't run on startup, but can run manually without any trouble
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...]
Re: Linux startup, Wheezy -- a required script won't run on startup, but can run manually without any trouble
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|
