1295315426 Q * Romster Remote host closed the connection 1295315464 J * Romster ~romster@202.168.100.149.dynamic.rev.eftel.com 1295325678 Q * micah Quit: leaving 1295326851 J * micah ~micah@micah.riseup.net 1295326938 J * melbar1 ~kiko@187.58.98.230 1295327216 Q * melbar Ping timeout: 480 seconds 1295327618 J * petzsch ~markus@dslb-092-078-228-087.pools.arcor-ip.net 1295327969 M * Bertl off to bed now ... have a good one everyone! 1295327973 N * Bertl Bertl_zZ 1295328677 J * awk ~awk@gw1.security.web.za 1295328709 M * awk Morning 1295328734 M * awk If somebody has a second could they maybe share some light on this - http://pastebin.com/a4wGNfWJ 1295328746 M * awk If I enable alot of flags then it starts, but I would like to start it with no flags? 1295328773 M * awk Also if I start it with allot of flags then I have no eth0 in the vserver.. However the CentOS vserver does have an eth0 1295329105 M * awk If I chroot to it, then I can use the network 1295329112 M * awk (ofcourse) 1295332699 M * awk never mind, it's a baselayout issue 1295334309 M * arekm Bertl_zZ: usertime/systime being 0 in vserver-stat - was this figured out? 1295337398 J * kir ~kir@swsoft-msk-nat.sw.ru 1295337641 Q * nkukard Ping timeout: 480 seconds 1295338429 J * nkukard ~nkukard@196-208-244-204.dynamic-8632.isgsm.net 1295339038 Q * Piet Remote host closed the connection 1295339068 J * Piet ~Piet__@659AAB0AX.tor-irc.dnsbl.oftc.net 1295340701 Q * nkukard Ping timeout: 480 seconds 1295340864 M * awk hrm, vprocunhide how to enable this, just touch /etc/vservers/.defaults/apps/vprocunhide 1295340865 M * awk ? 1295340963 Q * petzsch Quit: Leaving. 1295341537 J * nkukard ~nkukard@41-133-203-144.dsl.mweb.co.za 1295346413 M * ard /etc/init.d/vprocunhide start 1295346423 M * ard ? 1295347491 Q * DoberMann Ping timeout: 480 seconds 1295348704 P * kir Leaving. 1295348836 M * awk na, don't have that service.. 1295348840 M * awk it's fine that touch worked 1295348844 Q * awk 1295349099 J * DoberMann ~james@2a01:e35:8b44:84c0:230:18ff:fea3:7188 1295349569 J * barismetin ~barismeti@zanzibar.inria.fr 1295350174 J * manana ~mayday090@84.17.25.149 1295350714 Q * Piet Ping timeout: 480 seconds 1295351299 J * Piet ~Piet__@659AAB0EU.tor-irc.dnsbl.oftc.net 1295351384 Q * melbar1 Remote host closed the connection 1295351814 J * petzsch ~markus@dslb-092-078-228-087.pools.arcor-ip.net 1295353645 Q * Piet Remote host closed the connection 1295353699 J * Piet ~Piet__@659AAB0FG.tor-irc.dnsbl.oftc.net 1295354936 J * yarihm ~yarihm@149-39-239-77-pool.cable.fcom.ch 1295356732 J * thierryp ~thierry@home.parmentelat.net 1295357350 J * melbar ~kiko@187.78.38.111 1295358388 N * ensc Guest679 1295358398 J * ensc ~irc-ensc@p5DF2C734.dip.t-dialin.net 1295358796 Q * Guest679 Ping timeout: 480 seconds 1295358940 Q * petzsch Quit: Leaving. 1295360950 Q * barismetin Remote host closed the connection 1295361733 Q * thierryp Remote host closed the connection 1295364151 J * ktwilight_ ~keliew@91.176.87.242 1295364151 Q * ktwilight Read error: Connection reset by peer 1295364229 Q * sladen Ping timeout: 480 seconds 1295365265 J * sladen ~paul@starsky.19inch.net 1295365979 J * thierryp ~thierry@82.226.190.44 1295365986 Q * thierryp Remote host closed the connection 1295366463 J * dna ~dna@dslb-088-074-197-070.pools.arcor-ip.net 1295366538 J * hparker_lappie ~hparker@2001:470:1f0f:32c:beae:c5ff:fe01:b647 1295366555 Q * hparker_lappie Remote host closed the connection 1295367162 J * lamvak ~lamvak@078088249025.wroclaw.vectranet.pl 1295367988 N * Bertl_zZ Bertl 1295367992 M * Bertl morning folks! 1295368151 Q * dna Read error: Connection reset by peer 1295368171 J * dna ~dna@dslb-088-074-197-070.pools.arcor-ip.net 1295368195 Q * Chlorek Ping timeout: 480 seconds 1295368329 J * Chlorek nobody@2001:6a0:183:f002::3 1295368547 M * lamvak mor'v'ning 1295368662 N * ensc Guest697 1295368672 J * ensc ~irc-ensc@p5DF2C734.dip.t-dialin.net 1295368831 Q * Guest697 Ping timeout: 480 seconds 1295369037 A * arekm wonders if {user,sys}TIME problem could be in util-vserver 1295369517 M * Bertl it definitely is there, I presume it does not handle the 'new' proc format 1295369661 J * petzsch ~markus@dslb-092-078-228-087.pools.arcor-ip.net 1295370098 M * arekm what's new in it? 1295370118 M * Bertl we removed the TBS fields from the sched entry 1295370138 M * Bertl (together with the TB scheduler) 1295370387 J * bonbons ~bonbons@2001:960:7ab:0:2c0:9fff:fe2d:39d 1295370402 M * arekm Bertl: vserver-stat seem to use /proc/xyz/stat for cputime 1295370440 M * Bertl for a context? 1295370462 M * Bertl well, might be, if so, it must be a mainline change then 1295370578 M * arekm hm, does that only if !vc_isSupported(vcFEATURE_VSTAT) 1295370598 M * arekm I guess recent vservers do support this feature 1295370636 M * arekm ok, it fetches info via vc_sched_info 1295370686 M * arekm which is a syscall 1295370730 M * Bertl hmm 1295370940 M * arekm Bertl: vc_isSupported(vcFEATURE_VSTAT) is returning false; am I right that this should be supported? 1295371000 M * arekm ./lib/issupported.c: case vcFEATURE_VSTAT : return ver >= 0x00020103 && ver < 0x00020306; 1295371005 M * arekm ouh, or not 1295371123 M * Bertl vc_sched_info() is gone since 020306 that is correct ... 1295371177 M * Bertl maybe we should keep it with the user/sys information or add a new one with this data? daniel_hozac? 1295371212 M * arekm non cgroup handler works. cgroup doesn't 1295371263 Q * lamvak Quit: Leaving. 1295371376 M * Bertl I presume the non cgroup version gets the information by just summing up the process data (which is a sensible thing to do as there are no other clues) 1295371920 M * arekm cgroup version also uses vc_sched_info 1295371930 M * arekm and this means kernel is guilty 1295371977 M * Bertl well, we removed vc_sched_info() so it is unlikely to provide anything except a return code :) 1295371993 M * arekm doh, and what is replacement? 1295372020 M * Bertl it was removed with cgroup accounting as replacement 1295372148 M * Bertl but as I said, it might make sense to have something similar for retrieving the accounted user/sys times (which are still valid) 1295372168 M * Bertl the other entries in vc_sched_info() are not available anymore 1295372308 M * Bertl nah, we can remove that as well, the cpuacct cgroup provides that info 1295372406 M * Bertl cpuacct.stat file lists a few statistics which further divide the CPU time obtained by the cgroup into user and system times. Currently the following statistics are supported: 1295372412 M * Bertl user: Time spent by tasks of the cgroup in user mode. 1295372412 M * Bertl system: Time spent by tasks of the cgroup in kernel mode. 1295372532 M * Bertl so we should completely switch to that for newer util-vserver 1295375080 M * arekm user/system - I assue in seconds? 1295375097 M * arekm and previous interface used what? miliseconds? microseconds? (utime_total) 1295375116 M * arekm or also seconds... but in such cae these look preety low 1295375253 M * arekm http://pld.pastebin.com/jTPzi5hP 1295375274 M * Bertl msec 1295375297 M * Bertl fields are labeled user_msec and sys_msec 1295375391 M * arekm user and system are in USER_HZ unit. 1295375393 M * arekm bahh 1295375459 M * arekm not sure what USER_HZ is from userspace point of view 1295375493 M * arekm afaik it's 100 for userpace (always) 1295375556 M * arekm 100 70 6.5G 1.5G 21h35m32 7h39m37 1d06h06 carme-pld 1295375564 M * Bertl well, I doubt so 1295375573 M * Bertl you can select USER_HZ in the kernel config 1295375584 M * arekm looks more correct for uptime 1 day 6 hours 1295375625 M * arekm kernel != userspace. AFAIK all userspace interfaces in kernel use 100 1295376084 M * arekm daniel_hozac: http://cvs.pld-linux.org/cgi-bin/cvsweb/packages/util-vserver/util-vserver-usersystime.patch?rev=1.1 1295377170 M * arekm It reports times with a granularity defined by the kernel constant USER_HZ. Userspace 1295377173 M * arekm applications can determine the value of this constant using sysconf(_SC_CLK_TCK). 1295377316 M * Bertl for example on alpha: 1295377318 M * Bertl #ifdef __KERNEL__ 1295377318 M * Bertl #define HZ CONFIG_HZ 1295377318 M * Bertl #define USER_HZ HZ 1295377405 M * Bertl same goes for h8300 and ia64, btw 1295377502 M * Bertl so yes, retrieving and using that value will be required on those archs (and should be done on any arch) 1295377552 M * arekm daniel_hozac, Bertl: http://cvs.pld-linux.org/cgi-bin/cvsweb/packages/util-vserver/util-vserver-usersystime.patch?rev=1.2 1295377561 M * arekm Bertl: this one should work on these then 1295377608 M * arekm now only that creds problem left ;/ 1295377651 M * Bertl hmm * USER_HZ ? shouldn't that be / USER_HZ to get seconds? 1295377674 M * arekm but you used ms 1295377689 M * Bertl then it should be * 1000 / USER_HZ no? 1295378395 M * arekm right 1295378491 Q * yarihm Quit: This computer has gone to sleep 1295378540 M * arekm http://cvs.pld-linux.org/cgi-bin/cvsweb/packages/util-vserver/util-vserver-usersystime.patch?rev=1.3 1295378543 M * arekm updated 1295378589 M * Bertl yep, looks better ... let's see what daniel_hozac thinks 1295378609 M * arekm likely he won't like sscanf used there but who knows ;P 1295379600 J * yarihm ~yarihm@149-39-239-77-pool.cable.fcom.ch 1295379805 Q * yarihm 1295379942 J * mib_kz12nz 55b545a3@ircip3.mibbit.com 1295380120 M * mib_kz12nz hi, is somebody who knows the linux vserver together with long running sync call (~1700s) on clients 1295380310 J * fzylogic ~fzylogic@208.80.64.200 1295380400 M * Bertl mib_kz12nz: hmm? 1295380431 M * mib_kz12nz i wrote a script to monitor the sync() call through strace 1295380468 M * mib_kz12nz I put the measured values into a chart 1295380512 M * mib_kz12nz The chart shows long running sync() calls multiple time. The current maximum is about 1700s 1295380542 M * Bertl depending on the kernel, sync can take quite a while, especially if new requests are queued 1295380563 M * mib_kz12nz Is it my fault? 1295380566 M * Bertl the kernels 2.6.26-2.6.35 were extremely bad in this regard 1295380594 M * Bertl 2.6.36 was the first one to fix the extemely bad I/O performance 1295380625 M * Bertl (before that, 2.6.22 was fine too, at least to some extent) 1295380656 M * Bertl but that's not really Linux-VServer related, i.e. you see the same performance problems on vanilla (kernel.org) kernels 1295380660 M * mib_kz12nz hmm, I guess 2.6.33.2-vs2.3.0.36.30.4 is bad :-) 1295380724 M * mib_kz12nz thanks for your help 1295380809 Q * Piet Remote host closed the connection 1295380832 P * mib_kz12nz 1295380874 J * Piet ~Piet__@659AAB0OH.tor-irc.dnsbl.oftc.net 1295382824 J * hijacker_ ~hijacker@87-126-142-51.btc-net.bg 1295383906 J * dna_ ~dna@dslb-088-074-219-236.pools.arcor-ip.net 1295384004 J * dna__ ~dna@dslb-088-074-209-001.pools.arcor-ip.net 1295384331 Q * dna Ping timeout: 480 seconds 1295384419 Q * dna_ Ping timeout: 480 seconds 1295385351 Q * bonbons Quit: Leaving 1295388173 Q * hijacker_ Quit: Leaving 1295388295 Q * petzsch Quit: Leaving. 1295390688 Q * dna__ Quit: Verlassend