Hi all,

I've installed postfix (and also cpufreqd) on my Slack-current 2.6.11.6
system. Everything works all right, except when I boot the scripts are
not executed. Yet I chmod'd rc.postfix and rc.cpufreqd properly.

Perusing the book:
http://slackbook.lizella.net/chapter4.html

I could'nt find an answer, since the scripts chmod'd +x are supposed to
be enable. Then again, which is the parent process launching those
scripts ? Where is the error message redirected to ?

The scripts seem to be allright, except they are launched within a "case
$1", which means that if no argument (start, stop, restar) is given,
well there's an error. But I couldn't get it in the logs :-(
Does whichever process launches the "+x" scripts give any argument at all ?

(I wish the book was more explicit on that one)
(And I'm willing to write down the section, as soon as an appropriate
answer is established)

Thanks,
++

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

gregg wrote:
> Hi all,
>
> I've installed postfix (and also cpufreqd) on my Slack-current 2.6.11.6
> system. Everything works all right, except when I boot the scripts are
> not executed. Yet I chmod'd rc.postfix and rc.cpufreqd properly.
>
> Perusing the book:
> http://slackbook.lizella.net/chapter4.html
>
> I could'nt find an answer, since the scripts chmod'd +x are supposed to
> be enable. Then again, which is the parent process launching those
> scripts ? Where is the error message redirected to ?
>
> The scripts seem to be allright, except they are launched within a "case
> $1", which means that if no argument (start, stop, restar) is given,
> well there's an error. But I couldn't get it in the logs :-(
> Does whichever process launches the "+x" scripts give any argument at all ?
>
> (I wish the book was more explicit on that one)
> (And I'm willing to write down the section, as soon as an appropriate
> answer is established)
>
> Thanks,
> ++

If you have a look at /etc/rc.d/rc.M, which is executed when going
multi-user, then you'll see that it executes the other scripts in
/etc/rc.d .
Thus, if you create scripts for your own service, you'll have to load
them from rc.M.

And you have to give the argument (start) yourself, like:

if [ -x /etc/rc.d/rc.postfix ]; then
. /etc/rc.d/rc.postfix start
fi

which would execute rc.postfix only if it's chmod +x

Regards
Bram4

- --


BIG BROTHER IS WATCHING YOU
www.anti-dmca.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (MingW32)

iD8DBQFCVDfJsv7ahDE9W98RAplyAKCAaLL3dKG4VwUXhylu2M uSjwcooQCbBM4G
2g36ZKekthQMB5q5uS0Pe+U=
=Lbhn
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

gregg wrote:
> Hi all,
>
> I've installed postfix (and also cpufreqd) on my Slack-current 2.6.11.6
> system. Everything works all right, except when I boot the scripts are
> not executed. Yet I chmod'd rc.postfix and rc.cpufreqd properly.
>
> Perusing the book:
> http://slackbook.lizella.net/chapter4.html
>
> I could'nt find an answer, since the scripts chmod'd +x are supposed to
> be enable. Then again, which is the parent process launching those
> scripts ? Where is the error message redirected to ?
>
> The scripts seem to be allright, except they are launched within a "case
> $1", which means that if no argument (start, stop, restar) is given,
> well there's an error. But I couldn't get it in the logs :-(
> Does whichever process launches the "+x" scripts give any argument at all ?
>
> (I wish the book was more explicit on that one)
> (And I'm willing to write down the section, as soon as an appropriate
> answer is established)
>
> Thanks,
> ++
You could also run the new scripts from rc.local if you dont want to
modify rc.M.

M
- --
http://miroco.homelinux.net/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFCVDsyCDtd7k1xGowRAl0SAJwPL52/sjvybLstW8HKl0IvpvPzSQCgjwGO
eU8voeOxGAlIPuPyBowMb7o=
=cNBe
-----END PGP SIGNATURE-----

bram4 wrote:

> If you have a look at /etc/rc.d/rc.M, which is executed when going
> multi-user, then you'll see that it executes the other scripts in
> /etc/rc.d .
> Thus, if you create scripts for your own service, you'll have to load
> them from rc.M.

Yes, well, i did that ( I mean look into rc.M)
I don't like the idea of touching it, so I usually load this from
rc.local (which seems more logical).


> And you have to give the argument (start) yourself, like:
>
> if [ -x /etc/rc.d/rc.postfix ]; then
> . /etc/rc.d/rc.postfix start
> fi
>
> which would execute rc.postfix only if it's chmod +x

Right, okay for that.

It's just that, reading from the book, well, it seemed only a chmod on
any script in rc.d was needed.
Apparently, it means chmod'ing a script _already_ present in rc.M

Either my English is too poor, or it's rather ambiguous.
(It may very well be the first, and since I'm French you can bet lack of
intelligence does not help me either...).

Anyway, thank you for the answer.
(rc.M is the one launching)

And I reckon there is no error message (in logs or on screen) since
nothing is launched !


I could issue a foreach loop in rc.M to launch any script chmod'd +x in
the directory, but that would conflict with what's done already -- and
especially what is not to be done: e.g. rc.K)

Creating another directory does give me satisfaction, for it would make
me move scripts I want in it (and not keep it in rc.d)

Maybe renaming scripts in rc.local.name_of_service_wanted_here, and
create a foreach loop in rc.local ?
Mmmh.
Any ideas, you all veterans :-)



> BIG BROTHER IS WATCHING YOU

And who the hell is watching HIM ?!
And especially, what happens when Big Brother crosses a mirror ?
:-)

++

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

gregg wrote:
> bram4 wrote:
>
>> If you have a look at /etc/rc.d/rc.M, which is executed when going
>> multi-user, then you'll see that it executes the other scripts in
>> /etc/rc.d .
>> Thus, if you create scripts for your own service, you'll have to load
>> them from rc.M.
>
>
> Yes, well, i did that ( I mean look into rc.M)
> I don't like the idea of touching it, so I usually load this from
> rc.local (which seems more logical).
>
>
>> And you have to give the argument (start) yourself, like:
>>
>> if [ -x /etc/rc.d/rc.postfix ]; then
>> . /etc/rc.d/rc.postfix start
>> fi
>>
>> which would execute rc.postfix only if it's chmod +x
>
>
> Right, okay for that.
>
> It's just that, reading from the book, well, it seemed only a chmod on
> any script in rc.d was needed.
> Apparently, it means chmod'ing a script _already_ present in rc.M
>
> Either my English is too poor, or it's rather ambiguous.
> (It may very well be the first, and since I'm French you can bet lack of
> intelligence does not help me either...).
>
> Anyway, thank you for the answer.
> (rc.M is the one launching)
>
> And I reckon there is no error message (in logs or on screen) since
> nothing is launched !
>
>
> I could issue a foreach loop in rc.M to launch any script chmod'd +x in
> the directory, but that would conflict with what's done already -- and
> especially what is not to be done: e.g. rc.K)
>
> Creating another directory does give me satisfaction, for it would make
> me move scripts I want in it (and not keep it in rc.d)
>
> Maybe renaming scripts in rc.local.name_of_service_wanted_here, and
> create a foreach loop in rc.local ?
> Mmmh.
> Any ideas, you all veterans :-)
>
>
>
>> BIG BROTHER IS WATCHING YOU
>
>
> And who the hell is watching HIM ?!
> And especially, what happens when Big Brother crosses a mirror ?
> :-)
>
> ++
If you only have two scripts you want to start, I'd put them in
rc.local. It's not the most elegant, but it's the fastest way.

Bram4


P.S.
J'vois pas le problème d'être francophone... ;-D

- --


BIG BROTHER IS WATCHING YOU
www.anti-dmca.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (MingW32)

iD8DBQFCVD1Zsv7ahDE9W98RAjKqAJ48MAB8ZYcSbZApUWX0a8 Gz6bmbPACgipMB
oiP2vzd8+cXSLhOzysMHmnQ=
=2xtM
-----END PGP SIGNATURE-----

gregg wrote:

> Hi all,
>
> I've installed postfix (and also cpufreqd) on my Slack-current 2.6.11.6
> system. Everything works all right, except when I boot the scripts are
> not executed. Yet I chmod'd rc.postfix and rc.cpufreqd properly.
>
> Perusing the book:
> http://slackbook.lizella.net/chapter4.html
>
> I could'nt find an answer, since the scripts chmod'd +x are supposed to
> be enable. Then again, which is the parent process launching those
> scripts ? Where is the error message redirected to ?
>
> The scripts seem to be allright, except they are launched within a "case
> $1", which means that if no argument (start, stop, restar) is given,
> well there's an error. But I couldn't get it in the logs :-(
> Does whichever process launches the "+x" scripts give any argument at all ?
>
> (I wish the book was more explicit on that one)
> (And I'm willing to write down the section, as soon as an appropriate
> answer is established)
>
> Thanks,
> ++

Just a guess, but did you add lines like the following in
/etc/rc.d/rc.local ? Every rc script _you_ add, must be started by
_you_ by letting it be called in rc.local ...

if [ -x /etc/rc.d/rc.postfix ]; then
echo "Starting postfix: /etc/rc.d/rc.postfix start"
/etc/rc.d/rc.postfix start
fi

if [ -x /etc/rc.d/rc.cpufreqd ]; then
echo "Starting cpufreqd: /etc/rc.d/rc.cpufreqd start"
/etc/rc.d/rc.cpufreqd start
fi

Cheers, Eric

bram4 wrote:

> P.S.
> J'vois pas le problème d'être francophone... ;-D

je déconnais (r) (c) (tm)
:-)

(or maybe did I _really_ not understand the book properly, anyway)

gregg wrote:
[...]
> It's just that, reading from the book, well, it seemed only a chmod on
> any script in rc.d was needed.
> Apparently, it means chmod'ing a script _already_ present in rc.M

Well, it seems to be the usual way in Slackware. The script is often already
in rc.d, and it calling sequence in rc.whatever is preceded by
if [ -x <script> ]
so all you have to do to get it invoked is chmod-ing it to executable. In
rc.modules you find quite a few instances. And it makes sense, once you get
used to it...

--
jjg

jg wrote:
> gregg wrote:
>>Apparently, it means chmod'ing a script _already_ present in rc.M
>
>
> Well, it seems to be the usual way in Slackware. The script is often already
> in rc.d, and it calling sequence in rc.whatever is preceded by
> if [ -x <script> ]
> so all you have to do to get it invoked is chmod-ing it to executable. In
> rc.modules you find quite a few instances. And it makes sense, once you get
> used to it...

Er, what if the script is not in rc.M yet (just like cpufreqd).
I don't think you can assume each and every application to be in rc.M
(up to a certain point, any system is pretty much alike, true enough.
But then, some prefer postfix to sendmail, or exim, or whatever...)


I find the FreeBSD way just more consistent (chmod'ing a script in
/usr/local/etc/rc.d/ for instance make it launched at boot. Of course,
here postfix and cpufreqd aren't in /usr/local... grrr, what a mess)

I wonder what's more simple and elegant, here ?
Adding things to rc.M by myself (making me not to forget to check every
time I upgrade) or finding a way to let it be done automagically by
_simply_ chmod'ing (and I mean just that, simply chmod'ing without
adding 3 lines of "if [ -x soandso ]" etc...), using a loop somewhere...

Maybe I'm making too much out of it ? :-)

++

On 2005-04-06, gregg <greggNOSPAMarbage@NOSPAMfree.WANTEDfr> wrote:
>
> Er, what if the script is not in rc.M yet (just like cpufreqd).

Then add it, or add it to rc.local.

> I find the FreeBSD way just more consistent (chmod'ing a script in
> /usr/local/etc/rc.d/ for instance make it launched at boot. Of course,
> here postfix and cpufreqd aren't in /usr/local... grrr, what a mess)

You could certainly emulate this by adding these modifications to rc.M
or rc.local, as well.

> I wonder what's more simple and elegant, here ?
> Adding things to rc.M by myself (making me not to forget to check every
> time I upgrade) or finding a way to let it be done automagically by
> _simply_ chmod'ing (and I mean just that, simply chmod'ing without
> adding 3 lines of "if [ -x soandso ]" etc...), using a loop somewhere...

I personally prefer using rc.local to call software I've installed
myself. It solves the upgrade issue (as long as you save your old
rc.local), and is simple enough. rc.local doesn't even need to call a
shell script: for example, I call dhcpd straight out of rc.local,
without an intervening shell script (or any other file tests, for that
matter). If it breaks, the worst that happens is that I have no DHCP
server, or, if I don't want one, maybe I get an error on boot, but
that's it.

--keith

--
kkeller-usenet@wombat.san-francisco.ca.us
(try just my userid to email me)
AOLSFAQ=http://wombat.san-francisco.ca.us/cgi-bin/fom
see X- headers for PGP signature information