1347754394 J * nakacya ~nakacya@KD118152083243.ppp-bb.dion.ne.jp 1347755421 J * fisted_ ~fisted@xdsl-87-78-182-245.netcologne.de 1347755578 Q * fisted Ping timeout: 480 seconds 1347757483 Q * clopez Ping timeout: 480 seconds 1347765615 M * Bertl_oO off to bed now ... have a good one everyone! 1347765619 N * Bertl_oO Bertl_zZ 1347771232 J * Aiken ~Aiken@2001:44b8:2168:1000:21f:d0ff:fed6:d63f 1347774358 J * ghislain ~AQUEOS@adsl2.aqueos.com 1347775887 Q * yang Remote host closed the connection 1347776681 J * yang yang@yang.netrep.oftc.net 1347784953 J * bonbons ~bonbons@2001:960:7ab:0:209d:13a7:9fd5:19d8 1347785426 J * hijacker ~hijacker@cable-84-43-134-121.mnet.bg 1347785879 Q * nakacya Remote host closed the connection 1347785902 J * nakacya ~nakacya@KD118152083243.ppp-bb.dion.ne.jp 1347786388 Q * nakacya Ping timeout: 480 seconds 1347793523 J * nakacya ~nakacya@KD118152083243.ppp-bb.dion.ne.jp 1347797686 J * Xerran ~user@04ZAAFGQQ.tor-irc.dnsbl.oftc.net 1347797778 P * Xerran 1347797909 Q * Aiken Remote host closed the connection 1347797999 Q * nakacya Remote host closed the connection 1347798021 J * nakacya ~nakacya@KD118152083243.ppp-bb.dion.ne.jp 1347798509 Q * nakacya Ping timeout: 480 seconds 1347799372 J * fisted ~fisted@xdsl-84-44-239-208.netcologne.de 1347799586 Q * fisted_ Ping timeout: 480 seconds 1347800790 Q * ghislain Quit: Leaving. 1347800799 J * ensc ~irc-ensc@p54ADE16A.dip.t-dialin.net 1347801890 Q * ensc|w Remote host closed the connection 1347801899 J * ensc|w ~ensc@www.sigma-chemnitz.de 1347804961 Q * mib_4xlzg1 Quit: http://www.mibbit.com ajax IRC Client 1347807151 M * ensc Bertl_zZ: is it possible that there is a regression between 3.2 and 3.4 regarding the vshelper? It worked fine with 3.2 but with 3.4 it will not be called or called with a completely corrupted cmdline (stack or other random content) 1347807246 M * ensc vs_reboot_helper() seems to use snprintf() wrong (the -1 in the size should be omitted) but it does not explain the seen behavior 1347807604 M * ensc call_usermodehelper_fns() copies its arguments only without duplicating them. Because cmdline, env, ... are on the vs_reboot_helper() stack and usermode helper calls the helper asynchronously, this will cause the seen corruption 1347807794 Q * macmaN Read error: Connection reset by peer 1347807869 J * macmaN ~chezburge@138.167.190.90.dyn.estpak.ee 1347808199 M * ensc Bertl_zZ: it should suffice to call do_vshelper with sync=1 1347808203 Q * macmaN Read error: Connection reset by peer 1347808319 J * macmaN ~chezburge@138.167.190.90.dyn.estpak.ee 1347808639 M * ensc ... or better sync=UMH_WAIT_PROC 1347809064 J * senrabdet 18224ae4@ircip3.mibbit.com 1347809084 M * senrabdet Hi All - Hi All: am working on getting printing to work with x2go on vserver guest. When print, appears "to work" but jobs "get stuck" in print spool (var/spool/cups) with no errors. Have been advised this may be a permissions problem and so am checking what is different on permssions between one box where can print from x2go client to x2go server (no vser 1347809110 M * senrabdet (no vserver involved) vs. x2go client to x2go server running on vserver guest. 1347809122 M * senrabdet Q: in each case, in the users home folder there is an .x2go folder with session info that gets generated when x2go connects. In both cases, in that .x2go folder there is a "spool" symlink that appears to point to a hidden folder in /tmp. - In the case though of the "x2go client to x2go server, no server", the link properties are: Type: Link to folder (i 1347809149 M * senrabdet - In the case though of the "x2go client to x2go server, no server", the link properties are: Type: Link to folder (inode/directory) Link target: /tmp/.x2go-soho/spool/C-soho-50-12478-7535_stDGNMOE_dp24 Contents: nothing 1347809160 N * Bertl_zZ Bertl 1347809163 M * senrabdet - In the case of "x2go client to x2go server on vserver guest", the link properities are: Type: link (broken) (inode/symlink) Link target: /tmp/.x2go-collins.p/spool/C-collins.p-50-1347806215_stDGNOME_dp24 Size: 66 bytes (66 bytes) 1347809165 M * Bertl morning folks! 1347809169 M * senrabdet morning 1347809191 M * senrabdet Is broken link relevant? Could this explain printing issues? 1347809199 M * daniel_hozac ensc: but it should run asynchronously. 0 should mean it waits long enough for the process to exec. 1347809214 M * ensc daniel_hozac: no; this would be '1' 1347809227 M * daniel_hozac no 1347809234 M * daniel_hozac 1 is waiting for the process to complete. 1347809235 M * ensc #define UMH_NO_WAIT 0 /* don't wait at all */ 1347809235 M * ensc #define UMH_WAIT_EXEC 1 /* wait for the exec, but not the process */ 1347809235 M * ensc #define UMH_WAIT_PROC 2 /* wait for the process to complete */ 1347809246 M * ensc include/linux/kmod.h 1347809250 M * daniel_hozac hmm, well, looks like the defines have changed then. 1347809258 M * Bertl slowly, the issue is a string/command going away during execution, yes? 1347809260 M * daniel_hozac and that's most likely why it no longer works. 1347809281 M * Bertl and yes, we definitely should use the macros 1347809305 M * senrabdet if I follow, the link appears to stay broken the whole session 1347809332 M * ensc yes; macros were changed in march 2012... 1347809348 M * Bertl senrabdet: a broken link means that whatever you are pointing to is gone 1347809407 M * ensc daniel_hozac: why should it only be UMH_WAIT_EXEC, but not PROC? 'reboot()' syscall is defined not to return so that PROC seems to be a better choice 1347809435 M * senrabdet Bertl: Ah...so it is trying to point to some hidden .x2go folder in /tmp. Does this have to do with the fstab I'm using in the vserver folder (not the /etc/fstab inside the guest). 1347809474 M * Bertl could be, could also be that it tries to create special files there (device nodes, etc) 1347809497 M * Bertl and by default, your guest will have a tmpfs without any permissions 1347809610 M * senrabdet Yes - my fstab tmp line (again for the vserver, no inside the guest) is none /tmp tmpfs size=128m,mode=1777 0 0 1347809643 M * Bertl ensc: there are more helper functions than just the reboot, but maybe the WAIT_PROC works/is a good choice for the reboot part 1347809688 M * daniel_hozac no, all the helpers are expected to be async. 1347809722 M * daniel_hozac we changed that because of some problem with running it synchronously. 1347809729 M * daniel_hozac i don't remember what it was exactly. 1347809729 M * Bertl because of the kill lockup, yes? 1347809744 M * Bertl i.e. signal doesn't get delivered until helper finishes 1347809752 M * daniel_hozac sounds familiar. 1347809756 M * Bertl helper waits for processes to get killed 1347809766 M * Bertl (something like that) 1347809925 M * Bertl UMH_WAIT_EXEC seems to even exist in 3.0, so I'd say we switch to that macro and it should be fine for all versions, no? 1347809938 M * daniel_hozac yeah 1347809966 M * Bertl ensc: do you see any problems with that? 1347809973 M * ensc Bertl: no; sounds sane 1347809985 M * ensc Bertl: but you should fix the snprintf()s too 1347809991 M * ensc (remove the -1 from size) 1347809995 M * Bertl yup 1347810128 M * senrabdet Sorry, had to leave for a minute: if use "none /tmp tmpfs size=128m,mode=1777 0 0" in the vserver configuration fstab, is that the right syntax? To try to get the link to work, should I change it? 1347810197 M * Bertl well, as I said, nothing wrong with the link itself 1347810213 M * Bertl i.e. the link works as intended, the target is not there :) 1347810237 M * senrabdet Oh...so need to look elsewhere possibly in other permissions.... 1347810245 M * Bertl check what x2go wants to put in the tmp dir (e.g. with strace or by looking through the logs) 1347810274 M * Bertl and depending on that, add the necessary permissions 1347810278 M * senrabdet OK (hang on) 1347810400 M * Bertl ensc, daniel_hozac: so we make that: 1347810405 M * Bertl sync ? UMH_WAIT_PROC : UMH_WAIT_EXEC, 1347810415 M * Bertl in do_vshelper(), agreed? 1347810506 J * sannes ~ace@cm-84.211.87.28.getinternet.no 1347810520 M * ensc ok; seems to require the smallest changes 1347810601 M * Bertl I have no problem if we additionally define 1347810616 M * Bertl VXS_HELPER_SYNC and VXS_HELPER_ASYNC or so 1347810669 M * Bertl but we currently do not handle the completely async case in do_vshelper() and I don't think we'll ever need it 1347811258 M * Bertl http://vserver.13thfloor.at/ExperimentalT/delta-vshelper-fix02.diff 1347811895 M * Bertl ensc, daniel_hozac: if you are fine with the patch, I'll roll a new kernel for each of the maintained 3.x versions 1347811915 M * Bertl s/kernel/patch/ 1347811952 M * daniel_hozac yeah, looks good. 1347812016 M * ensc yes; it's ok 1347812027 M * Bertl excellent! thanks! 1347814372 Q * senrabdet Quit: http://www.mibbit.com ajax IRC Client 1347814879 J * ghislain ~AQUEOS@adsl2.aqueos.com 1347815043 Q * ghislain 1347815616 Q * fisted Quit: leaving 1347816500 J * fisted ~fisted@xdsl-84-44-239-208.netcologne.de 1347818714 Q * ensc|w Remote host closed the connection 1347819399 J * ghislain ~AQUEOS@adsl2.aqueos.com 1347822325 J * ensc|w ~ensc@www.sigma-chemnitz.de 1347822371 Q * ensc|w Remote host closed the connection 1347822625 J * ensc|w ~ensc@www.sigma-chemnitz.de 1347826090 M * Bertl off for a nap ... bbl 1347826105 N * Bertl Bertl_zZ 1347826893 J * Aiken ~Aiken@2001:44b8:2168:1000:21f:d0ff:fed6:d63f 1347827117 Q * sannes Remote host closed the connection 1347827400 Q * cuba33ci Read error: Connection reset by peer 1347827463 Q * hijacker Quit: Leaving 1347827503 J * cuba33ci ~cuba33ci@114-36-245-175.dynamic.hinet.net 1347828806 Q * bonbons Quit: Leaving 1347832365 Q * ghislain Quit: Leaving. 1347832626 Q * ntrs_ Ping timeout: 480 seconds 1347833007 J * ntrs ~ntrs@vault08.rosehosting.com 1347833605 Q * click Ping timeout: 480 seconds 1347834966 N * ensc Guest7271 1347834976 J * ensc ~irc-ensc@p54ADF9CA.dip.t-dialin.net 1347835387 Q * Guest7271 Ping timeout: 480 seconds 1347837274 N * Bertl_zZ Bertl 1347837278 M * Bertl back now ... 1347839174 J * nakacya ~nakacya@KD118152083243.ppp-bb.dion.ne.jp