On 8/26/06, Axel Liljencrantz <[EMAIL PROTECTED]> wrote:
> On 8/26/06, Martin Bähr <[EMAIL PROTECTED]> wrote:
> > hi,
> >
> > stumbled on another wierd bug that i can't make any sense of:
> >
> > > cat foo | while read i j; echo $i,$j; mv -i $i {$j}.ttf; end | less
> > mv: cannot stat `163641.ttf': No such file or directory
> > mv: cannot stat `1336501.ttf': No such file or directory
> > mv: cannot stat `961162.ttf': No such file or directory
> > mv: overwrite `Arial.ttf'? fish: Could not send process 16515 from group
> > 16377 to group 16506
> > setpgid: Operation not permitted
> > fish: Could not send job 1 (#cat foo | while read i j; echo $i,$j; mv -i $i
> > {$j}.ttf; end | less#) to foreground
> > tcsetpgrp: Operation not permitted
> > 163641.ttf,Andover
> > 1336501.ttf,Arial
> > 961162.ttf,Arial
> > 912439.ttf,Arial
> > fish: Could not send process 16516 from group 16377 to group 16506
> > setpgid: Operation not permitted
> > fish: Could not send job 1 (#cat foo | while read i j; echo $i,$j; mv -i $i
> > {$j}.ttf; end | less#) to foreground
> > tcsetpgrp: Operation not permitted
> > fish: Could not send job 1 (#cat foo | while read i j; echo $i,$j; mv -i $i
> > {$j}.ttf; end | less#) to foreground
> > tcsetpgrp: Operation not permitted
> > Missing filename ("less --help" for help)
> >
> > at this point the whole thing hangs uninteruptably
> >
> > the contents of foo are lines like:
> > 293856.ttf Celticmd Decorative w Drop Caps
> > 961164.ttf Font in a Red Suit (The Christmas Font)
> > 163644.ttf Font
> > 163654.ttf Yikes!
> >
> > (don't ask me about the fonts these are files recovered from a disk crash
> > :-)
>
> I can reproduce this behaviour when in interactive mode. Seems to be a
> problem with blocks in pipelines that only surfaces in interactive
> mode. Will look into it.
Ouch. Subtle issue. What happened was that at some point during the
job's execution, all created processes in the job had exited, which
means that the process group of the job also expired (This happens
automatically, you can't control the lifetime of a process group other
than by not killing all processes in the group). So when fish forked
of new processes and tried to add them to the process group of the
job, this operation failed, since the group was no more.
I wrote a fix that simply creates a new process group if the first one
no longer exists. I am unsure if this is a fix that works, since it
has the potential side effect that a job can change group id during
it's execution. This shouldn't be a big issue, since this can only
happen while fish is forking of new children to start a job, so the
original process group should never ever be user visible. But still,
it might cause some issue I haven't though of.
The alternative solution that I can see is to fork of a 'group
keepalive process' whenever fish detects that this issue could arise.
(Specifically, this can only happen when using a block inside a
pipeline) This could also be user visible through event handlers
listening to signals, etc.
If anyone on-list is a signal and process group expert, please
enlighten me as to what solution you think is least risky.
[...]
>
>
> --
> Axel
>
--
Axel
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Fish-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/fish-users
