[aklug] Re: linux bash backgrounding and I/O redirection

On Mon, Jul 23, 2012 at 6:21 PM, Jim MacDonald <jim@macdonald.org> wrote:
> How did you redirect? 2>&1 ?

Jim, I was really only answering the forking/proc control issue, as I
had initially tried that method myself (launching a process, waiting,
checking to see if it's still running, then killing it) before I
realized that it didn't do what I actually needed it to do.

Hmm. In my case I don't really redirect qua redirect. I use socat with
EXEC:"cat - > foo.mp3". That's a simplification; the cat is really in
a separate process so umask can do some voodoo.

I am not redirecting stderr in any of this because my script is a)
running on Mac OS X, FreeBSD, and b) is a LaunchDaemon, responding to
incoming traffic on a TCP port. stderr gets logged to the standard
console logging (/var/log/system.log) by default, which is what I
want.

To recap: when packets come in on listening socket, they get passed to
a bash script which launches socat. Socat reads from stdin, the usual
'-' option, EXECs a second script (due to a limitation of socat's EXEC
function) which is basically "umask; cat - > foo.mp3". All
straightforward stdin/stdout.

I wrote this two years ago, and can post code if it's interesting to
you. It's been in production flawlessly since.

This works for the type of logger I made, which is designed to record
an audio circuit, public address in this case, so that whenever the
microphones are open, mp3 data is logged. I'm using a Barix Instreamer
to do the A/D conversion, as it has a useful level-activated TCP push
function. (I tried implementing this entirely in software for about 5
years, then gave up.) I modeled my script after Barix-provided Windows
code.

If I were logging a radio station, in contrast, it would need to
record steadily, with periodic timestamps of some kind, much like
technocurmudgeon is needing. Funny, I was just looking at someone
else's logger the other day http://stephenkelly.ca/ckdu-os/?q=node/3
which 'cheats' by using mp3cat, set to stop recording at a particular
file size.

Needless to say, that method could easily produce unreliable files; if
there were an interruption in the MP3 stream, then it would get out of
sync, at least until the next hourly rollover.

In my case, I'm not a radio station, so it doesn't matter.
Hope this helps.

technocurmudgeon, if you're logging gps freq data, what about another
approach; how about logging to a database, for which you tail the
incoming stream, and insert each new row into a DB (with a handy
timestamp column)?

jermudgeon
---------
To unsubscribe, send email to <aklug-request@aklug.org>
with 'unsubscribe' in the message body.
Received on Mon Jul 23 19:52:38 2012