Date: Wed, 9 Sep 2015 15:02:43 +0200 From: Polytropon <freebsd@edvax.de> To: Olivier Nicole <Olivier.Nicole@cs.ait.ac.th> Cc: questions@freebsd.org Subject: Re: One daemon not starting in /etc/rc.local Message-ID: <20150909150243.e6553ca5.freebsd@edvax.de> In-Reply-To: <wu7mvwvolir.fsf@banyan.cs.ait.ac.th> References: <20150909134348.0668c422.freebsd@edvax.de> <wu7mvwvolir.fsf@banyan.cs.ait.ac.th>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 09 Sep 2015 18:54:52 +0700, Olivier Nicole wrote: > 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. If I remember correctly, this file will be executed via /etc/rc.d/local, depending on the (default) keywords found in _that_ file, but only if /etc/rc.local actually does exist. > >> 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. Okay, then the only difference could be environmental variables not set at the earlier stage (or inherited from the interactive session). The C shell of course would complaim about 2>&1. :-) > >> 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. Yes, that is possible - in the context of subshells executing further commands with redirection; foreground vs. background vs. daemonized... > 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. Exactly that was my thought. Things like nohup, daemon or detach can lead to interesting results when redirection is added. :-) -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ...
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150909150243.e6553ca5.freebsd>