[NTG-context] calling ConTeXt as a background process

Florian Wobbe Florian.Wobbe at awi.de
Fri Oct 8 17:08:38 CEST 2010


On Oct 8, 2010, at 16:30 , Henning Hraban Ramm wrote:

> Am 2010-10-08 um 15:54 schrieb Taco Hoekwater:
> 
>> On 10/08/2010 03:47 PM, Henning Hraban Ramm wrote:
>>> 
>>> 16002 15978 TS 21 15:41 ? 00:00:01 \_ /var/www/xxx/bin/python
>>> /var/www/.../manage.py run_gunicorn -c /var/www/.../gunicorn-settings.py
>>> 16210 16002 TS 14 15:42 ? 00:00:08 \_ luatex --interaction=batchmode
>>> --fmt=/var/opt/context/tex/texmf-cache/.../formats/cont-en
>>> --lua=/var/opt/context/tex/texmf-cache/...
>>> 16212 16210 TS 17 15:42 ? 00:00:00 \_ [uname] <defunct>
>> 
>> Hm, defunct, eh?
>> 
>> The luatex binary itself definitely does not call uname as a
>> process, therefore this has to be the os.resultof() function
>> that Hans implements in l-os.lua. I am suspecting issues with
>> redirection now, as that function is defined as:
>> 
>> function os.resultof(command)
>>   local handle = io.popen(command,"r")
>>   return handle and handle:read("*all") or ""
>> end

The strange thing is that running

 luatex --interaction=batchmode --fmt=".../formats/cont-en" --lua=".../formats/cont-en.lui" --backend=pdf hello

causes luatex (or say l-os.lua) to call 'uname -m' via os.resultof

However, when doing

 mtxrun --script context --batchmode --once hello

*only* texlua calls 'uname -m' and the following luatex child does *not* anymore. Why?

>> of course this will fail/block rather horribly if uname -m
>> does not write to STDOUT (and that is not just uname, thre
>> are a few more uses of os.resultof()).

if that is the case you should not see any reads after the child forks:

clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7feb7a0369d0) = 14998
[...]
read(3, "x86_64\n", 4096) = 7
read(3, "", 4096) = 0
--- SIGCHLD (Child exited) @ 0 (0) ---

> My script now calls first os.uname and then the external one.
> From the shell it works like expected.
> And even from the server process! That alone doesn't seem to be the problem.
> 
> Here's the trace:
> 
> strace -ff texlua call_uname.lua
> 
> [...]

I'm running out of ideas. From your script os.resultof("uname -m") works and from luatex it doesn't. What does this trace distinguish from the one of luatex?

Florian



More information about the ntg-context mailing list