On 26-10-2010 10:56, Taco Hoekwater wrote:
On 10/26/10 22:09, Hans Hagen wrote:
On 26-10-2010 9:28, Taco Hoekwater wrote:
Hi Henning,
On 10/08/10 21:44, Henning Hraban Ramm wrote:
Ok, the failures were the same with fcgi and gunicorn app servers.
But it _works_ with django's dev server (w
On 10/26/10 22:09, Hans Hagen wrote:
> On 26-10-2010 9:28, Taco Hoekwater wrote:
>>
>> Hi Henning,
>>
>> On 10/08/10 21:44, Henning Hraban Ramm wrote:
>>> Ok, the failures were the same with fcgi and gunicorn app servers.
>>>
>>> But it _works_ with django's dev server (which you must not use in
Am 2010-10-26 um 21:28 schrieb Taco Hoekwater:
We just had a somewhat similar problem (texlua hung at 100% cpu
when run via apache) and it turns out, after lots of debugging,
that mtxrun cannot do anything without $HOME. Perhaps yours was
a different symptom of the same problem ?
Ah, I didn't
On 26-10-2010 9:28, Taco Hoekwater wrote:
Hi Henning,
On 10/08/10 21:44, Henning Hraban Ramm wrote:
Ok, the failures were the same with fcgi and gunicorn app servers.
But it _works_ with django's dev server (which you must not use in
production due to memory/security holes etc.).
We just ha
Hi Henning,
On 10/08/10 21:44, Henning Hraban Ramm wrote:
> Ok, the failures were the same with fcgi and gunicorn app servers.
>
> But it _works_ with django's dev server (which you must not use in
> production due to memory/security holes etc.).
We just had a somewhat similar problem (texlua h
Am 2010-10-10 um 10:47 schrieb Patrick Gundlach:
Thank you all for your patience, ideas and help!
Sorry, that I didn't quite understand the problem/solution, could
you describe in a few sentences what problem was and how you solved
it?
I actually couldn't find out what the real problem
>
> Thank you all for your patience, ideas and help!
Sorry, that I didn't quite understand the problem/solution, could you describe
in a few sentences what problem was and how you solved it?
Thanks
Patrick
___
If
Ok, the failures were the same with fcgi and gunicorn app servers.
But it _works_ with django's dev server (which you must not use in
production due to memory/security holes etc.).
While ConTeXt runs it looks like:
5852 25767 TS 21 18:04 pts/000:00:00 \_ python manage.py
runserv
On 8-10-2010 4:57, Taco Hoekwater wrote:
Hi,
On 10/08/2010 04:30 PM, Henning Hraban Ramm wrote:
I just don't understand why any lua script would call uname externally
if it's available as os.uname?
My guess is that this is historical. Hans?
yes, and also related to some issues on osx wher
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-se
Just installed Ruby, fetched the latest beta and tried texexec:
26382 26367 TS 20 16:38 ?00:00:01 \_ /var/www/xxx/bin/
python /var/www/xxx/manage.py run_gunicorn -c /var/www/.../gunicorn-
settings.py
26509 26382 TS 20 16:38 ?00:00:00 \_ /bin/sh -c texexec
--batchmode
Hi,
On 10/08/2010 04:30 PM, Henning Hraban Ramm wrote:
I just don't understand why any lua script would call uname externally
if it's available as os.uname?
My guess is that this is historical. Hans?
Best wishes,
Taco
Sorry, no smart ideas about the rest of the problems any more
__
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
>
> function os.resultof(command)
>local handle = io.popen(command,"r")
>return handle and handle:read("*all") or ""
> end
>
shouldn't the handle be close()d?
Patrick
___
If your question is of interest t
On Fri, Oct 8, 2010 at 3:47 PM, Henning Hraban Ramm wrote:
> Am 2010-10-08 um 13:46 schrieb Florian Wobbe:
>>
>> Right, so you are not even getting to the point where luatex is called.
>> This is still texlua executing instructions from mtxrun.
>
>>> strace -p 14256
>>> attach: ptrace(PTRACE_ATTAC
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/..
Am 2010-10-08 um 13:46 schrieb Florian Wobbe:
Right, so you are not even getting to the point where luatex is
called. This is still texlua executing instructions from mtxrun.
strace -p 14256
attach: ptrace(PTRACE_ATTACH, ...): Operation not permitted
(as the same user as well as as root)
So
On Oct 8, 2010, at 12:00 , Henning Hraban Ramm wrote:
> Am 2010-10-08 um 11:25 schrieb Florian Wobbe:
>
>> This output looks quite messy because it is composed of the mixed output for
>> five processes. I don't suspect the fault in luatex executable itself,
>> however, mtxrun calls uname -m in
On 8-10-2010 10:00, Henning Hraban Ramm wrote:
Sorry for the OT thread, I suspected the problem being more in the
LuaTeX area.
I never had problems running luatex (texlua) on linux boxes as part of a
web service so I cannot image luatex being the problem. Can you see what
pdftex does?
Hans
Am 2010-10-08 um 11:25 schrieb Florian Wobbe:
This output looks quite messy because it is composed of the mixed
output for five processes. I don't suspect the fault in luatex
executable itself, however, mtxrun calls uname -m in a subshell and
my guess is that it hangs there. Have you tried
On Fri, Oct 8, 2010 at 11:21 AM, Henning Hraban Ramm wrote:
> Am 2010-10-08 um 10:12 schrieb Patrick Gundlach:
>
>> I don't think it's in the LuaTeX area, for LuaTeX is just a regular
>> process.
>
> Hm, I suspect it might be some system call inside LuaTeX that is blocked or
> the like.
>
>> I hav
> Am 2010-10-08 um 09:59 schrieb Florian Wobbe:
>
>>> Thank you, but the problem is most probably something in my server setup
>>> that doesn't fit something in LuaTeX.
>>> As I mentioned: I got no problems calling TeX directly, just from the
>>> server process.
>>
>> All right. I have one more
Am 2010-10-08 um 10:12 schrieb Patrick Gundlach:
I don't think it's in the LuaTeX area, for LuaTeX is just a regular
process.
Hm, I suspect it might be some system call inside LuaTeX that is
blocked or the like.
I have to admit that I have run into similar problems with different
softwa
On Fri, Oct 8, 2010 at 10:47 AM, Henning Hraban Ramm wrote:
> Am 2010-10-08 um 10:37 schrieb luigi scarso:
>>
>> An user permissions/environment issue ?
>
>
> I can't exclude that, but since the web server and its subprocesses run as
> the same user that I (can) use for login and got no problems r
Am 2010-10-08 um 10:37 schrieb luigi scarso:
An user permissions/environment issue ?
I can't exclude that, but since the web server and its subprocesses
run as the same user that I (can) use for login and got no problems
running TeX as that user, I wouldn't know where to look for the wrong
Am 2010-10-08 um 09:59 schrieb Florian Wobbe:
Thank you, but the problem is most probably something in my server
setup that doesn't fit something in LuaTeX.
As I mentioned: I got no problems calling TeX directly, just from
the server process.
All right. I have one more suggestion. If you d
On Fri, Oct 8, 2010 at 10:00 AM, Henning Hraban Ramm wrote:
> Summary so far:
>
> * Machine: virtual server on Debian 5.0 (x86_64) (I thought it was Ubuntu,
> because I run that on my other Linux machines, sorry).
> * Webserver: Django 1.2/fcgi (Python 2.5) behind Nginx
>
> I can run ConTeXt witho
> Sorry for the OT thread, I suspected the problem being more in the LuaTeX
> area.
I don't think it's in the LuaTeX area, for LuaTeX is just a regular process.
I have to admit that I have run into similar problems with different software I
tried to run from a "server process" (whatever this
Summary so far:
* Machine: virtual server on Debian 5.0 (x86_64) (I thought it was
Ubuntu, because I run that on my other Linux machines, sorry).
* Webserver: Django 1.2/fcgi (Python 2.5) behind Nginx
I can run ConTeXt without any problems from the shell, also as the
same user that runs the
On Oct 8, 2010, at 09:36 , Henning Hraban Ramm wrote:
>> I've got Ubunto and OSX here and could try to reproduce the error for you,
>> if you post your script.
>
> Thank you, but the problem is most probably something in my server setup that
> doesn't fit something in LuaTeX.
> As I mentioned:
Am 2010-10-07 um 18:32 schrieb Florian Wobbe:
Well, remote sensing with computers is cumbersome and as I haven't
got a clue what happens on your machine I'd rather see your the
shell script.
Don't keep fixed on that shell script - it was only one of many failed
attempts. "context" itself i
Henning Hraban Ramm wrote:
I can imagine that it has something to do with SElinux settings, didn't
dive in that yet.
That does sound familiar, in fact. I had a hanging database server
a while back because I moved it to a different location. apparmor
was the culprit in that case, so perhaps it
> Am 2010-10-07 um 12:54 schrieb Florian Wobbe:
>
>> On Oct 7, 2010, at 12:19 , Henning Hraban Ramm wrote:
>>
>>> Am 2010-10-07 um 11:06 schrieb Taco Hoekwater:
> Of course, prd_paket.tex is my input file. But that's there.
Your shell quotes were off. It is looking for
"
Am 2010-10-07 um 17:48 schrieb luigi scarso:
How's ConTeXt called in ConTeXtgarden Live? Any special means?
http://github.com/pgundlach/contextlive/blob/master/runtexexec.c
I use fork()/exec() combination in C.
Ok, I won't use C...
I saw you set TEXMFHOME - I don't need that for MkIV, do I?
Am 2010-10-07 um 12:54 schrieb Florian Wobbe:
On Oct 7, 2010, at 12:19 , Henning Hraban Ramm wrote:
Am 2010-10-07 um 11:06 schrieb Taco Hoekwater:
Of course, prd_paket.tex is my input file. But that's there.
Your shell quotes were off. It is looking for
"./prd_paket --batchmode --once.tex
On Thu, Oct 7, 2010 at 5:44 PM, Henning Hraban Ramm wrote:
> Am 2010-10-07 um 12:27 schrieb Patrick Gundlach:
>
>>> How's ConTeXt called in ConTeXtgarden Live? Any special means?
>>
>> http://github.com/pgundlach/contextlive/blob/master/runtexexec.c
>>
>> I use fork()/exec() combination in C.
>
>
Am 2010-10-07 um 12:27 schrieb Patrick Gundlach:
How's ConTeXt called in ConTeXtgarden Live? Any special means?
http://github.com/pgundlach/contextlive/blob/master/runtexexec.c
I use fork()/exec() combination in C.
Ok, I won't use C...
I guess it's a problem of my specific combination of U
Am 2010-10-07 um 12:16 schrieb :
Have you tried attaching to the stalled processes using strace (Linux)
or dtruss (Mac)? This will tell you what system call is blocking,
might
give a clue. The defunct uname process in your original post suggests
to me the parent did not calling wait() on the
Hi Hraban,
>
> How's ConTeXt called in ConTeXtgarden Live? Any special means?
Please CC me for these kind of questions, for I don't follow the list every day.
I've put context live into a repo at github:
http://github.com/pgundlach/contextlive
and take a look at
http://github.com/pgundlach/
Am 2010-10-07 um 11:06 schrieb Taco Hoekwater:
Of course, prd_paket.tex is my input file. But that's there.
Your shell quotes were off. It is looking for
"./prd_paket --batchmode --once.tex"
Ok, but it doesn't work with any other call of luatex - I also tried
to start another shell script
Posted by Henning Hraban Ramm [hra...@fiee.net]
> Am 2010-10-07 um 10:42 schrieb Taco Hoekwater:
>
> > On 10/07/10 09:34, Henning Hraban Ramm wrote:
> >> mtxrun --script context "prd_paket --batchmode --once"
> >
> > When I run that last thing on the command line, I get:
> >
> > ! I can't find f
On 10/07/10 11:00, Henning Hraban Ramm wrote:
> Am 2010-10-07 um 10:42 schrieb Taco Hoekwater:
>
>> On 10/07/10 09:34, Henning Hraban Ramm wrote:
>>> mtxrun --script context "prd_paket --batchmode --once"
>>
>> When I run that last thing on the command line, I get:
>>
>> ! I can't find file `./
Am 2010-10-07 um 10:42 schrieb Taco Hoekwater:
On 10/07/10 09:34, Henning Hraban Ramm wrote:
mtxrun --script context "prd_paket --batchmode --once"
When I run that last thing on the command line, I get:
! I can't find file `./prd_paket --batchmode --once'.
<*> "./prd_paket --batchmode --on
On 10/07/10 09:34, Henning Hraban Ramm wrote:
> mtxrun --script context "prd_paket --batchmode --once"
When I run that last thing on the command line, I get:
! I can't find file `./prd_paket --batchmode --once'.
<*> "./prd_paket --batchmode --once"
Please type another input file name:
B
Am 2010-10-07 um 09:06 schrieb Henning Hraban Ramm:
Hi together!
I'm trying since about a week to get ConTeXt running as a background
process of a web application.
It's always hanging, and I get no log.
"ps axef" shows the call stack:
\_ /var/www/xxx/bin/python /var/www/xxx/releases/curre
Hi together!
I'm trying since about a week to get ConTeXt running as a background
process of a web application.
It's always hanging, and I get no log.
"ps axef" shows the call stack:
\_ /var/www/xxx/bin/python /var/www/xxx/releases/current/cerebrale/
manage.py runfcgi method=threaded ...
46 matches
Mail list logo