Screenshot instructions:
Windows
Mac
Red Hat Linux
Ubuntu
Click URL instructions:
Right-click on ad, choose "Copy Link", then paste here →
(This may not be possible with some types of ads)
|
From: Riccardo Murri <riccardo.murri@gm...> - 2011-12-13 19:44:37
|
Hi Matthias, On Tue, Dec 13, 2011 at 20:21, Matthias Rieber <supportrq@...> wrote: > Am 13.12.2011 16:13, schrieb richard -rw- weinberger: >> I'll try that. What should I grep for in the strace log? >> >> For anything which can cause your problem. >> E.g. Failing system calls which should not fail... >> >> We've had problems with java and glibc where glibc used x86 specific >> futex operations which are not supported on UML... >> > I traced a larger part and it seems that erlang causes many futex calls > on the hostsystem and none on the uml kernel. > I think you should run the strace *in* the UML, not on the host. Best regards, Riccardo |
|
From: Matthias Rieber <supportrq@su...> - 2011-12-13 12:42:18
|
Hi, I've a strange problem with ejabberd(a jabber server written in Erlang) running under the user mode linux kernel. Almost everything works as expected but a certain function, pubsub/pep, doesn't work. When I run the very same installation in a chroot environment on the host, it behaves correctly. The UML Kernel is a vanilla 2.6.32.49. I've tried different systems 32bit/64bit, they show the same behaviour. Due to the lack of any Erlang knowledge I can't check why the jabber server doesn't work. Are there know issues with Erlang? Any ideas to debug it without digging in the server? Regards, Matthias |
|
From: richard -rw- weinberger <richard.weinberger@gm...> - 2011-12-13 12:54:48
|
On Tue, Dec 13, 2011 at 1:10 PM, Matthias Rieber <supportrq@...> wrote: > Hi, > > I've a strange problem with ejabberd(a jabber server written in Erlang) > running under the user mode linux kernel. Almost everything works as > expected but a certain function, pubsub/pep, doesn't work. When I run > the very same installation in a chroot environment on the host, it > behaves correctly. The UML Kernel is a vanilla 2.6.32.49. I've tried > different systems 32bit/64bit, they show the same behaviour. Please define "doesn't work". > Due to the lack of any Erlang knowledge I can't check why the jabber > server doesn't work. Are there know issues with Erlang? Any ideas to > debug it without digging in the server? Maybe Erlang makes use of a system call which is not available on UML... You can try strace... -- Thanks, //richard |
|
From: Matthias Rieber <supportrq@su...> - 2011-12-13 13:56:03
|
Hello, On 13.12.2011 13:54, richard -rw- weinberger wrote: > On Tue, Dec 13, 2011 at 1:10 PM, Matthias Rieber <supportrq@...> wrote: >> Hi, >> >> I've a strange problem with ejabberd(a jabber server written in Erlang) >> running under the user mode linux kernel. Almost everything works as >> expected but a certain function, pubsub/pep, doesn't work. When I run >> the very same installation in a chroot environment on the host, it >> behaves correctly. The UML Kernel is a vanilla 2.6.32.49. I've tried >> different systems 32bit/64bit, they show the same behaviour. > > Please define "doesn't work". hard to describe. The jabber server receives a xml stanza, it returns a confirmation, that it has been processed correctly. The stanza should lead to an information storage in the mnesia database, which didn't happen, when I run ejabberd in UML. >> Due to the lack of any Erlang knowledge I can't check why the jabber >> server doesn't work. Are there know issues with Erlang? Any ideas to >> debug it without digging in the server? > > Maybe Erlang makes use of a system call which is not available on UML... > You can try strace... I'll try that. What should I grep for in the strace log? Matthias |
|
From: richard -rw- weinberger <richard.weinberger@gm...> - 2011-12-13 15:13:38
|
On Tue, Dec 13, 2011 at 2:55 PM, Matthias Rieber <supportrq@...> wrote: > Hello, > > On 13.12.2011 13:54, richard -rw- weinberger wrote: >> On Tue, Dec 13, 2011 at 1:10 PM, Matthias Rieber <supportrq@...> wrote: >>> Hi, >>> >>> I've a strange problem with ejabberd(a jabber server written in Erlang) >>> running under the user mode linux kernel. Almost everything works as >>> expected but a certain function, pubsub/pep, doesn't work. When I run >>> the very same installation in a chroot environment on the host, it >>> behaves correctly. The UML Kernel is a vanilla 2.6.32.49. I've tried >>> different systems 32bit/64bit, they show the same behaviour. >> >> Please define "doesn't work". > > hard to describe. The jabber server receives a xml stanza, it returns a > confirmation, that it has been processed correctly. The stanza should > lead to an information storage in the mnesia database, which didn't > happen, when I run ejabberd in UML. > >>> Due to the lack of any Erlang knowledge I can't check why the jabber >>> server doesn't work. Are there know issues with Erlang? Any ideas to >>> debug it without digging in the server? >> >> Maybe Erlang makes use of a system call which is not available on UML... >> You can try strace... > > I'll try that. What should I grep for in the strace log? > For anything which can cause your problem. E.g. Failing system calls which should not fail... We've had problems with java and glibc where glibc used x86 specific futex operations which are not supported on UML... -- Thanks, //richard |
|
From: Matthias Rieber <supportrq@su...> - 2011-12-13 17:23:53
|
Hi,
On 13.12.2011 16:13, richard -rw- weinberger wrote:
> On Tue, Dec 13, 2011 at 2:55 PM, Matthias Rieber <supportrq@...> wrote:
>>> Maybe Erlang makes use of a system call which is not available on UML...
>>> You can try strace...
>>
>> I'll try that. What should I grep for in the strace log?
>>
>
> For anything which can cause your problem.
> E.g. Failing system calls which should not fail...
>
> We've had problems with java and glibc where glibc used x86 specific
> futex operations which are not supported on UML...
running strace (stracer -s 16000 -f -p <erlang process>):
---UML---
{{EPOLLIN, {u32=244, u64=4954239656334983412}}}, 256, 5891) = 1
clock_gettime(CLOCK_MONOTONIC, {452384, 184995846}) = 0
recvfrom(244, "\27\3\1\0
\6\362\333>F\36\273[OL\350{\325\0073\301S^\250\334!3\272<6\t\2505\367>\246\264\27\3\1\0000z\367\217\371\257\323\237\244\237\205&?JR}\224\271\201\355k\341\0163\n\24\6\233\220\t\334\225_q\357\34\246k\375\365\342A\220\307\251\254\2134;",
1460, 0, NULL, NULL) = 90
getpeername(244, {sa_family=AF_INET, sin_port=htons(56873),
sin_addr=inet_addr("<ip>")}, [16]) = 0
clock_gettime(CLOCK_MONOTONIC, {452384, 188543846}) = 0
clock_gettime(CLOCK_MONOTONIC, {452384, 189644846}) = 0
clock_gettime(CLOCK_MONOTONIC, {452384, 190721846}) = 0
clock_gettime(CLOCK_MONOTONIC, {452384, 191717846}) = 0
clock_gettime(CLOCK_MONOTONIC, {452384, 192725846}) = 0
writev(244, [{NULL, 0}, {"\27\3\1\0
f\364^\233\275\316\336@\333\215\20\204\212\353\26\\\311_\5r.J\20\265\305qQ\243a\265\7\336\27\3\1\0000\367c\235=\236\17b\357H\301\36\254B\362~\205\3&\10\261\212y\355\36\324\270\4m\374\245\231\365E>OWC\360\355\334\316\361s\357X\340\3267",
90}], 2) = 90
clock_gettime(CLOCK_MONOTONIC, {452384, 195375846}) = 0
clock_gettime(CLOCK_MONOTONIC, {452384, 196278846}) = 0
epoll_ctl(3, EPOLL_CTL_DEL, 244, {EPOLLIN, {u32=244,
u64=4954239656334983412}}) = 0
epoll_ctl(3, EPOLL_CTL_ADD, 244, {EPOLLIN, {u32=244,
u64=4954239656334983412}}) = 0
epoll_wait(3, {{EPOLLIN, {u32=244, u64=4954239656334983412}}}, 256, 63) = 1
clock_gettime(CLOCK_MONOTONIC, {452384, 204040846}) = 0
recvfrom(244, "\27\3\1\0
9\227\3\240\0009\272\363\233\224\317\244\365\344\207\"~3\t.usg\24ka\254W\313:\301$\27\3\1\0000\242\3316\345\312[j\227\0\32\301w;\34;\210T@\235\202\16\366#\346\3640\261\261\215\223RD\335\373\253'l=\374\266p\201\n\26\31\377!\220",
1460, 0, NULL, NULL) = 90
getpeername(244, {sa_family=AF_INET, sin_port=htons(56873),
sin_addr=inet_addr("<ip>")}, [16]) = 0
clock_gettime(CLOCK_MONOTONIC, {452384, 207843846}) = 0
clock_gettime(CLOCK_MONOTONIC, {452384, 208831846}) = 0
clock_gettime(CLOCK_MONOTONIC, {452384, 209830846}) = 0
clock_gettime(CLOCK_MONOTONIC, {452384, 210909846}) = 0
clock_gettime(CLOCK_MONOTONIC, {452384, 211799846}) = 0
writev(244, [{NULL, 0}, {"\27\3\1\0
\276\214\3162\353\21\367\3567?Hu(`}\36\274\342\345c\351\313\5\3038\302\247X=\23\3137\27\3\1\0000\3406\265k\306\303rA\177\313\nC]o\332\314\212\1M\203\r\5\26\366|\311@...\\f\267\t\247\344\344\235\5\23\341\5\2411\356Xf\337\331",
90}], 2) = 90
clock_gettime(CLOCK_MONOTONIC, {452384, 214603846}) = 0
clock_gettime(CLOCK_MONOTONIC, {452384, 215550846}) = 0
epoll_ctl(3, EPOLL_CTL_DEL, 244, {EPOLLIN, {u32=244,
u64=4954239656334983412}}) = 0
epoll_ctl(3, EPOLL_CTL_ADD, 244, {EPOLLIN, {u32=244,
u64=4954239656334983412}}) = 0
epoll_wait(3, {}, 256, 44) = 0
clock_gettime(CLOCK_MONOTONIC, {452384, 243013848}) = 0
clock_gettime(CLOCK_MONOTONIC, {452384, 244243848}) = 0
epoll_wait(3, {}, 256, 15) = 0
clock_gettime(CLOCK_MONOTONIC, {452384, 266889850}) = 0
clock_gettime(CLOCK_MONOTONIC, {452384, 268038850}) = 0
clock_gettime(CLOCK_MONOTONIC, {452384, 269136850}) = 0
epoll_wait(3, {}, 256, 241) = 0
clock_gettime(CLOCK_MONOTONIC, {452384, 513838874}) = 0
clock_gettime(CLOCK_MONOTONIC, {452384, 514661874}) = 0
clock_gettime(CLOCK_MONOTONIC, {452384, 515497874}) = 0
---HOST Kernel---
epoll_wait(3, {}, 256, 1) = 0
epoll_wait(3, {}, 256, 2984) = 0
epoll_wait(3, {}, 256, 1) = 0
epoll_wait(3, {{EPOLLIN, {u32=256, u64=256}}}, 256, 9997) = 1
recvfrom(256, "\27\3\1\0 \0241\v\215b\1x\33n?\1\10
\341\37~\333t\31\32pL\vE\16k\225\0108\235\215@\27\3\1\0000\375\275
?\310`p\253\t`cy\2248\271\22\251\33\323\326\372\f[Q\351Ks\213\3052\25\366\177\267b\233'<s\371\341\fI\324>\353t\3",
1460, 0, NULL, NULL) = 90
getpeername(256, {sa_family=AF_INET, sin_port=htons(56910),
sin_addr=inet_addr("<ip>")}, [16]) = 0
epoll_ctl(3, EPOLL_CTL_DEL, 256, {EPOLLIN, {u32=256, u64=256}}) = 0
epoll_ctl(3, EPOLL_CTL_ADD, 256, {EPOLLIN, {u32=256, u64=256}}) = 0
epoll_wait(3, {}, 256, 0) = 0
epoll_wait(3, {}, 256, 0) = 0
writev(256, [{NULL, 0}, {"\27\3\1\0
}\267Ug\354\21F\224\362\242\21\271`9\212\327d\257\20\370\306\325\6\16\206\265U\4\374\343u\210\27\3\1\0000\261\222\270g\324\26600&y[\227\5r\302Qw\331\335;d\332\211\235\217\360\376\240\276
$7\352\237\242[\322{\320\352\333\323c\366N\201{\34", 90}], 2) = 90
writev(256, [{NULL, 0}, {"\27\3\1\0
2\340K\220\264<\307\376\246Z\311\254\374
\313\3454m\245\241T\347HM\250\214a\237c\201\326\n\27\3\1\000031`X\0\275G\17%\335\200=\316\272\274\351\276\34\3352\267\316~\355\37\262\240\341uCe\307\337\262\270\260\350]\334\353\307\363\367\302?\255\276\375",
90}], 2) = 90
writev(270, [{NULL, 0}, {"<outgoing jabber messages>", 457}], 2) = 457
writev(274, [{NULL, 0}, {"<outgoing jabber messages>", 467}], 2) = 467
writev(256, [{NULL, 0}, {"\27\3\1\0
!\201}\376\5\246\202\352\26\r%#k\312\342x\251s`\325\0061\3573\321\221\211\10V\370\351T\27\3\1\00006\242\253B\330W
\3225MwZC\t\356\17!\276\231[\270\36\213\347\237\0\206-\373nc\34\20z\316\370\362N\27\2\33g\261\17\302^xa",
90}], 2) = 90
epoll_wait(3, {{EPOLLIN, {u32=256, u64=256}}}, 256, 5936) = 1
recvfrom(256, "\27\3\1\0
\20\7\320sQ\344D\20DAF\265+\211j=\245`GD\342]S\275\252\234{\217\277ao\212\27\3\1\0000\203\367\255q\364\330\266\254\336\356B\10\222\304gxC|\257\304\371l7p\354\33\3122\263SD\2>\200q\252\r\253\3552\2\205\27A~\371\237O",
1460, 0, NULL, NULL) = 90
getpeername(256, {sa_family=AF_INET, sin_port=htons(56910),
sin_addr=inet_addr("<ip>")}, [16]) = 0
epoll_ctl(3, EPOLL_CTL_DEL, 256, {EPOLLIN, {u32=256, u64=256}}) = 0
epoll_ctl(3, EPOLL_CTL_ADD, 256, {EPOLLIN, {u32=256, u64=256}}) = 0
epoll_wait(3, {}, 256, 0) = 0
mmap(NULL, 4825088, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0x7f8bbbc44000
epoll_wait(3, {}, 256, 0) = 0
writev(256, [{NULL, 0}, {"\27\3\1\0 ^t\16\344P\203\337m\246x\350\314i
E\313q\344j7\363\37K\23\241\200g*~B\273d\27\3\1\0000\246kj\304\21P\253\rK}\22Z\343{1\371\235I2\224JP\336ds\232Nw[M\237\n(\336\251\343\2*\37u\332\312\376R\201=\204z",
90}], 2) = 90
writev(256, [{NULL, 0}, {"\27\3\1\0
\\`$G\241\242/`\315\21L\337\341F\367sZ\342\314\351f\272:\252B\273\246OsH\234\240\27\3\1\0000&mH\3\236v\4\227-|bD=\237\357\306[a+\375\344\3469S\375\375\236x\370\232\255q6\243\265\303\216\237\376\363>O\244R8\5\377^",
90}], 2) = 90
writev(270, [{NULL, 0}, {"<outgoing jabber messages>", 418}], 2) = 418
writev(275, [{NULL, 0}, {"<outgoing jabber messages>", 457}], 2) = 457
writev(275, [{NULL, 0}, {"<outgoing jabber messages>, 458}], 2) = 458
writev(275, [{NULL, 0}, {"<outgoing jabber messages>", 419}], 2) = 419
writev(274, [{NULL, 0}, {"<outgoing jabber messages>", 428}], 2) = 428
epoll_wait(3, {}, 256, 0) = 0
writev(256, [{NULL, 0}, {"\27\3\1\0
;\24^\5\246\367Q\256\337\225D%2\372B\247\271\fb=\333\312\0\254\205\264
\n\4P\10,\27\3\1\0000\350\236'\23\266\313KN\241]\25\5j\332-u\312X\fS\355o\216\356W\203b\222\20nc\2008\2735\236B|J\0278\22\264\235\n\250\207\r",
90}], 2) = 90
The only big difference I can see are the many
clock_gettime(CLOCK_MONOTONIC, ...).
Regards,
Matthias
|
|
From: Matthias Rieber <supportrq@su...> - 2011-12-13 19:21:43
|
Hi, Am 13.12.2011 16:13, schrieb richard -rw- weinberger: > I'll try that. What should I grep for in the strace log? > > For anything which can cause your problem. > E.g. Failing system calls which should not fail... > > We've had problems with java and glibc where glibc used x86 specific > futex operations which are not supported on UML... > I traced a larger part and it seems that erlang causes many futex calls on the hostsystem and none on the uml kernel. Matthias |
|
From: richard -rw- weinberger <richard.weinberger@gm...> - 2011-12-13 21:46:22
|
On Tue, Dec 13, 2011 at 8:21 PM, Matthias Rieber <supportrq@...> wrote: > Hi, > > Am 13.12.2011 16:13, schrieb richard -rw- weinberger: > >> I'll try that. What should I grep for in the strace log? >> >> For anything which can cause your problem. >> E.g. Failing system calls which should not fail... >> >> We've had problems with java and glibc where glibc used x86 specific >> futex operations which are not supported on UML... >> > I traced a larger part and it seems that erlang causes many futex calls on > the hostsystem and none on the uml kernel. > That's good. UML has only limited futex support... -- Thanks, //richard |
|
From: Riccardo Murri <riccardo.murri@gm...> - 2011-12-13 19:44:37
|
Hi Matthias, On Tue, Dec 13, 2011 at 20:21, Matthias Rieber <supportrq@...> wrote: > Am 13.12.2011 16:13, schrieb richard -rw- weinberger: >> I'll try that. What should I grep for in the strace log? >> >> For anything which can cause your problem. >> E.g. Failing system calls which should not fail... >> >> We've had problems with java and glibc where glibc used x86 specific >> futex operations which are not supported on UML... >> > I traced a larger part and it seems that erlang causes many futex calls > on the hostsystem and none on the uml kernel. > I think you should run the strace *in* the UML, not on the host. Best regards, Riccardo |
|
From: Matthias Rieber <supportrq@su...> - 2011-12-13 19:58:25
|
Hi, Am 13.12.2011 20:44, schrieb Riccardo Murri: >> I traced a larger part and it seems that erlang causes many futex calls >> on the hostsystem and none on the uml kernel. >> > I think you should run the strace *in* the UML, not on the host. I run it on the uml kernel and host kernel to find the difference why it's not running properly on the uml kernel. Matthias |