[Mailman-Users] socket.gethostname()

[Richard Barrett]

On Thursday, November 6, 2003, at 10:43  pm, John Poltorak wrote:

> On Thu, Nov 06, 2003 at 05:59:28PM +0000, Richard Barrett wrote:
>
>>>>>>> import socket
>>>>>>> socket.gethostname()
>>>> 'mailman2'
>>>
>>> Where does value originate and should it match anything within
>>> Mailman's
>>> configuration?
>>>
>>
>> It originates within the system kernel. Read the man page for 
>> hostname.
>> Like hostname, socket.gethostname() is calling a system C library
>> function to get the information, which is quite independent of 
>> Mailman.
>
> I suppose I need to run it independently of Apache to see what is 
> really
> going on.
>
>
>>> Is there any way to dump the value of  self.__tmpfname to the logfile
>>> from
>>> the lines above ?
>>>
>>
>> No because you would not running Mailman, just the Python interpreter
>> from the command line.
>>
>>> This is what currently appears in the error log:-
>>>
>>>
>>> admin(648):   File "../Mailman/MailList.py", line 817, in __save
>>> admin(648):     fname_tmp = fname + '.tmp.%s.%d' %
>>> (socket.gethostname(), os.getpid())
>>> admin(648): error: (14, 'Bad address')
>>>
>>>
>>
>> This is a system error code, EFAULT, which means "Bad address",
>> whatever that means. It is certainly abnormal and I suspect not a
>> problem in MM per se. It could indicate an incipient memory problem or
>> corrupt libraries or kernel or ...
>
> I'm actually trying to get a ported version running. I'm not using 
> Unix.

In that case the problem may be highlighting a deficiency in the 
'UNIX-like' environment in which Python and Mailman are being asked to 
operate. The error seems to indicate that the Python port is trying to 
produce an emulation of a UNIX environment but failing at times.

>
>> After discussion with a colleague we decided we couldn't identify any
>> simple, obvious cause or course of action to take but it sounded like
>> something was broken in the system.
>>
>> Is this a persistent or occasional problem?
>
> I'm just trying to get it set up, that's all.

I was trying to find out if this was a reproducible problem.

>
>> My first instincts are to reboot the system, maybe run a few
>> diagnostics on memory and disk, and a full fsck and see if that clears
>> it. With my knowledge of things this is SWAG territory.
>>
>>> I'm assuming that socket.gethostname() is the culprit.
>>>
>>
>> If you called socket.gethostname() from the Python command line as I
>> suggested  in my previous message and got a sensible result, you are
>> probably wrong in this assumption.
>
> It works fine from a Python command line, but I can't be sure the
> environment in which Apache is running is exactly the same.
>
> When I remove socket.gethostname() from the above line it works, so I'm
> quite it is the culprit.

If you were running Linux I would think you were confusing issues here. 
Yes, the error may be being provoked by the execution of the 
gethostname() function but it is highly unlikely that it is the basic 
cause of the the error. Most likely, the function call is just 
triggering a latent defect in the system environment in which it is 
executing. But you are working with a different port of Python and 
presumably the implementation of modules such as socket are 
significantly different from the Linux/UNIX implementation. This may or 
may not be the source of your problem. But I am convinced this is not a 
MM problem.

>
> What I need is to discover the values which are being retrieved by
> LockFile.py. Not being a Python expert stops me from outputting the
> variables to a file or to the screen....
>
>

I'm not clear what you mean by 'retrieved'.

Instances of the LockFile class are created in a number of places in 
Mailman source code:

bash-2.05a$ find . -name "*.py" | xargs grep 'LockFile('
./Mailman/Archiver/HyperArch.py:        self._lock_file = 
LockFile.LockFile(
./Mailman/Archiver/HyperDatabase.py:        self.lockfile = 
LockFile.LockFile(self.path + ".lock")
./Mailman/Handlers/Scrubber.py:    lock = LockFile.LockFile(lockfile)
./Mailman/LockFile.py:    lockfile = LockFile('/tmp/LockTest', 
withlogging=True, lifetime=120)
./Mailman/MailList.py:        self.__lock = LockFile.LockFile(
./Mailman/MTA/Postfix.py:    return LockFile.LockFile(LOCKFILE)
./Mailman/Pending.py:    lock = LockFile.LockFile(LOCKFILE,
./Mailman/Pending.py:    lock = LockFile.LockFile(LOCKFILE,
./Mailman/Pending.py:    lock = LockFile.LockFile(LOCKFILE,

In each case a file path is passed in as a parameter and a temporary 
file name is created by the statement in the LockFile class initialiser 
__init__() function with the statement:

         self.__tmpfname = '%s.%s.%d.%d' % (
             lockfile, socket.gethostname(), os.getpid(), self.__counter)

The use of the hostname (as provided by gethostname()), pid and a 
monotonically increasing counter is to ensure each temporary file name 
is unique. I suspect that if your Mailman port is not going to operate 
in a file sharing (between different hosts) environment that the 
inclusion of the hostname in the temporary file name is not strictly 
necessary. This would let you change the way the temporary file name is 
formed by pretending the latent defect in the underlying Python/system 
does not exist. You could probably change the code to read as follows 
without getting an immediate problem:

         self.__tmpfname = '%s.%d.%d' % (
             lockfile, os.getpid(), self.__counter)

There is a function of the LockFile class, __writelog() which you could 
use to write information to a log file. If you can be clearer about 
what you are trying to achieve I can suggest what code changes you can 
make to get the information you want logged.

-----------------------------------------------------------------------
Richard Barrett                               http://www.openinfo.co.uk