One daemon not starting in /etc/rc.local

Polytropon freebsd at
Wed Sep 9 11:43:53 UTC 2015

On Wed, 09 Sep 2015 14:19:57 +0700, Olivier Nicole wrote:
> In /etc/rc.local I have:
> # REQUIRE: networking DAEMON FILESYSTEMS devfs
> # PROVIDE: p0f recover-backup count-stats

Does rc.local pay attention to this kind of comments?
It was my impression that both rc.local and rc.shutdown.local
are "dumb" and determined by execution time...

I tend to associate the REQUIRE and PROVIDE keywords
with the rc ordering mechanism which rc.d/ style files
use so they can be run the correct order. As I mentioned,
rc.local's runtime is determined by /etc/rc itself.

>From "man rc.local":

     [...] The rc.local script contains com-
     mands which are pertinent only to a specific site.  Typically, the
     /usr/local/etc/rc.d/ mechanism is used instead of rc.local these days but
     if you want to use rc.local, it is still supported.  In this case, it
     should source /etc/rc.conf and contain additional custom startup code for
     your system.  The best way to handle rc.local, however, is to separate it
     out into rc.d/ style scripts and place them under /usr/local/etc/rc.d/.

So if you can, create and rc.d/ style script and put it
into /usr/local/etc/rc.d/ including the keywords mentioned

> echo iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii
> # start the OS fingerprint analyzer
> # -l means on line per record!
> /usr/local/bin/p0f -i vmx0  'tcp dst port 25' 2>&1|/usr/local/bin/ 2345 &
> echo iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii
> At boot I see the 2 lines of iii but p0f is not started.
> If I copy/paste in sheel the line /usr/local/bin/p0f etc. it starts,
> prints the start-up message and runs happilly.

Is the "non-use" of spaces in the segment "2>&1|/usr/local/bin/p0f"
significant? Is the shell where you're interactively executing the
command different from the shell that runs rc.local (/bin/sh)?

> There must be a trivial error, but I can't see it, so any help will be
> greatly appreciated.

Except what might be pure form, I don't see any errors, so the
reason for the different behaviour might be in the environment...

Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...

More information about the freebsd-questions mailing list