Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:46509
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain l-i-e.com designates 67.139.134.202 as permitted sender)
Message-ID: <2672.98.193.1261589684.squirrel@www.l-i-e.com>
In-Reply-To: <4B325191.6020102@lerdorf.com>
References: <4B31D462.9080507@lerdorf.com>
    <10845a340912230623o42fbcc7eqbeb354392917fd03@mail.gmail.com>
    <4B325191.6020102@lerdorf.com>
Date: Wed, 23 Dec 2009 11:34:44 -0600 (CST)
To: "Rasmus Lerdorf" <rasmus@lerdorf.com>
Cc: "PHP Developers Mailing List" <internals@lists.php.net>
User-Agent: Hostbaby Webmail
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Importance: Normal
Subject: Re: [PHP-DEV] ignore_user_abort=true for sapi/cli
From: ceo@l-i-e.com ("Richard Lynch")

On Wed, December 23, 2009 11:21 am, Rasmus Lerdorf wrote:
> Richard Quadling wrote:
>> 2009/12/23 Rasmus Lerdorf <rasmus@lerdorf.com>:
>>> Can anyone think of a situation where you actually want our current
>>> ignore_user_abort=false setting for the cli sapi?
>>
>> I would say that the default setting is pretty important as pressing
>> CTRL+C (at least on windows) is the quickest way of killing a PHP
>> cli
>> based script without killing the shell/console or loading the task
>> manager (or similar), finding the right instance of PHP and then
>> killing it.
>
> Again, ignore_user_abort has no effect on signal handling.  A SIGTERM
> is
> going to kill the process regardless of the ignore_user_abort setting.
>
> ignore_user_abort is a simple boolean that guides whether to abort
> when
> PHP is unable to write to whatever output mechanism the sapi uses.
> For
> cli that would be stdout.  If for some reason your cli script's tty
> goes
> away without the script being terminated then your script will die the
> next time it tries to write anything because ignore_user_abort is off
> by
> default.  One situation where this is likely is when you specifically
> background and nohup your cli script.  Right now unless you also set
> ignore_user_abort to true in your script, it will die on any sort of
> output.  There are other cases as well.

If my SSH session conks out, I'd kind of like it to just kill of the
PHP process by default, since I'll try to log back in and start over.

I guess that's a reasonable expectation to keep it that way.

I realize, of course, that a Un*x guru like you is going to know some
fancy dancy way to re-attach your new tty/shell thingie to the
still-running PHP process when you log back in, but your average
developer, not so much. :-)

I probably have unknowingly relied on this behaviour more times than I
can count, personally.

I could probably get used to it if it changed though.

Actually, for a long-running php script, or a shaky connection, I
usually re-direct to a log file and background it, but even that is
more than some "Devs" are going to "get".

-- 
Some people ask for gifts here.
I just want you to buy an Indie CD for yourself:
http://cdbaby.com/search/from/lynch