Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 09 Sep 2015 18:54:52 +0700
From:      Olivier Nicole <Olivier.Nicole@cs.ait.ac.th>
To:        Polytropon <freebsd@edvax.de>
Cc:        questions@freebsd.org
Subject:   Re: One daemon not starting in /etc/rc.local
Message-ID:  <wu7mvwvolir.fsf@banyan.cs.ait.ac.th>
In-Reply-To: <20150909134348.0668c422.freebsd@edvax.de> (message from Polytropon on Wed, 9 Sep 2015 13:43:48 %2B0200)

next in thread | previous in thread | raw e-mail | index | archive | help
Polytropon <freebsd@edvax.de> writes:

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

That was a try before I added the echo iii lines. I wanted to see where
in the startup sequece /etc/rc.local was called and kind of make sure it
was after the network interfaces had been started.

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

In fact I discovered that FreeBSD alread has that startup script, though
it is installed along with amavisd-new.

>
>
>> 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/p0f-analyzer.pl 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)?

I switched down to sh for the manual test.

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

A wild guess is that it has something to do with the fact that p0f
writes to stdout and stdout is piped to stdin of the next process. 

Maybe whatever is started via rc should never hold on the stdin/stdout?

I noticed that in the startup script provided in amavis port, the
command is started via /usr/bin/daemon, so purposedly detaching the
control terminal.

Thank you anyway,

Olivier

-- 



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?wu7mvwvolir.fsf>