Re: [gentoo-portage-dev] EbuildProcess logs poll-error to already removed $T (on AIX)

[Perry Smith]

On Mar 28, 2011, at 10:56 AM, Zac Medico wrote:

> On 03/28/2011 03:05 AM, Michael Haubenwallner wrote:
>>
>>
>> On 03/25/2011 05:23 PM, Zac Medico wrote:
>>>> * EbuildProcess received strange poll event: 16384
>>
>>> You can compare 16384 to the values of POLLERR and POLLNVAL in order to
>>> see what type of event it is. Apparently the values on AIX are different
>>> from those on Linux, because here's what I see on Linux:
>>
>> On AIX 5.3 this is:
>>
>> Python 2.7.1 (r271:86832, Feb 28 2011, 17:51:02)
>> [GCC 4.2.4 (Gentoo 4.2.4-r01.2 p1.1)] on aix5
>> Type "help", "copyright", "credits" or "license" for more information.
>>>>> import select
>>>>> dir(select)
>> ['PIPE_BUF', 'POLLERR', 'POLLHUP', 'POLLIN', 'POLLMSG', 'POLLNVAL', 'POLLOUT',
>> 'POLLPRI', 'POLLRDBAND', 'POLLRDNORM', 'POLLWRBAND', 'POLLWRNORM', '__doc__',
>> '__file__', '__name__', '__package__', 'error', 'poll', 'select']
>>>>> select.POLLNVAL
>> 32768
>>>>> select.POLLERR
>> 16384
>
> So, apparently POLLERR is the "strange poll event" that's being received.
>
>> On AIX 6.1 it looks similar except for missing 'PIPE_BUF'.
>>
>>> This will handle the IOError:
>>> http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=0a64f784003c11e151405b7f708d77770de0ed57
>>
>> Yes, that makes it work, thank you!
>>
>>> It might be risky to skip logging of the POLLNVAL / POLLERR events, so
>>> hopefully we can determine their cause and handle them somehow. Do they
>>> seem to cause any problems? It might be something specific about pty
>>> devices on AIX.
>>
>> There doesn't seem to go anything wrong so far.
>
> Maybe on AIX, POLLERR is essentially equivalent to POLLHUP in this case.
> If that's true, then we could conditionally modify portage's
> PollConstants class for AIX like this:
>
> diff --git a/pym/_emerge/PollConstants.py b/pym/_emerge/PollConstants.py
> index d0270a9..73a3908 100644
> --- a/pym/_emerge/PollConstants.py
> +++ b/pym/_emerge/PollConstants.py
> @@ -1,6 +1,7 @@
> # Copyright 1999-2009 Gentoo Foundation
> # Distributed under the terms of the GNU General Public License v2
>
> +import platform
> import select
> class PollConstants(object):
>
> @@ -16,3 +17,8 @@ class PollConstants(object):
> 		v *= 2
> 	del k, v
>
> +if platform.system() in ('AIX',):
> +	# Interpret POLLERR like POLLHUP.
> +	PollConstants.POLLHUP = \
> +		PollConstants.POLLHUP | PollConstants.POLLERR
> +	PollConstants.POLLERR = 0
>
> Does platform.system() return "AIX" exactly as I spelled it?
>
>> I've no idea about programming with pty devices at all.
>> However, one relevant (IMHO) thing I can see is:
>> portage/util/_pty.py:_can_test_pty_eof() returns True for Linux only.
>>
>> Anything I can try out?
>
> You can check whether or not pty support is enabled in portage like this:
>
> python -c 'import portage.util._pty, sys;
> sys.stdout.write(str(portage.util._pty._disable_openpty))'

I did not 100% follow this.  In particular, I didn't see how we started talking about pty's.  But, since you are, I'll wade in.

When the master side (the side that a daemon opens like telnetd) closes, the slave side gets the same treatment as if a modem hung up on a real tty.  This is a SIGHUP *and* any further writes will return EIO (5) and further reads return 0.  (All this is assuming CLOCAL is off.)

I would not be surprised if the child process is receiving a SIGHUP if all the process session and controlling tty requirements have been met and the file descriptor is also selectable for POLLHUP and POLLERR.  I would peek inside the Python code because perhaps it is testing for POLLERR before it is testing for POLLHUP.  Or, perhaps it is not expecting the POLLERR at all (that is the 16384 value)

This should *not* be AIX specific but is actually POSIX standard.

Does that help?

pedz