Interrupting find(1)

Thread View: net.bugs.4bsd

3 messages

[T] Back to Threads [V] Tree View [G] Group Articles

3 total messages Started by Ian Donaldson Wed, 17 Sep 1986 15:56

#1683

Author: Ian Donaldson
Date: Wed, 17 Sep 1986 15:56

42 lines
1810 bytes

Ever wondered why its difficult to abort find(1) during -exec processing?

ie:	find / -print -exec ls -l {} \;
 	^C
	^C
	^C
	aarrgh! its still not stopped!

You usually end up having to hit ^C (or DEL if you prefer) several times
in order for it to stop.  The only reliable way of stopping such a
command is to ^Z it and use kill(1).

This is because there is a piece of code in there that does basically this:

		if(fork()) {
			oint = signal(SIGINT, SIG_IGN);
			oquit = signal(SIGQUIT, SIG_IGN);
			wait( for the -exec process to finish );
			signal(SIGINT, oint);
			signal(SIGQUIT, oquit);
			}
		else {
			handle the exec'd process
			}

Chances are that when you hit ^C, the wait() is in process, and will
end up killing the exec'd process, but the interrupt is ignored by
find(1), and so it proceeds on its merry way exec'ing more things...

The fix would be simply to change SIG_IGN to SIG_HOLD in both statements.

I suspect the same thing happens with find(1) under SVR2 systems, 
but their ain't much you can do about it since there's no SIG_HOLD mode 
under SVR2.

This behaviour was observed with 4.2bsd find(1) on both a Sun-2 and a Vax-750.

I hope that 4.3 has it fixed.

Please forgive me if this has already been brought up.

Ian Donaldson.

Re: Interrupting find(1)

#1685

Author: Guy Harris
Date: Wed, 24 Sep 1986 06:57

21 lines
1335 bytes

> Chances are that when you hit ^C, the wait() is in process, and will
> end up killing the exec'd process, but the interrupt is ignored by
> find(1), and so it proceeds on its merry way exec'ing more things...

"Fixed in 4.3."

> The fix would be simply to change SIG_IGN to SIG_HOLD in both statements.

But not that way.  SIG_HOLD only appears in "/usr/include/sys/signal.h" as a
historical holdover; setting the signal action to SIG_HOLD will *not* set
the "p_sigmask" bit for that signal, so it won't hold it.  The correct fix
is to put a "sigblock"/"sigsetmask" pair around the "wait".

> This behaviour was observed with 4.2bsd find(1) on both a Sun-2 and a
> Vax-750.

There's some chance you'll see it on other VAX models, too.
-- 
	Guy Harris
	{ihnp4, decvax, seismo, decwrl, ...}!sun!guy
	guy@sun.com (or guy@sun.arpa)

Re: Interrupting find(1)

#1690

Author: Ed Hall
Date: Fri, 26 Sep 1986 07:40

14 lines
1296 bytes

In article <7566@sun.uucp> guy@sun.uucp (Guy Harris) writes:
>> The fix would be simply to change SIG_IGN to SIG_HOLD in both statements.
>
>But not that way.  SIG_HOLD only appears in "/usr/include/sys/signal.h" as a
>historical holdover; setting the signal action to SIG_HOLD will *not* set
>the "p_sigmask" bit for that signal, so it won't hold it.  The correct fix
>is to put a "sigblock"/"sigsetmask" pair around the "wait".

	--or look at the status returned by wait(), and exit appropriately
	if the child process was killed by SIGINT...  This would even work
	on Vanilla V7 systems (assuming any are still around).

		-Ed Hall
		decvax!randvax!edhall

Thread Navigation

This is a paginated view of messages in the thread with full content displayed inline.

Messages are displayed in chronological order, with the original post highlighted in green.

Use pagination controls to navigate through all messages in large threads.

Back to All Threads