redirection tricks on processor invocation

redirection tricks on processor invocation

[Joan Picanyol i Puig]

Dear all,

I have an application that generates aggregate reports from separate
log streams. In order to avoid loosing data, it should be invoked as a
processor from all of it's sources log directories. The application
reads from stdin (and thus know what stream it is called from and what
other streams should look at). However, I don't the resultant log file
to be altered (since I must archive it for auditing purposes).

I've been struggling to find the correct fd copying and redirections so
that whenever runit feeds @*.u to my processor a copy of it is sent to
stdout (the application writes to a separate location), but to no avail. 

In summary, I want a copy of my processor's stdin to be seen by svlogd
as my processor's stdout. Any ideas?

tks
-- 
pica

Re: redirection tricks on processor invocation

[Laurent Bercot]

> In summary, I want a copy of my processor's stdin to be seen by svlogd
> as my processor's stdout. Any ideas?

 Use multitee: http://code.dogmap.org/fdtools/multitee/

 Your processor could be, for instance, if you have execline installed:
 exec execlineb -c "
  piperw 6 7
  background { fdclose 7 fdmove 0 6 yourapplication }
  fdclose 6
  multitee 0-1,7
 "

 which copies stdin to stdout untouched, but also feeds a copy of
stdin to yourapplication's stdin.

-- 
 Laurent

Re: redirection tricks on processor invocation

[Joan Picanyol i Puig]

* Laurent Bercot <ska-supervision@skarnet.org> [20090603 08:27]:
> > In summary, I want a copy of my processor's stdin to be seen by svlogd
> > as my processor's stdout. Any ideas?
> 
>  Use multitee: http://code.dogmap.org/fdtools/multitee/
> 
>  Your processor could be, for instance, if you have execline installed:
>  exec execlineb -c "
>   piperw 6 7
>   background { fdclose 7 fdmove 0 6 yourapplication }
>   fdclose 6
>   multitee 0-1,7
>  "
> 
>  which copies stdin to stdout untouched, but also feeds a copy of
> stdin to yourapplication's stdin.

That's exactly what I want. Given that piperw apparently has no shell
equivalent without a named pipe I guess it's time for me to bite the
bullet and just use skalibs.

tks
--
pica

Re: redirection tricks on processor invocation

[Joan Picanyol i Puig]

* Joan Picanyol i Puig <lists-supervision@biaix.org> [20090603 12:31]:
> * Laurent Bercot <ska-supervision@skarnet.org> [20090603 08:27]:
> > > In summary, I want a copy of my processor's stdin to be seen by svlogd
> > > as my processor's stdout. Any ideas?
> > 
> >  Use multitee: http://code.dogmap.org/fdtools/multitee/
> > 
> >  Your processor could be, for instance, if you have execline installed:
> >  exec execlineb -c "
> >   piperw 6 7
> >   background { fdclose 7 fdmove 0 6 yourapplication }
> >   fdclose 6
> >   multitee 0-1,7
> >  "
> > 
> >  which copies stdin to stdout untouched, but also feeds a copy of
> > stdin to yourapplication's stdin.
> 
> Given that piperw apparently has no shell equivalent without a named
> pipe I guess it's time for me to bite the bullet and just use skalibs.

Actually, it's multitee's dependency in skalibs that makes me bite the
bullet (I should be able to avoid named pipes using subshells in my
processor's script.

qvb
--
pica

Re: redirection tricks on processor invocation

[Joan Picanyol i Puig]

* Joan Picanyol i Puig <lists-supervision@biaix.org> [20090603 12:38]:
> * Joan Picanyol i Puig <lists-supervision@biaix.org> [20090603 12:31]:
> > * Laurent Bercot <ska-supervision@skarnet.org> [20090603 08:27]:
> > > > In summary, I want a copy of my processor's stdin to be seen by svlogd
> > > > as my processor's stdout. Any ideas?
> > > 
> > >  Use multitee: http://code.dogmap.org/fdtools/multitee/
> > > 
> > >  Your processor could be, for instance, if you have execline installed:
> > >  exec execlineb -c "
> > >   piperw 6 7
> > >   background { fdclose 7 fdmove 0 6 yourapplication }
> > >   fdclose 6
> > >   multitee 0-1,7
> > >  "
> > > 
> > >  which copies stdin to stdout untouched, but also feeds a copy of
> > > stdin to yourapplication's stdin.
> > 
> > Given that piperw apparently has no shell equivalent without a named
> > pipe
> 
> I should be able to avoid named pipes using subshells in my
> processor's script.

A week later, I've been unable to translate this simple execline snippet
to shell syntax. I can't figure out a way to workaround the fact that
shell pipes are created before redirection. Any hints?

tks
--
pica

Re: redirection tricks on processor invocation

[Laurent Bercot]

> A week later, I've been unable to translate this simple execline snippet
> to shell syntax. I can't figure out a way to workaround the fact that
> shell pipes are created before redirection. Any hints?

 Your problem is that the shell can't open anonymous fds. The only way
to get an anonymous pipe is the | construct, which does not open more fds
because it's redirected at once to 1 and 0.
 The multitee command needs one more fd to be opened, and you can't do
that with anonymous pipes. You need a named pipe for this:

 mkfifo /tmp/fifo ;
 yourapplication </tmp/fifo &
 exec 7>/tmp/fifo multitee 0-1,7

 Inelegant? Unsatisfying?
 Go forth, o my convert, and preach the virtues of execline. :)

-- 
 Laurent