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 ... \_ /bin/sh -c cd /var/www/xxx/_textemp && /var/opt/context/tex/ texmf-linux-64/bin/context ... \_ /bin/sh /var/opt/context/tex/texmf-linux-64/bin/context -- purgeall --batchmode --result=/var/www/xxx/_textemp/xxx.pdf \_ texlua /var/opt/context/tex/texmf-linux-64/bin/mtxrun --script context --purgeall --batchmode --result=/ ... \_ [uname] <defunct> I.e. it looks like texlua calls uname in a way that lets the process hang forever. If I call the same from an active shell everything runs fine. Also uname alone works in the shell command. Any ideas what I could/should check? I don't think it could be the PATH, since ConTeXt's bin as well as all the system tools are in: PATH=/var/opt/context/tex/texmf-linux-64/bin:/var/www/cerebrale/bin:/ command:/usr/local/bin:/usr/local/sbin:/bin:/sbin:/usr/bin:/usr/sbin:/ usr/X11R6/bin TEXMFOS=/var/opt/context/tex/texmf-linux-64 TEXROOT=/var/opt/context/tex The user that runs the server process (incl. sub-shell and ConTeXt) owns all the TeX files and the directory. Maybe it's a Python problem, here's my call: subprocess.Popen(cmd.encode('utf-8'), shell=True, stderr=logfile, stdout=logfile) But I can call several other commands in this way without problems. The whole thing (incl. ConTeXt) works on my Mac (OSX 10.5.8) at home. Everything I call before ConTeXt shows up in the logfile. Greetlings from Lake Constance! Hraban --- http://www.fiee.net/texnique/ http://wiki.contextgarden.net https://www.cacert.org (I'm an assurer)
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/current/cerebrale/ manage.py runfcgi method=threaded ... \_ /bin/sh -c cd /var/www/xxx/_textemp && /var/opt/context/tex/ texmf-linux-64/bin/context ... \_ /bin/sh /var/opt/context/tex/texmf-linux-64/bin/context -- purgeall --batchmode --result=/var/www/xxx/_textemp/xxx.pdf \_ texlua /var/opt/context/tex/texmf-linux-64/bin/mtxrun --script context --purgeall --batchmode --result=/ ... \_ [uname] <defunct>
I.e. it looks like texlua calls uname in a way that lets the process hang forever. If I call the same from an active shell everything runs fine. Also uname alone works in the shell command. Any ideas what I could/should check?
I don't think it could be the PATH, since ConTeXt's bin as well as all the system tools are in: PATH=/var/opt/context/tex/texmf-linux-64/bin:/var/www/cerebrale/bin:/ command:/usr/local/bin:/usr/local/sbin:/bin:/sbin:/usr/bin:/usr/ sbin:/usr/X11R6/bin TEXMFOS=/var/opt/context/tex/texmf-linux-64 TEXROOT=/var/opt/context/tex
The user that runs the server process (incl. sub-shell and ConTeXt) owns all the TeX files and the directory.
Maybe it's a Python problem, here's my call: subprocess.Popen(cmd.encode('utf-8'), shell=True, stderr=logfile, stdout=logfile)
But I can call several other commands in this way without problems. The whole thing (incl. ConTeXt) works on my Mac (OSX 10.5.8) at home. Everything I call before ConTeXt shows up in the logfile.
I tried to call mtxrun directly and replaced the calls to uname -m with their return value (x86_64). Now the texlua process itself hangs, even if not "defunct" it doesn't do anything: \_ /var/www/xxx/bin/python /var/www/xxx/releases/current/cerebrale/ manage.py runfcgi method=threaded ... \_ /bin/sh -c cd /var/www/xxx/_textemp && mtxrun --script context "prd_paket --batchmode --once" PATH=/var/opt/context/tex/texmf- linux-64/bin:/var/www/xxx/bin:... \_ texlua /var/opt/context/tex/texmf-linux-64/bin/mtxrun -- script context prd_paket --batchmode --once TEXMFOS=/var/opt/context/ tex/texmf-linux-64 VIRTUAL_ENV=/var/www/xxx PATH=/var/opt/context/tex/ texmf-linux-64/bin:... Help? Greetlings from Lake Constance! Hraban --- http://www.fiee.net/texnique/ http://wiki.contextgarden.net https://www.cacert.org (I'm an assurer)
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: But it is hard to say whether that is the problem. If it was me, I would attach a gdb to the process to see where it is at from the backtrace (but you need a non-stripped build of the binary for that). Best wishes, Taco
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 --once"
Please type another input file name:
Of course, prd_paket.tex is my input file. But that's there.
But it is hard to say whether that is the problem. If it was me, I would attach a gdb to the process to see where it is at from the backtrace (but you need a non-stripped build of the binary for that).
I'd like to avoid compiling a debugging version of luatex... I guess the problem isn't luatex itself, but the probably somehow restricted environment. How's ConTeXt called in ConTeXtgarden Live? Any special means? Greetlings from Lake Constance! Hraban --- http://www.fiee.net/texnique/ http://wiki.contextgarden.net https://www.cacert.org (I'm an assurer)
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 `./prd_paket --batchmode --once'. <*> "./prd_paket --batchmode --once"
Please type another input file name:
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"
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 that calls luatex, but it hangs in the same manner. If I kill the luatex process, further commands work. I found a lot of examples where people call other programs from Django in the same way as I tried with LuaTeX (i.e. without additional shell script), so my call isn't probably too wrong. Greetlings from Lake Constance! Hraban --- http://www.fiee.net/texnique/ http://wiki.contextgarden.net https://www.cacert.org (I'm an assurer)
Posted by Henning Hraban Ramm [hraban@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 file `./prd_paket --batchmode --once'. <*> "./prd_paket --batchmode --once"
Please type another input file name:
Of course, prd_paket.tex is my input file. But that's there.
But it is hard to say whether that is the problem. If it was me, I would attach a gdb to the process to see where it is at from the backtrace (but you need a non-stripped build of the binary for that).
I'd like to avoid compiling a debugging version of luatex...
Hraban, 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 child (uname) and it exited. Best, Robin
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 child (uname) and it exited.
Here's the output of strace after I killed the stalled process: execve("/var/opt/context/tex/texmf-linux-64/bin/context", ["/var/opt/ context/tex/texmf-linux"..., "--batchmode", "--once", "prd_streifband- d"], [/* 10 vars */]) = 0 brk(0) = 0x1e4bd000 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2ababa192000 uname({sys="Linux", node="aine.fiee.net", ...}) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2ababa193000 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) open("/etc/ld.so.cache", O_RDONLY) = 3 fstat(3, {st_mode=S_IFREG|0644, st_size=20573, ...}) = 0 mmap(NULL, 20573, PROT_READ, MAP_PRIVATE, 3, 0) = 0x2ababa195000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/lib/libncurses.so.5", O_RDONLY) = 3 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\320% \1\0\0\0\0\0@"..., 832) = 832 fstat(3, {st_mode=S_IFREG|0644, st_size=256288, ...}) = 0 mmap(NULL, 2353152, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x2ababa393000 mprotect(0x2ababa3ce000, 2093056, PROT_NONE) = 0 mmap(0x2ababa5cd000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE| MAP_FIXED|MAP_DENYWRITE, 3, 0x3a000) = 0x2ababa5cd000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/lib/libdl.so.2", O_RDONLY) = 3 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0> \0\1\0\0\0\20\16\0\0\0\0\0\0@"..., 832) = 832 fstat(3, {st_mode=S_IFREG|0644, st_size=14616, ...}) = 0 mmap(NULL, 2109728, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x2ababa5d2000 mprotect(0x2ababa5d4000, 2097152, PROT_NONE) = 0 mmap(0x2ababa7d4000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED| MAP_DENYWRITE, 3, 0x2000) = 0x2ababa7d4000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/lib/libc.so.6", O_RDONLY) = 3 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0> \0\1\0\0\0\300\342\1\0\0\0\0\0@"..., 832) = 832 fstat(3, {st_mode=S_IFREG|0755, st_size=1375536, ...}) = 0 mmap(NULL, 3482232, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x2ababa7d6000 mprotect(0x2ababa920000, 2093056, PROT_NONE) = 0 mmap(0x2ababab1f000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE| MAP_FIXED|MAP_DENYWRITE, 3, 0x149000) = 0x2ababab1f000 mmap(0x2ababab24000, 17016, PROT_READ|PROT_WRITE, MAP_PRIVATE| MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x2ababab24000 close(3) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2ababab29000 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2ababab2a000 arch_prctl(ARCH_SET_FS, 0x2ababab29af0) = 0 mprotect(0x2ababab1f000, 12288, PROT_READ) = 0 munmap(0x2ababa195000, 20573) = 0 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0 open("/dev/tty", O_RDWR|O_NONBLOCK) = -1 ENXIO (No such device or address) ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fff561b3e10) = -1 EINVAL (Invalid argument) brk(0) = 0x1e4bd000 brk(0x1e4be000) = 0x1e4be000 brk(0x1e4bf000) = 0x1e4bf000 getuid() = 1005 getgid() = 1006 geteuid() = 1005 getegid() = 1006 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0 brk(0x1e4c0000) = 0x1e4c0000 open("/proc/meminfo", O_RDONLY) = 3 fstat(3, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2ababa195000 read(3, "MemTotal: 2097152 kB\nMemFree"..., 4096) = 771 close(3) = 0 munmap(0x2ababa195000, 4096) = 0 brk(0x1e4c1000) = 0x1e4c1000 rt_sigaction(SIGCHLD, {SIG_DFL}, {SIG_DFL}, 8) = 0 rt_sigaction(SIGCHLD, {SIG_DFL}, {SIG_DFL}, 8) = 0 rt_sigaction(SIGINT, {SIG_DFL}, {SIG_DFL}, 8) = 0 rt_sigaction(SIGINT, {SIG_DFL}, {SIG_DFL}, 8) = 0 rt_sigaction(SIGQUIT, {SIG_DFL}, {SIG_DFL}, 8) = 0 rt_sigaction(SIGQUIT, {SIG_DFL}, {SIG_DFL}, 8) = 0 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0 rt_sigaction(SIGQUIT, {SIG_IGN}, {SIG_DFL}, 8) = 0 uname({sys="Linux", node="aine.fiee.net", ...}) = 0 stat("/var/www/xxx/_textemp", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 stat(".", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 getpid() = 26040 getppid() = 26038 brk(0x1e4c2000) = 0x1e4c2000 socket(PF_FILE, SOCK_STREAM, 0) = 3 fcntl(3, F_SETFL, O_RDWR|O_NONBLOCK) = 0 connect(3, {sa_family=AF_FILE, path="/var/run/nscd/socket"...}, 110) = 0 sendto(3, "\2\0\0\0\v\0\0\0\7\0\0\0passwd\0"..., 19, MSG_NOSIGNAL, NULL, 0) = 19 poll([{fd=3, events=POLLIN|POLLERR|POLLHUP}], 1, 5000) = 1 ([{fd=3, revents=POLLIN|POLLHUP}]) recvmsg(3, {msg_name(0)=NULL, msg_iov(2)=[{"passwd\0"..., 7}, {"\270O \3\0\0\0\0\0"..., 8}], msg_controllen=24, {cmsg_len=20, cmsg_level=SOL_SOCKET, cmsg_type=SCM_RIGHTS, {4}}, msg_flags=0}, MSG_CMSG_CLOEXEC) = 15 mmap(NULL, 217016, PROT_READ, MAP_SHARED, 4, 0) = 0x2ababa195000 close(4) = 0 close(3) = 0 brk(0x1e4c3000) = 0x1e4c3000 getpgrp() = 29995 rt_sigaction(SIGCHLD, {0x439730, [], SA_RESTORER, 0x2ababa807f60}, {SIG_DFL}, 8) = 0 getrlimit(RLIMIT_NPROC, {rlim_cur=582*1024, rlim_max=582*1024}) = 0 brk(0x1e4c4000) = 0x1e4c4000 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0 open("/var/opt/context/tex/texmf-linux-64/bin/context", O_RDONLY) = 3 ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fff561b3e80) = -1 ENOTTY (Inappropriate ioctl for device) lseek(3, 0, SEEK_CUR) = 0 read(3, "#!/bin/sh\nmtxrun --script context"..., 80) = 39 lseek(3, 0, SEEK_SET) = 0 getrlimit(RLIMIT_NOFILE, {rlim_cur=1024, rlim_max=1024}) = 0 dup2(3, 255) = 255 close(3) = 0 fcntl(255, F_SETFD, FD_CLOEXEC) = 0 fcntl(255, F_GETFL) = 0x8000 (flags O_RDONLY| O_LARGEFILE) fstat(255, {st_mode=S_IFREG|0755, st_size=39, ...}) = 0 lseek(255, 0, SEEK_CUR) = 0 brk(0x1e4c5000) = 0x1e4c5000 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0 read(255, "#!/bin/sh\nmtxrun --script context"..., 39) = 39 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0 brk(0x1e4c6000) = 0x1e4c6000 stat(".", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 stat("/var/opt/context/tex/texmf-linux-64/bin/mtxrun", {st_mode=S_IFREG|0755, st_size=428842, ...}) = 0 open("/proc/sys/kernel/ngroups_max", O_RDONLY) = 3 read(3, "65536\n"..., 31) = 6 close(3) = 0 brk(0x1e546000) = 0x1e546000 getgroups(65536, [1006]) = 1 stat("/var/opt/context/tex/texmf-linux-64/bin/mtxrun", {st_mode=S_IFREG|0755, st_size=428842, ...}) = 0 brk(0x1e547000) = 0x1e547000 rt_sigprocmask(SIG_BLOCK, [INT CHLD], [], 8) = 0 clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID| SIGCHLD, child_tidptr=0x2ababab29b80) = 26041 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0 rt_sigaction(SIGINT, {0x43a340, [], SA_RESTORER, 0x2ababa807f60}, {SIG_DFL}, 8) = 0 wait4(-1, [{WIFSIGNALED(s) && WTERMSIG(s) == SIGTERM}], 0, NULL) = 26041 write(2, "/var/opt/context/tex/texmf-linux-"..., 116/var/opt/context/ tex/texmf-linux-64/bin/context: line 2: 26041 Terminated mtxrun --script context "$@" ) = 116 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 --- SIGCHLD (Child exited) @ 0 (0) --- wait4(-1, 0x7fff561b3b74, WNOHANG, NULL) = -1 ECHILD (No child processes) rt_sigreturn(0x8) = 0 rt_sigaction(SIGINT, {SIG_DFL}, {0x43a340, [], SA_RESTORER, 0x2ababa807f60}, 8) = 0 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0 read(255, ""..., 39) = 0 exit_group(143) = ? Can you tell what's going on? Greetlings from Lake Constance! Hraban --- http://www.fiee.net/texnique/ http://wiki.contextgarden.net https://www.cacert.org (I'm an assurer)
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/contextlive/blob/master/runtexexec.c I use fork()/exec() combination in C. Patrick
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 Ubuntu/SElinux, Django/fcgi and LuaTeX... :-( I found others running latex from Django in exactly the same matter as ConTeXt fails for me. But I can call other programs that way, so part of the problem is in LuaTeX. Greetlings, Hraban
On Thu, Oct 7, 2010 at 5:44 PM, Henning Hraban Rammwrote: > 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 Ubuntu/SElinux, > Django/fcgi and LuaTeX... :-( > I found others running latex from Django in exactly the same matter as > ConTeXt fails for me. > But I can call other programs that way, so part of the problem is in LuaTeX. 1) Are you sure to have done source setuptex before run luatex 2) does os.system(...) in python only work ? -- luigi
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?
1) Are you sure to have done source setuptex before run luatex
tried that and tried to set TEXROOT and TEXMFOS "manually" (and the output of "set" looks right).
2) does os.system(...) in python only work ?
Thank you, I didn't think of the easiest option! With strace I get a return code of 0, so the command seems to run through, nothing hangs, but also nothing happens. Without strace texlua hangs, and after killing it I get a 36608 (don't know what that is, it's not the PID). Greetlings from Lake Constance! Hraban --- http://www.fiee.net/texnique/ http://wiki.contextgarden.net https://www.cacert.org (I'm an assurer)
participants (5)
-
Henning Hraban Ramm
-
luigi scarso
-
Patrick Gundlach
-
Robin.Kirkham@csiro.au
-
Taco Hoekwater