RC keywords question

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

RC keywords question

Ion-Mihai Tetcu-2
Hi,


I'm converting my ports to work with the new HEAD RC style and while at
it I also thought to check the keywords to make sure they're OK. Read
rcorder(8) and rc(8).

Let's take mail/dspam as an example. Obviously it PROVIDE: dspam

When run in --daemon mode dspam receives messages via LMTP and deliver
them via SMTP. So it REQUIRE: NETWORK; it also uses syslogd (which
starts BEFORE: SERVERS).

Now things start getting interesting.

Since it's a content filter, it should start before the SMTP server.

If SMTP server = sendmail|courier it's easy: BEFORE: mail

If it's postfix it's:
- if it's started via /etc/rc.d/sendmail (sendmail_enable="YES" and
postfix in /etc/mail/mailer.conf) BEFORE: mail should be enough (but see
below);
- if sendmail_enable="NO" and /usr/local/sbin/postfix is linked in rc.d
as sendmail.sh then BEFORE: mail should be OK too since that's before
rc.d/localpkg (right ?)

How to interact with various ways to start qmail I have yet to discover.

So until here I would have:
PROVIDE: dspam
REQUIRE: NETWORK syslogd
BEFORE: mail
and since mail REQUIRE: LOGIN this is actually:
REQUIRE: NETWORK syslogd LOGIN

Q: should I write all the REQUIRE keywords or just the last one (LOGIN) ?


OK, now dspam could also use mysql or pgsql; if the dependency is set
at compile time, it's easy to have the right REQUIRE; but dspam can
also use either or none, as instructed in dspam.conf so this is also
settable at run-time. How can I write the REQUIRE: line in this case ?


Thanks,

--
IOnut - Unregistered ;) FreeBSD "user"
  "Intellectual Property" is   nowhere near as valuable   as "Intellect"

BOFH excuse #344:
Network failure - call NBC


_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: RC keywords question

Brooks Davis
On Mon, Dec 05, 2005 at 02:58:05PM +0200, Ion-Mihai Tetcu wrote:

> Hi,
>
>
> I'm converting my ports to work with the new HEAD RC style and while at
> it I also thought to check the keywords to make sure they're OK. Read
> rcorder(8) and rc(8).
>
> Let's take mail/dspam as an example. Obviously it PROVIDE: dspam
>
> When run in --daemon mode dspam receives messages via LMTP and deliver
> them via SMTP. So it REQUIRE: NETWORK; it also uses syslogd (which
> starts BEFORE: SERVERS).
>
> Now things start getting interesting.
>
> Since it's a content filter, it should start before the SMTP server.
>
> If SMTP server = sendmail|courier it's easy: BEFORE: mail
>
> If it's postfix it's:
> - if it's started via /etc/rc.d/sendmail (sendmail_enable="YES" and
> postfix in /etc/mail/mailer.conf) BEFORE: mail should be enough (but see
> below);
> - if sendmail_enable="NO" and /usr/local/sbin/postfix is linked in rc.d
> as sendmail.sh then BEFORE: mail should be OK too since that's before
> rc.d/localpkg (right ?)
>
> How to interact with various ways to start qmail I have yet to discover.
>
> So until here I would have:
> PROVIDE: dspam
> REQUIRE: NETWORK syslogd
> BEFORE: mail
> and since mail REQUIRE: LOGIN this is actually:
> REQUIRE: NETWORK syslogd LOGIN
>
> Q: should I write all the REQUIRE keywords or just the last one (LOGIN) ?
>
>
> OK, now dspam could also use mysql or pgsql; if the dependency is set
> at compile time, it's easy to have the right REQUIRE; but dspam can
> also use either or none, as instructed in dspam.conf so this is also
> settable at run-time. How can I write the REQUIRE: line in this case ?

"BEFORE: mail" acts for most intents and purposes like all mail scripts
contained "REQUIRE: dspam" so dspam does not depend on LOGIN.  As
a rule, there's no point in depending on syslogd, just depend on
SERVERS instead.  This is actually what DAEMON is.  I'd say that
virtually all ports should "REQUIRE: DAEMON" unless they have more
specific requirements. For the database support, I'd suggest setting the
dependencies based on the ports configure options.  It's harmless to
depend on something that doesn't actually run, but annoying to depend on
something that doesn't exist.

The correct solution for databases is probably to add a new dummy
script DATABASES which all the database startup scripts should declare
they run BEFORE.  Then other startup scripts could REQUIRE that
unconditionally even if they aren't currently configured to use a
database and none are installed.

-- Brooks

--
Any statement of the form "X is the one, true Y" is FALSE.
PGP fingerprint 655D 519C 26A7 82E7 2529  9BF0 5D8E 8BE9 F238 1AD4

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: RC keywords question

Ion-Mihai Tetcu-2
On Mon, 5 Dec 2005 08:16:56 -0800
Brooks Davis <[hidden email]> wrote:

> On Mon, Dec 05, 2005 at 02:58:05PM +0200, Ion-Mihai Tetcu wrote:
> > Hi,
> >
> >
> > I'm converting my ports to work with the new HEAD RC style and
> > while at it I also thought to check the keywords to make sure
> > they're OK. Read rcorder(8) and rc(8).
> >
> > Let's take mail/dspam as an example. Obviously it PROVIDE: dspam
> >
> > When run in --daemon mode dspam receives messages via LMTP and
> > deliver them via SMTP. So it REQUIRE: NETWORK; it also uses syslogd
> > (which starts BEFORE: SERVERS).
> >
> > Now things start getting interesting.
> >
> > Since it's a content filter, it should start before the SMTP server.
> >
> > If SMTP server = sendmail|courier it's easy: BEFORE: mail
> >
> > If it's postfix it's:
> > - if it's started via /etc/rc.d/sendmail (sendmail_enable="YES" and
> > postfix in /etc/mail/mailer.conf) BEFORE: mail should be enough
> > (but see below);
> > - if sendmail_enable="NO" and /usr/local/sbin/postfix is linked in
> > rc.d as sendmail.sh then BEFORE: mail should be OK too since that's
> > before rc.d/localpkg (right ?)
> >
> > How to interact with various ways to start qmail I have yet to
> > discover.
> >
> > So until here I would have:
> > PROVIDE: dspam
> > REQUIRE: NETWORK syslogd
> > BEFORE: mail
> > and since mail REQUIRE: LOGIN this is actually:
> > REQUIRE: NETWORK syslogd LOGIN
> >
> > Q: should I write all the REQUIRE keywords or just the last one
> > (LOGIN) ?
> >
> >
> > OK, now dspam could also use mysql or pgsql; if the dependency is
> > set at compile time, it's easy to have the right REQUIRE; but dspam
> > can also use either or none, as instructed in dspam.conf so this is
> > also settable at run-time. How can I write the REQUIRE: line in
> > this case ?
>
>
> "BEFORE: mail" acts for most intents and purposes like all mail
> scripts contained "REQUIRE: dspam" so dspam does not depend on
> LOGIN.  As a rule, there's no point in depending on syslogd, just

I think it's better if I make sure dspam starts before its potential
consumers that the other way around; and this for one reason: I know
that my port's consumers are mail servers, but making each mail server
OPTIONally depend of each content filter is obviously unfeasible (of
course I counld ask the user to modify his server's rc script by hand).
Please correct me if I'm wrong.

> depend on SERVERS instead.  This is actually what DAEMON is.  I'd say
> that virtually all ports should "REQUIRE: DAEMON" unless they have
> more specific requirements.

So I should have REQUIRE: DAEMON and that's all ?
Do I understand this right: BEFORE is for approximately selecting when
the server should start while REQUIRE actually asks for something to be
running ?

> For the database support, I'd suggest
> setting the dependencies based on the ports configure options.  It's
> harmless to depend on something that doesn't actually run, but
> annoying to depend on something that doesn't exist.

In my case the user either select one database back-end and that is
statically compiled and then I e.g USE_MYSQL and I can write my BEFORE
line (that's what I'm doing now for mysql);

Or select multiple WITH_DB_NAME OPTIONS and have support for loading
any of them at runtime. For this case what I'm asking is: is there any
way  to hook-in a script that would parse dspam.conf, see what DB is set
and REQUIERE the right thing ?

> The correct solution for databases is probably to add a new dummy
> script DATABASES which all the database startup scripts should declare
> they run BEFORE.  Then other startup scripts could REQUIRE that
> unconditionally even if they aren't currently configured to use a
> database and none are installed.

And what do I do until then ? Or I just let the script as it is (.sh)
on 7.x also ?

Thanks,

--
IOnut - Unregistered ;) FreeBSD "user"
  "Intellectual Property" is   nowhere near as valuable   as "Intellect"

BOFH excuse #406:
Bad cafeteria food landed all the sysadmins in the hospital


_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-rc
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: RC keywords question

Yar Tikhiy-2
In reply to this post by Brooks Davis
On Mon, Dec 05, 2005 at 08:16:56AM -0800, Brooks Davis wrote:

> On Mon, Dec 05, 2005 at 02:58:05PM +0200, Ion-Mihai Tetcu wrote:
> >
> > I'm converting my ports to work with the new HEAD RC style and while at
> > it I also thought to check the keywords to make sure they're OK. Read
> > rcorder(8) and rc(8).
> >
> > Let's take mail/dspam as an example. Obviously it PROVIDE: dspam
> >
> > When run in --daemon mode dspam receives messages via LMTP and deliver
> > them via SMTP. So it REQUIRE: NETWORK; it also uses syslogd (which
> > starts BEFORE: SERVERS).
> >
> > Now things start getting interesting.
> >
> > Since it's a content filter, it should start before the SMTP server.
> >
> > If SMTP server = sendmail|courier it's easy: BEFORE: mail
> >
> > If it's postfix it's:
> > - if it's started via /etc/rc.d/sendmail (sendmail_enable="YES" and
> > postfix in /etc/mail/mailer.conf) BEFORE: mail should be enough (but see
> > below);
> > - if sendmail_enable="NO" and /usr/local/sbin/postfix is linked in rc.d
> > as sendmail.sh then BEFORE: mail should be OK too since that's before
> > rc.d/localpkg (right ?)
> >
> > How to interact with various ways to start qmail I have yet to discover.
> >
> > So until here I would have:
> > PROVIDE: dspam
> > REQUIRE: NETWORK syslogd
> > BEFORE: mail
> > and since mail REQUIRE: LOGIN this is actually:
> > REQUIRE: NETWORK syslogd LOGIN
> >
> > Q: should I write all the REQUIRE keywords or just the last one (LOGIN) ?

Ideally, one should put only REQUIRE keywords for those conditions
that are *actually required* by the service, and rcorder will take
care of the rest.

> > OK, now dspam could also use mysql or pgsql; if the dependency is set
> > at compile time, it's easy to have the right REQUIRE; but dspam can
> > also use either or none, as instructed in dspam.conf so this is also
> > settable at run-time. How can I write the REQUIRE: line in this case ?
>
> "BEFORE: mail" acts for most intents and purposes like all mail scripts
> contained "REQUIRE: dspam" so dspam does not depend on LOGIN.  As
> a rule, there's no point in depending on syslogd, just depend on
> SERVERS instead.  This is actually what DAEMON is.  I'd say that
> virtually all ports should "REQUIRE: DAEMON" unless they have more
> specific requirements. For the database support, I'd suggest setting the
> dependencies based on the ports configure options.  It's harmless to
> depend on something that doesn't actually run, but annoying to depend on
> something that doesn't exist.
>
> The correct solution for databases is probably to add a new dummy
> script DATABASES which all the database startup scripts should declare
> they run BEFORE.  Then other startup scripts could REQUIRE that
> unconditionally even if they aren't currently configured to use a
> database and none are installed.

Just an additional remark:

In a system with complex interactions it can be hard to order rc.d
scripts properly without help from services they start.  For instance,
the database can REQURE "mail".  Then either the mail daemon should
spool mail until dspam starts after the database, or dspam should
start early and return a temporary failure condition to the mail
daemon until it can connect to the database.  Similar considerations
apply to other practical cases.

--
Yar
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: RC keywords question

Yar Tikhiy-2
In reply to this post by Ion-Mihai Tetcu-2
On Mon, Dec 05, 2005 at 07:09:05PM +0200, Ion-Mihai Tetcu wrote:

> On Mon, 5 Dec 2005 08:16:56 -0800
> Brooks Davis <[hidden email]> wrote:
>
> > On Mon, Dec 05, 2005 at 02:58:05PM +0200, Ion-Mihai Tetcu wrote:
> > > Hi,
> > >
> > >
> > > I'm converting my ports to work with the new HEAD RC style and
> > > while at it I also thought to check the keywords to make sure
> > > they're OK. Read rcorder(8) and rc(8).
> > >
> > > Let's take mail/dspam as an example. Obviously it PROVIDE: dspam
> > >
> > > When run in --daemon mode dspam receives messages via LMTP and
> > > deliver them via SMTP. So it REQUIRE: NETWORK; it also uses syslogd
> > > (which starts BEFORE: SERVERS).
> > >
> > > Now things start getting interesting.
> > >
> > > Since it's a content filter, it should start before the SMTP server.
> > >
> > > If SMTP server = sendmail|courier it's easy: BEFORE: mail
> > >
> > > If it's postfix it's:
> > > - if it's started via /etc/rc.d/sendmail (sendmail_enable="YES" and
> > > postfix in /etc/mail/mailer.conf) BEFORE: mail should be enough
> > > (but see below);
> > > - if sendmail_enable="NO" and /usr/local/sbin/postfix is linked in
> > > rc.d as sendmail.sh then BEFORE: mail should be OK too since that's
> > > before rc.d/localpkg (right ?)
> > >
> > > How to interact with various ways to start qmail I have yet to
> > > discover.
> > >
> > > So until here I would have:
> > > PROVIDE: dspam
> > > REQUIRE: NETWORK syslogd
> > > BEFORE: mail
> > > and since mail REQUIRE: LOGIN this is actually:
> > > REQUIRE: NETWORK syslogd LOGIN
> > >
> > > Q: should I write all the REQUIRE keywords or just the last one
> > > (LOGIN) ?
> > >
> > >
> > > OK, now dspam could also use mysql or pgsql; if the dependency is
> > > set at compile time, it's easy to have the right REQUIRE; but dspam
> > > can also use either or none, as instructed in dspam.conf so this is
> > > also settable at run-time. How can I write the REQUIRE: line in
> > > this case ?
> >
> >
> > "BEFORE: mail" acts for most intents and purposes like all mail
> > scripts contained "REQUIRE: dspam" so dspam does not depend on
> > LOGIN.  As a rule, there's no point in depending on syslogd, just
>
> I think it's better if I make sure dspam starts before its potential
> consumers that the other way around; and this for one reason: I know
> that my port's consumers are mail servers, but making each mail server
> OPTIONally depend of each content filter is obviously unfeasible (of
> course I counld ask the user to modify his server's rc script by hand).
> Please correct me if I'm wrong.

IMHO this is a very good general point.  A mail server can live
without a content filter while the latter is meaningless without
the former.  So the filter's rc.d script should use `BEFORE: mail'.

> > depend on SERVERS instead.  This is actually what DAEMON is.  I'd say
> > that virtually all ports should "REQUIRE: DAEMON" unless they have
> > more specific requirements.
>
> So I should have REQUIRE: DAEMON and that's all ?
> Do I understand this right: BEFORE is for approximately selecting when
> the server should start while REQUIRE actually asks for something to be
> running ?

Why, BEFORE is just the antipode of REQUIRE.  REQUIRE asks for
something to run before this script while BEFORE asks for this
script to run before something.  The purpose for the two opposite
ways of telling the same dependence is explained above in your own
words:  When script A depends on script B, the information about
the dependence can belong to either A or B while the other script
should know nothing about it.

--
Yar
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-rc
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: RC keywords question

Yar Tikhiy-2
On Mon, Dec 05, 2005 at 08:26:58PM +0300, Yar Tikhiy wrote:

> > >
> > > "BEFORE: mail" acts for most intents and purposes like all mail
> > > scripts contained "REQUIRE: dspam" so dspam does not depend on
> > > LOGIN.  As a rule, there's no point in depending on syslogd, just
> >
> > I think it's better if I make sure dspam starts before its potential
> > consumers that the other way around; and this for one reason: I know
> > that my port's consumers are mail servers, but making each mail server
> > OPTIONally depend of each content filter is obviously unfeasible (of
> > course I counld ask the user to modify his server's rc script by hand).
> > Please correct me if I'm wrong.
>
> IMHO this is a very good general point.  A mail server can live
> without a content filter while the latter is meaningless without
> the former.  So the filter's rc.d script should use `BEFORE: mail'.

Just a small clarification: I don't mean that the filter must start
before mail.  I mean that it is the filter's rc.d script that should
contain the information for rcorder if any.  OTOH, the mail rc.d script
need not care about this issue at all.

--
Yar
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-rc
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: RC keywords question

Brooks Davis
In reply to this post by Ion-Mihai Tetcu-2
On Mon, Dec 05, 2005 at 07:09:05PM +0200, Ion-Mihai Tetcu wrote:

> On Mon, 5 Dec 2005 08:16:56 -0800
> Brooks Davis <[hidden email]> wrote:
>
> > On Mon, Dec 05, 2005 at 02:58:05PM +0200, Ion-Mihai Tetcu wrote:
> > > Hi,
> > >
> > >
> > > I'm converting my ports to work with the new HEAD RC style and
> > > while at it I also thought to check the keywords to make sure
> > > they're OK. Read rcorder(8) and rc(8).
> > >
> > > Let's take mail/dspam as an example. Obviously it PROVIDE: dspam
> > >
> > > When run in --daemon mode dspam receives messages via LMTP and
> > > deliver them via SMTP. So it REQUIRE: NETWORK; it also uses syslogd
> > > (which starts BEFORE: SERVERS).
> > >
> > > Now things start getting interesting.
> > >
> > > Since it's a content filter, it should start before the SMTP server.
> > >
> > > If SMTP server = sendmail|courier it's easy: BEFORE: mail
> > >
> > > If it's postfix it's:
> > > - if it's started via /etc/rc.d/sendmail (sendmail_enable="YES" and
> > > postfix in /etc/mail/mailer.conf) BEFORE: mail should be enough
> > > (but see below);
> > > - if sendmail_enable="NO" and /usr/local/sbin/postfix is linked in
> > > rc.d as sendmail.sh then BEFORE: mail should be OK too since that's
> > > before rc.d/localpkg (right ?)
> > >
> > > How to interact with various ways to start qmail I have yet to
> > > discover.
> > >
> > > So until here I would have:
> > > PROVIDE: dspam
> > > REQUIRE: NETWORK syslogd
> > > BEFORE: mail
> > > and since mail REQUIRE: LOGIN this is actually:
> > > REQUIRE: NETWORK syslogd LOGIN
> > >
> > > Q: should I write all the REQUIRE keywords or just the last one
> > > (LOGIN) ?
> > >
> > >
> > > OK, now dspam could also use mysql or pgsql; if the dependency is
> > > set at compile time, it's easy to have the right REQUIRE; but dspam
> > > can also use either or none, as instructed in dspam.conf so this is
> > > also settable at run-time. How can I write the REQUIRE: line in
> > > this case ?
> >
> >
> > "BEFORE: mail" acts for most intents and purposes like all mail
> > scripts contained "REQUIRE: dspam" so dspam does not depend on
> > LOGIN.  As a rule, there's no point in depending on syslogd, just
>
> I think it's better if I make sure dspam starts before its potential
> consumers that the other way around; and this for one reason: I know
> that my port's consumers are mail servers, but making each mail server
> OPTIONally depend of each content filter is obviously unfeasible (of
> course I counld ask the user to modify his server's rc script by hand).
> Please correct me if I'm wrong.
Yes, you should be using BEFORE here because you need dspam to run
before any PROVIDEr of "mail" and you can't assume all providers will be
modified.  This is what BEFORE is for.

> > depend on SERVERS instead.  This is actually what DAEMON is.  I'd say
> > that virtually all ports should "REQUIRE: DAEMON" unless they have
> > more specific requirements.
>
> So I should have REQUIRE: DAEMON and that's all ?

Yes.  For virtualy every case, this is what what you want to do.

> Do I understand this right: BEFORE is for approximately selecting when
> the server should start while REQUIRE actually asks for something to be
> running ?

If there is only one provider of what ever your service script if
providing, "BEFORE: someservice" exactly the same as adding "REQUIRE:
yourservice" to all files that provide "someservice".

> > For the database support, I'd suggest
> > setting the dependencies based on the ports configure options.  It's
> > harmless to depend on something that doesn't actually run, but
> > annoying to depend on something that doesn't exist.
>
> In my case the user either select one database back-end and that is
> statically compiled and then I e.g USE_MYSQL and I can write my BEFORE
> line (that's what I'm doing now for mysql);
>
> Or select multiple WITH_DB_NAME OPTIONS and have support for loading
> any of them at runtime. For this case what I'm asking is: is there any
> way  to hook-in a script that would parse dspam.conf, see what DB is set
> and REQUIERE the right thing ?
At this point you must add REQUIRE lines for any database that you
depend on at compile time.  If users choose to find a way to circumvent
that, there's nothing you can do.  Note that it's OK to depend on a
startup script that isn't enabled.  rcorder, unlike launchd, doesn't
care.

> > The correct solution for databases is probably to add a new dummy
> > script DATABASES which all the database startup scripts should declare
> > they run BEFORE.  Then other startup scripts could REQUIRE that
> > unconditionally even if they aren't currently configured to use a
> > database and none are installed.
>
> And what do I do until then ? Or I just let the script as it is (.sh)
> on 7.x also ?

We could MFC such a script to RELENG_6 so I don't see a major support
issue here.

-- Brooks

--
Any statement of the form "X is the one, true Y" is FALSE.
PGP fingerprint 655D 519C 26A7 82E7 2529  9BF0 5D8E 8BE9 F238 1AD4

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: RC keywords question

Brooks Davis
In reply to this post by Yar Tikhiy-2
On Mon, Dec 05, 2005 at 08:14:16PM +0300, Yar Tikhiy wrote:
> Just an additional remark:
>
> In a system with complex interactions it can be hard to order rc.d
> scripts properly without help from services they start.  For instance,
> the database can REQURE "mail".  Then either the mail daemon should
> spool mail until dspam starts after the database, or dspam should
> start early and return a temporary failure condition to the mail
> daemon until it can connect to the database.  Similar considerations
> apply to other practical cases.

Loops are definitely something to be watched out for, but this one is
a somewhat poor example, IMO.  Looking at the "mail" scripts in the
base, it's clear that they are intended to provide the local delivery
agent.  If the particular mail system needs daemons running for local
mail submission to work, those daemons must start much earlier (probably
BEFORE: SERVERS).

-- Brooks

--
Any statement of the form "X is the one, true Y" is FALSE.
PGP fingerprint 655D 519C 26A7 82E7 2529  9BF0 5D8E 8BE9 F238 1AD4

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: RC keywords question

Yar Tikhiy-2
On Mon, Dec 05, 2005 at 02:00:53PM -0800, Brooks Davis wrote:

> On Mon, Dec 05, 2005 at 08:14:16PM +0300, Yar Tikhiy wrote:
> > Just an additional remark:
> >
> > In a system with complex interactions it can be hard to order rc.d
> > scripts properly without help from services they start.  For instance,
> > the database can REQURE "mail".  Then either the mail daemon should
> > spool mail until dspam starts after the database, or dspam should
> > start early and return a temporary failure condition to the mail
> > daemon until it can connect to the database.  Similar considerations
> > apply to other practical cases.
>
> Loops are definitely something to be watched out for, but this one is
> a somewhat poor example, IMO.  Looking at the "mail" scripts in the
> base, it's clear that they are intended to provide the local delivery
> agent.  If the particular mail system needs daemons running for local
> mail submission to work, those daemons must start much earlier (probably
> BEFORE: SERVERS).

Have you ever met lame software trying to send mail about its
condition directly by SMTP to a pre-set local relay?  So a database
engine can, in theory, requre "mail".  Of course, I won't advise
using such a bogus DB engine, but my example isn't too poor either ;-)

--
Yar
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-rc
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: RC keywords question

Brooks Davis
On Tue, Dec 06, 2005 at 08:13:30AM +0300, Yar Tikhiy wrote:

> On Mon, Dec 05, 2005 at 02:00:53PM -0800, Brooks Davis wrote:
> > On Mon, Dec 05, 2005 at 08:14:16PM +0300, Yar Tikhiy wrote:
> > > Just an additional remark:
> > >
> > > In a system with complex interactions it can be hard to order rc.d
> > > scripts properly without help from services they start.  For instance,
> > > the database can REQURE "mail".  Then either the mail daemon should
> > > spool mail until dspam starts after the database, or dspam should
> > > start early and return a temporary failure condition to the mail
> > > daemon until it can connect to the database.  Similar considerations
> > > apply to other practical cases.
> >
> > Loops are definitely something to be watched out for, but this one is
> > a somewhat poor example, IMO.  Looking at the "mail" scripts in the
> > base, it's clear that they are intended to provide the local delivery
> > agent.  If the particular mail system needs daemons running for local
> > mail submission to work, those daemons must start much earlier (probably
> > BEFORE: SERVERS).
>
> Have you ever met lame software trying to send mail about its
> condition directly by SMTP to a pre-set local relay?  So a database
> engine can, in theory, requre "mail".  Of course, I won't advise
> using such a bogus DB engine, but my example isn't too poor either ;-)
A valid point.  Of course the code either works correctly when a
dependency doen't work, or it's totally hopeless and you will have to
ditch the database in question. :)

-- Brooks

--
Any statement of the form "X is the one, true Y" is FALSE.
PGP fingerprint 655D 519C 26A7 82E7 2529  9BF0 5D8E 8BE9 F238 1AD4

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: RC keywords question

dougb
In reply to this post by Ion-Mihai Tetcu-2
Hopefully by new your actual question has been adequately answered, however
I wanted to reemphasize one point from this thread because it will be very
important for port authors to understand as we move into the world of ports
being run as part of the base rcorder.

The REQUIRE line does not guarantee that a service will be running when your
script starts, it only specifies to rcorder what has to happen before this
script is run. Therefore, your application must handle any error conditions
that may result if the service you depend on is not actually running when
your script tries to run.

hth,

Doug

--

     This .signature sanitized for your protection

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[hidden email]"