1157760004 M * Bertl check out the 03_base one, scroll down to the middle 1157760008 M * matti Bertl: Cool! Thanks! 1157760027 M * node_ okay, im there 1157760035 M * matti Bertl: No I can merge with -cks a lot easiest :) 1157760047 M * matti s/No/Now/ 1157760059 M * Bertl node_: you'll see that we add vx_info/xid and nx_info/nid to each task 1157760149 M * Bertl node_: in 08_context you'll find the vx_info at the beginning 1157760181 M * Bertl it contains all the info which makes up a 'context' or guest 1157760351 J * Hollow_ ~hollow@2001:a60:f026::1 1157760352 Q * Hollow Read error: Connection reset by peer 1157760566 M * node_ ahh right, that was mentioned in the paper i read on linux-vserver.org 1157760585 M * node_ i'll take a look at what'd it take to start porting the security server 1157760720 M * Bertl node_: let me add the following 'setup' detail (you will encounter in Linux-VServer setups) 1157760747 M * Bertl we currently put guests into a separate namespace and chroot() into the guest from there 1157760892 M * node_ okay, that really shouldnt affect the security server 1157760938 M * Bertl just wanted to mention it, as it causes some issues with grsec every now and then :) 1157760947 M * node_ oh absolutely 1157761004 M * node_ the most significant task i see will be getting the security server to render decisions based upon a third criterion now: the process' context 1157761023 M * node_ the term 'context' is so overloaded here.. in selinux-land, 'context' refers to a process' security attributes 1157761058 M * doener well, you'll actually make decisions based on the xid (most probably) so you can use that term ;) 1157761696 M * node_ so what is vserver's status in terms of being accepted upstream? 1157761741 M * Bertl we are currently working with mainline folks to get some kind of *space based virtualization framework into mainline 1157761810 M * node_ is it looking like it'll be in 2.6 or more likely for 2.7? 1157761831 M * Bertl some patches are already in -mm, not sure there will be a 2.7 :) 1157761879 M * node_ wow, i didnt realize it was this far along 1157762002 M * doener well, "some patches" doesn't mean that much... Bertl, is there anything besides the namespace thingy in -mm? 1157762033 Q * Johnnie Remote host closed the connection 1157762186 M * Bertl doener: pid space was submitted several times, and user space should be in by now 1157762214 M * Bertl but yes, noting solid yet, just a few tests which do not change the behaviour 1157762556 M * doener Bertl: what do you mean by "user space"? 1157762585 M * Bertl well, uid/gid stuff and process relation 1157762638 M * doener hm, must have completely missed those patches on lkml... seems I'm hittig ^R too often in mutt ;) 1157762645 M * doener s/hittig/hitting/ 1157762684 M * Bertl not sure they were on LKML though, folks moved to another mailing list which didn't manage to add our mailing list yet 1157762688 J * Johnnie ~jdlewis@static-acs-24-154-32-33.zoominternet.net 1157762707 M * doener ah, the csm(?) list 1157762747 M * Bertl Linux Containers 1157762772 M * Bertl might be worth subscribing for now, until they get the forward fixed 1157762817 M * doener ah, I meant lxc anyway... ;) 1157762973 M * Skram Skram is back! Oh noes! 1157763043 Q * DreamerC_ Quit: leaving 1157763062 J * DreamerC ~dreamerc@61-217-227-61.dynamic.hinet.net 1157763970 J * s0undt3ch ~s0undt3ch@bl7-240-146.dsl.telepac.pt 1157764188 Q * id23 Ping timeout: 480 seconds 1157764430 M * doener I don't see the reasons for failing hunks anymore... time to sleep, will finish the port tomorrow 1157764435 M * doener good night! 1157764675 M * matti Good night doener :) 1157764679 M * matti Sleep well. 1157765270 Q * Piet Quit: :tiuQ 1157765742 J * Piet hiddenserv@tor.noreply.org 1157765856 J * transacid ~transacid@transacid.de 1157766180 M * Bertl welcome transacid! 1157766198 M * matti :) 1157767266 J * mire ~mire@166-167-222-85.COOL.ADSL.VLine.verat.net 1157768151 M * Bertl wb mire! 1157770775 J * juggo ~lemur@h-68-166-181-4.sttnwaho.covad.net 1157771927 J * FireEgl FireEgl@2001:5c0:84dc:1:4:: 1157772231 M * ray6 ah, bertl mal wieder zu vernueftigen Zeiten wach? :) Hi... 1157772399 Q * Piet Quit: :tiuQ 1157773302 M * Bertl ray6: indeed! 1157773497 Q * m4z Ping timeout: 480 seconds 1157775239 M * ray6 und wie geht's so? 1157775262 M * Bertl please, english or pm :) 1157775283 M * Bertl otherwise I have to add translations to the irc logs too :) 1157775354 Q * node_ 1157775792 M * ebiederm Bertl: What seems half way solid in -mm are the trivial uts and ipc namespaces. 1157775824 M * Bertl excellent, we will start to integrate that into Linux-VServer very soon 1157775859 M * ebiederm Cool. I thought you might have missed those.. 1157775862 M * ray6 Bertl: ohm sorry, of course :) 1157775914 M * ebiederm Bertl: As for linux-containers versus linux-kernel. The idea is the flame fest (design discussion) happen on the containers mailing list but all of the final patches should hit linux-kernel. 1157775922 M * ebiederm As far as I know that has been followed so far. 1157775940 M * Bertl ebiederm: well, it seems that most parties carefully try to find ways so that I do not get the info, but I'm also working hard to gather that information on my side :) 1157776023 M * ebiederm Bertl: Good. I know there have been problems. 1157776068 M * ebiederm I don't have the evidence to describe any of it as malice, but it certainly hasn't helped keep you in the loop. 1157776088 M * ebiederm Hopefully with a sane mailing list that every one can subscribe to, it will be easier to keep every one in the loop. 1157776111 M * Bertl btw, any good reason why folks seem to stick with the MNT for the 'original' namespace, I consider VFS much more appropriate, but didn't get any feedback 1157776153 M * ebiederm The pid namespace is very close. But there is still some heavy lifting to do, to remove the use of pid_t in most of the kernel. 1157776167 M * Bertl yes, I saw that ... 1157776195 M * ebiederm I think I have about 30 patches in my working queue that I need to finish that chunk of the cleanup. 1157776206 M * ebiederm As for mnt. I guess that it what it currently describes. 1157776219 M * ebiederm As long as we pick a name and use it I really don't care. 1157776265 M * ebiederm The only concern I saw was the idea of having a namespace which filesystems the kernel supports. 1157776271 M * Bertl well, I'm okay with that too, just wanted to know why I didn't get any feedback in the first place ... 1157776314 M * Bertl ray6: I'm quite fine, a little too busy for my taste, but that will get better soon ... 1157776323 M * Bertl ray6: and you? 1157776495 M * ebiederm Bertl: I don't know why you didn't get feedback. I remember seeing your post, so it should have made it to everyone. 1157776582 M * Bertl okay, well, I think I could make better use of my time (than reading discussions) when in the end my questions/replies are ignored ... 1157776645 M * ebiederm Bertl: There is an element of that. 1157776800 M * ebiederm There was also a lot of email flying yesterday, and your vfs_namespace idea was a very gentle suggestion. 1157776825 M * ebiederm I think the real lack of feedback there was that the name didn't resonate with anyone. 1157776852 M * ebiederm The most useful feedback is submitting and reviewing patches. 1157776861 M * Bertl okay, np, maybe I just got the wrong impression 1157776884 M * ebiederm If you find something in a patch that is a problem it has very little chance of being included in mainstream. 1157776925 M * Bertl okay, that's why I plan to integrate it into Linux-VServer shortly ... so that we see _what_ is missing and/or wrong ... 1157776939 M * ebiederm The rest of the discussion is ultimately which patches should we write. 1157776984 M * ebiederm Bertl: That is a very good approach and Andrew Morton acutally asked for that. Hopefully the OpenVz will follow suite as well. 1157776985 M * Bertl is there an up-to-date git repository besides the mm tree? 1157777018 M * ebiederm Bertl: Except for where -mm in imported into git I don't think so. 1157777056 M * ebiederm A lot of this is actually expected to be put into the stock kernel as soon as the merge window opens. 1157777132 M * ebiederm I think my biggest pain is that I recently realized that user bean counters introduce a new global identifier space. 1157777144 M * ebiederm Ouch! 1157777167 M * ebiederm Now I have to pay attention to them. 1157777320 M * Bertl well, I'm not very happy with the UBC approach, as it is very 'heavy' 1157777346 M * Bertl and CKRM is no viable alternative either, as it is over engineered 1157777365 M * ebiederm How is UBC 'heavy' ? 1157777492 M * Bertl well it is very generic, and certain resource checks require a lot of locks to be taken and released 1157777514 M * Bertl also the hash structure adds unnecessary overhead for context accounting 1157777622 M * ebiederm Ok. An internal implementation issue not necessarily with the interface (unless the interface implice a hash I will have to look). 1157777737 M * Bertl thing is, we do roughly the same accounting as UBC does, but I would say that our current accounting is much faster/less intrusive than UBC 1157777765 M * ebiederm Bertl: You do it in a vserver specific way? 1157777767 M * Bertl (same goes for the limits of course) but I guess this area is something we could safely postpone till later 1157777799 M * Bertl ebiederm: we do most things in a vserver specific way :) 1157777870 M * ebiederm Bertl: True. I guess I should have asked does what you do easily port to what we are merging into the kernel? 1157777917 M * Bertl well, we have N places where we do accounting, which is tied directly to a vx_info substructure (context structure) 1157777987 M * ebiederm Which would roughly be a namespace in the current way of figuring things. 1157777996 M * Bertl exactly 1157778096 M * ebiederm For most of the where the are disjoin that really isn't a problem. The mount and pid namespaces that is a bit of a challgenge. 1157778127 M * ebiederm Accounter per namespace is certainly something that can be added fairly easily later. 1157778298 M * ebiederm I don't think I'm going to make it but (time permitting) I'm going to see how close I can get to getting the pid namespace into 2.6.19 1157778348 M * ebiederm That should really help the momentum of this project :) 1157778386 M * ebiederm Although things are actually starting to go pretty well with the original developers as it is. 1157778434 M * ebiederm The question. Which will be first a useable set of namespaces or usable paravirt support in the kernel :) 1157778463 M * ebiederm Bertl: Sleep well. I think I'm off for the night. 1157778509 M * Bertl okay, me too, have a good one! 1157778727 M * ray6 ah, n8 bertl... one question I had in mind: was the recent /proc race-condition in the kernel a problem for v-server guests having /proc bind-mounted? 1157778884 M * Bertl we usually do not bind mount proc 1157779034 M * ebiederm ray6: Which /proc race-condition 1157779065 M * ray6 the one giving possible root-compromise fixed in 2.6.16.whatever (20 or so) 1157779248 M * ebiederm ray6: Sorry I don't know. I was confused because I just fixed a readdir race in /proc. (It would occassionally miss processes). 1157779422 M * Bertl ray6: do you have an url for that? 1157779489 M * ray6 bertl: wait a second... iirc it has something to do with creating suid stuff in /proc 1157779536 M * ebiederm ray6: I think it was a suid /proc/pid/environ file. 1157779543 M * ebiederm And I don't think it was a race. 1157779634 M * ray6 the originl advisory called it a race condition :) http://lists.grok.org.uk/pipermail/full-disclosure/2006-July/047907.html http://secunia.com/cve_reference/CVE-2006-3626/ 1157779779 M * ray6 so the question remains would this be possible inside a guest or is prctl limited in a way that these kinds of operations don't work anyway? 1157779829 M * ray6 on the linux-vserver proc (bertl: sorry for calling it bind-mount, I thiught it was realized in a similar way but obviously it's more like a virtualized /proc ?) 1157780011 J * gerrit ~gerrit@c-67-160-146-170.hsd1.or.comcast.net 1157780017 M * Bertl well, if it works I think it would give you guest root or so 1157780062 M * ray6 Bertl: yeah, more shouldn't be possibly by that kind of exploit 1157780095 M * Bertl we do not modify the pid entries in proc, except for the init pid change, so it is likely to work 1157780235 M * Bertl okay, now really off to bed .. :) 1157780242 M * Bertl have a good one everyone! cya tomorrow! 1157780247 N * Bertl Bertl_zZ 1157780251 M * ray6 ok n8 :) 1157782408 J * meandtheshell ~markus@85-124-232-148.work.xdsl-line.inode.at 1157783049 M * Skram Hey all 1157783075 M * Skram Yey for new wiki design 1157783101 M * Skram cool-- new stable? 1157783121 M * Skram 2.6.17.7-vs2.0.2-rc27 is what I'm running 1157783777 Q * Smutje Ping timeout: 480 seconds 1157783957 Q * brc_ Ping timeout: 480 seconds 1157784853 J * tso ~tso@196-019.adsl.pool.ew.hu 1157784857 M * tso hi all 1157786294 Q * meandtheshell Remote host closed the connection 1157786424 Q * juggo Quit: Download Gaim: http://gaim.sourceforge.net/ 1157786471 J * meandtheshell ~markus@85-124-233-95.work.xdsl-line.inode.at 1157787582 Q * mire Ping timeout: 480 seconds 1157789555 J * bonbons ~bonbons@83.222.36.236 1157789940 Q * cryptronic Quit: changing servers 1157789952 J * cryptronic crypt@mail.openvcp.org 1157790019 Q * fs Quit: changing servers 1157790070 J * fs fs@213.178.77.98 1157790139 J * gdm ~gdm@www.iteration.org 1157790910 J * MooingLemur ~troy@shells200.pinchaser.com 1157791362 J * brc_ ~bruce@201.19.133.110 1157791469 Q * brc_ 1157791474 J * brc_ ~bruce@201.19.133.110 1157791720 Q * cehteh helium.oftc.net nobelium.oftc.net 1157791720 Q * nayco helium.oftc.net nobelium.oftc.net 1157791720 Q * Loki|muh helium.oftc.net nobelium.oftc.net 1157791720 Q * matti helium.oftc.net nobelium.oftc.net 1157791720 Q * waldi helium.oftc.net nobelium.oftc.net 1157791720 Q * nebuchadnezzar helium.oftc.net nobelium.oftc.net 1157791752 J * Loki|muh loki@satanix.de 1157791985 J * nayco ~nayco@proxy2.laroche.univ-nantes.fr 1157791999 J * matti matti@linux.gentoo.pl 1157792470 J * cehteh ~ct@cehteh.homeunix.org 1157792470 J * nebuchadnezzar ~nebu@zion.asgardr.info 1157792470 J * waldi ~waldi@bblank.thinkmo.de 1157792617 J * ||Cobra|| ~cob@pc-csa01.science.uva.nl 1157792829 J * id23 ~id@p50812CDF.dip0.t-ipconnect.de 1157792895 Q * cehteh Server closed connection 1157792895 Q * nebuchadnezzar Server closed connection 1157792895 Q * waldi Server closed connection 1157792899 J * waldi ~waldi@bblank.thinkmo.de 1157792899 J * nebuchadnezzar ~nebu@zion.asgardr.info 1157792921 J * cehteh ~ct@cehteh.homeunix.org 1157793791 J * kaner_ kaner@strace.org 1157793796 Q * kaner_ 1157795936 J * m4z m4z@bastard-operator.from-hell.net 1157796511 J * Aiken ~james@tooax6-140.dialup.optusnet.com.au 1157796737 M * meandtheshell morning folks - the grsec patched Linux-VServer kernel image is not available from an official debian mirror - right? 1157796789 A * meandtheshell just wanted to ensure this before going for a compile session :) 1157796917 M * daniel_hozac i would say that's highly unlikely. 1157797042 M * harry uhu 1157797065 M * harry what options would you enable by default, huh ;) 1157797456 J * romke ~romke@acrux.romke.net 1157797616 J * Viper0482 ~Viper0482@p54976828.dip.t-dialin.net 1157797619 P * Viper0482 1157797921 J * DreamerC_ ~dreamerc@59-117-96-36.dynamic.hinet.net 1157797921 Q * DreamerC Read error: Connection reset by peer 1157798453 J * murli1 ~murli@pub-nms.stcl.com 1157798537 P * murli1 1157799048 J * DreamerC ~dreamerc@59-115-55-247.dynamic.hinet.net 1157799049 Q * DreamerC_ Read error: Connection reset by peer 1157799737 M * gdm morning all. i'm just trying to set up a new kernel and was wondering what present recommendations were 1157799795 M * gdm i see kernel.org has 2.6.17.12 as the latest stable version, but linux-vserver.org lists 2.6.17.11 as the latest one patched 1157799804 M * gdm so should i use 2.6.17.11 ? 1157800066 M * gdm ok, gonna use 2.6.17.11 1157800408 M * daniel_hozac 2.6.17.13 is the latest one. 1157800624 M * daniel_hozac 2.0.2 only fails on the Makefile and some offsets on fs/ext2/super.c and fs/locks.c. 1157800828 Q * DreamerC Quit: leaving 1157800849 J * DreamerC ~dreamerc@59-115-55-247.dynamic.hinet.net 1157800993 M * gdm mmm... well, i think i will try first with 2.6.17.11 and if i'm successful, then i will try a later version 1157801003 A * gdm still very much a n00b 1157801101 Q * DreamerC 1157801162 J * DreamerC ~dreamerc@59-115-55-247.dynamic.hinet.net 1157801196 Q * DreamerC 1157801214 J * DreamerC ~dreamerc@59-115-55-247.dynamic.hinet.net 1157801308 Q * DreamerC 1157801335 J * DreamerC ~dreamerc@59-115-55-247.dynamic.hinet.net 1157801843 M * matti Hello. 1157802708 J * vrwttnmtu ~eryktyktu@82-69-161-137.dsl.in-addr.zen.co.uk 1157802715 M * vrwttnmtu Hello all! 1157802744 M * vrwttnmtu Is there any reason why /proc/net/tcp should act differently in a vserver than on a "normal" host? 1157802811 M * vrwttnmtu I am trying to run munin in a vserver, and a plugin that reads /proc/net/tcp to see how many connections on a certain port there currently are fails with: 1157802819 M * vrwttnmtu /var/run/munin/plugin-state/_proc_net_tcp.32096: open: Disk quota exceeded 1157802828 M * vrwttnmtu 2006/09/09-12:50:04 [31977] Plugin "port_5223" exited with status 31232. ---- 1157803060 Q * wenchien Quit: Terminated with extreme prejudice - dircproxy 1.0.5 1157803522 Q * shedi Quit: Leaving 1157804086 M * doener vrwttnmtu: that doesn't seem to be related to /proc/net/tcp at all... just disk quota 1157804148 M * vrwttnmtu doener, There aren't any disk quotas enabled, and I have many gigs free. 1157804207 M * daniel_hozac how about inodes? 1157804208 M * vrwttnmtu My guess was that something in the vserver was preventing it, and spitting out an exit code that the plugin mistakes 1157804224 M * vrwttnmtu # df -h 1157804224 M * vrwttnmtu Filesystem Size Used Avail Use% Mounted on 1157804224 M * vrwttnmtu /dev/hdv1 58G 31G 27G 54% / 1157804224 M * vrwttnmtu none 16M 8.0K 16M 1% /tmp 1157804231 M * vrwttnmtu # df -i 1157804231 M * vrwttnmtu Filesystem Inodes IUsed IFree IUse% Mounted on 1157804231 M * vrwttnmtu /dev/hdv1 60033088 984072 59049016 2% / 1157804231 M * vrwttnmtu none 129538 7 129531 1% /tmp 1157804240 M * vrwttnmtu It's not what it says it is 1157804246 M * vrwttnmtu It's nothing to do with disk. 1157804280 M * vrwttnmtu daniel_hozac, would the ipv6 patches change the way the /proc/net stuff is done? 1157804295 M * daniel_hozac not for IPv4. 1157804358 M * vrwttnmtu Oh, and if I run the plugin manually, it works: # /etc/munin/plugins/port_993 1157804358 M * vrwttnmtu count.value 1 1157804368 M * vrwttnmtu I guess it's a munin problem 1157804444 M * vrwttnmtu daniel_hozac, How is setuid/setgid handled in vserver - any difference? 1157804456 M * doener no 1157804483 M * vrwttnmtu Cos running it as root, it works fine. Telnet to the port, and issue: fetch port_993, and it fails with that error 1157804518 M * vrwttnmtu Even though the node runs as root (I know, I hate it too) 1157804659 M * daniel_hozac are you sure the plugins run as root? 1157804705 M * vrwttnmtu Well, as much as I can be 1157804722 M * vrwttnmtu There's a config file where you can specify user/group for a particular plugin 1157804909 M * vrwttnmtu And the perms on /proc/net/tcp are 444 1157805035 M * doener are there bash scripts? 1157805053 M * vrwttnmtu root 5879 0.0 0.3 6424 4088 ? S 13:30 0:00 /usr/sbin/munin-node [xxx.xxx.xxx.xxx] 1157805053 M * doener s/there/these/ 1157805058 M * vrwttnmtu Perl mainly 1157805070 M * vrwttnmtu #!/usr/bin/perl 1157805070 M * vrwttnmtu # 1157805099 M * vrwttnmtu Let me paste the script that is failing somewhere 1157805107 M * vrwttnmtu What's the paste-bin these days 1157805130 M * doener hm, so no -x... can you strace the process? maybe its parent with -ffF -o bla? 1157805271 M * vrwttnmtu http://paste.linux-vserver.org/346 1157805362 M * vrwttnmtu It works when run from the command line though, so the script is fine 1157805377 M * vrwttnmtu It's just when it's run via the listener. 1157805382 M * vrwttnmtu And it works on other boxes too 1157805394 M * vrwttnmtu I just wonder if the IPv6 patch can have done something 1157805528 Q * Aiken Ping timeout: 480 seconds 1157805560 M * gdm vrwttnmtu: have you set the user in /etc/munin/plugin-conf.d/munin-node ? 1157805569 M * vrwttnmtu Yep 1157805581 M * gdm what does it say there? 1157805585 M * vrwttnmtu [port*] 1157805585 M * vrwttnmtu user root 1157805605 M * doener it dies at line 64 1157805609 M * vrwttnmtu Should I try adding group root too? 1157805613 M * vrwttnmtu doener, Does it? 1157805614 M * gdm hmm. ok. yeah, maybe 1157805660 M * vrwttnmtu Nope. /var/run/munin/plugin-state/_proc_net_tcp.7051: open: Disk quota exceeded 1157805660 M * vrwttnmtu 2006/09/09-13:40:48 [7048] Plugin "port_993" exited with status 31232. ---- 1157805698 M * doener vrwttnmtu: open(CACHE_OUTPUT, ">$tmpfile") || die "$tmpfile: open: $!\n"; 1157805709 M * vrwttnmtu doener, Yeah, it might do - as you don't have the rest of the munin install 1157805710 M * doener that is line 64 and it perfectly matches the output 1157806012 M * doener vrwttnmtu: could you do the strace thingy? 1157806032 M * vrwttnmtu It could be tricky 1157806042 M * vrwttnmtu Shall I try and strace the master process to a file? 1157806059 M * doener yeah, with the options above (-ffF -o my_strace) 1157806069 M * doener you get one file per child then 1157806080 M * vrwttnmtu Just installing strace 1157806082 M * vrwttnmtu :) 1157806120 M * doener the files get the process' pid as suffix, and as the pid also appears in the error message (the filename) it's easy to get the right one :) 1157806146 M * vrwttnmtu so, strace -ffF -o my_strace /usr/sbin/munin-node ? 1157806173 M * doener yep 1157806184 M * vrwttnmtu Just going to wait for the 5 minute cron to pass, to minimise the junk. 1157806267 M * vrwttnmtu I can't ctrl C it to kill it? 1157806306 M * vrwttnmtu Jebus. 1157806309 M * vrwttnmtu There's a lot of stuff here 1157806368 M * vrwttnmtu open("/proc/net/tcp", O_RDONLY|O_LARGEFILE) = 3 1157806368 M * vrwttnmtu ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, 0xbf8be2bc) = -1 ENOTTY (Inappropriate ioctl for device) 1157806368 M * vrwttnmtu _llseek(3, 0, [0], SEEK_CUR) = 0 1157806368 M * vrwttnmtu fstat64(3, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0 1157806368 M * vrwttnmtu fcntl64(3, F_SETFD, FD_CLOEXEC) = 0 1157806369 M * vrwttnmtu open("/var/run/munin/plugin-state/_proc_net_tcp.14085", O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 0666) = -1 EDQUOT (Disk quota exceeded) 1157806372 M * vrwttnmtu write(2, "/var/run/munin/plugin-state/_pro"..., 75) = 75 1157806374 M * vrwttnmtu close(3) = 0 1157806376 M * vrwttnmtu exit_group(122) 1157806431 Q * ||Cobra|| Remote host closed the connection 1157806682 M * doener still disk quota... with any "munin is confused" reason eliminated 1157806738 A * Hollow_ waves 1157806741 M * Hollow_ bah 1157806743 Q * Hollow_ Remote host closed the connection 1157806748 J * Hollow ~hollow@2001:a60:f026::1 1157806752 M * Hollow better :) 1157806762 M * doener you don't like /nick, ehß 1157806765 M * doener s/ß/?/ 1157806783 M * Hollow well, it doesn't work in #gentoo-dev due to nickserv 1157806796 M * vrwttnmtu doener, It's not disk quota :) 1157806815 M * doener Hollow: +m? 1157806821 M * Hollow ? 1157806826 M * doener vrwttnmtu: well, the kernel thinks so ;) 1157806837 M * vrwttnmtu doener, Well, it's a vserver patched kernel. :) 1157806846 M * doener Hollow: you cannot change your nick if you lack voice in a +m channel IIRC 1157806869 M * doener (at least sth. like that is true on freenode) 1157806877 M * Hollow ah, dunno... it's the fastest anyway to press ctrl+q and alt+f2+k+down+enter 1157806878 M * Hollow ;) 1157806909 M * Hollow since the only app starting with k i use frequently is konversation 1157806922 M * doener Hollow: you seem like an emacs user... how many key do you press simultaneous today? 1157806925 M * Hollow (ok, konqueror, but it has it's own key) 1157806938 M * Hollow no, it's not simultanious 1157806942 M * Hollow alt+f2 1157806943 M * Hollow then k 1157806948 M * Hollow then arrow down 1157806949 M * Hollow then enter 1157806950 M * Hollow ;) 1157806960 M * doener yeah yeah, I know, but you made it look like ;) 1157806978 M * Hollow no, shortcuts invloving more then 2 keys are unusable 1157806981 M * Hollow :) 1157806990 M * Hollow so.. i'm not an emacs user at all :D 1157807038 M * doener daniel_hozac: any idea about -EDQUOT? 1157807082 M * matti Eh. 1157807118 M * vrwttnmtu $ grep EDQUOT patch-2.6.17.* | wc -l 1157807118 M * vrwttnmtu 16 1157807118 M * vrwttnmtu :) 1157807170 M * daniel_hozac vrwttnmtu: what kernel are you using? 1157807182 M * vrwttnmtu 2.6.17.7-ipv6 1157807188 M * vrwttnmtu vs2.1.1-rc26 1157807254 M * daniel_hozac and you are absolutely certain that you do not have any quotas whatsoever setup on that system? 1157807297 M * vrwttnmtu daniel_hozac, I'm pretty much sure. I haven't set any up. The FS is XFS, but there aren't any quotas set up, either on the host, or using whatever mechanisms vserver has in the guests 1157807320 M * vrwttnmtu Hmm 1157807323 M * vrwttnmtu /dev/cciss/c0d0p7 on /home type xfs (rw,noatime,usrquota,grpquota) 1157807332 M * vrwttnmtu It's mounted with usrquota, but I don't use it 1157807333 M * gdm hi, i have another question, if poss... http://paste.linux-vserver.org/347 <== i'm not sure about these errors, whether i can ignore them or if i have to go back and do something different? 1157807378 M * vrwttnmtu # quotastats 1157807378 M * vrwttnmtu quotastats: Error while getting old quota statistics from kernel: Bad address 1157807388 M * doener gdm: not vserver-related and IIRC you as a user can ignore them 1157807404 M * vrwttnmtu # repquota /home/ 1157807404 M * vrwttnmtu repquota: Mountpoint (or device) /home not found. 1157807404 M * vrwttnmtu repquota: Not all specified mountpoints are using quota. 1157807413 M * gdm doener: thanks 1157807414 M * daniel_hozac use the device node instead. 1157807423 M * vrwttnmtu # repquota /dev/cciss/c0d0p7 1157807423 M * vrwttnmtu repquota: Can't find mountpoint for device /dev/cciss/c0d0p7 1157807423 M * vrwttnmtu repquota: No correct mountpoint specified. 1157807423 M * vrwttnmtu repquota: Can't initialize mountpoint scan. 1157807453 M * vrwttnmtu (This is obviously on the host) 1157807453 M * daniel_hozac is that in the guest or on the host? 1157807455 M * vrwttnmtu :) 1157807504 M * vrwttnmtu Nothing in syslog/messages/kern.log on the host either 1157807553 M * daniel_hozac you might want to upgrade to a more recent kernel... we did fix some quota issues on XFS recently, though i don't think it should cause anything like this... 1157807564 M * vrwttnmtu Hmmm :) 1157807570 M * daniel_hozac could you add a simple system("id > /tmp/id"); to the munin script? 1157807595 M * vrwttnmtu To the one that listens on the port, or the plugin? 1157807612 M * doener plugin 1157807620 M * vrwttnmtu One sec 1157807660 M * vrwttnmtu uid=0(root) gid=1006(munin) groups=1006(munin) 1157807688 M * vrwttnmtu Thought I added group root too? 1157807690 M * daniel_hozac did you try setting the group to root as well? 1157807690 M * vrwttnmtu Hmm 1157807696 M * daniel_hozac heh. 1157807707 M * vrwttnmtu # tail /etc/munin/plugin-conf.d/munin-node 1157807707 M * vrwttnmtu [port*] 1157807707 M * vrwttnmtu user root 1157807707 M * vrwttnmtu group root 1157807744 M * vrwttnmtu # user # Set the user to run the plugin as 1157807744 M * vrwttnmtu # group # Set the group to run the plugin as 1157807759 M * vrwttnmtu But the file is 444 anyway? 1157807784 M * vrwttnmtu Is it trying to lock it in some way? 1157807797 M * vrwttnmtu cat /proc/net/tcp works as a normal user 1157807803 M * daniel_hozac what file? it fails to create the one in /var/run. 1157807822 M * daniel_hozac try setting your uid to 0, gid to 1006 and then create a file there. 1157807832 M * vrwttnmtu open("/var/run/munin/plugin-state/_proc_net_tcp.14085", O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 0666) = -1 EDQUOT (Disk quota exceeded) 1157807839 M * vrwttnmtu I think it uses the process ID in that file too 1157807846 M * vrwttnmtu So, unless I can guess it.... 1157807848 M * daniel_hozac indeed. 1157807866 M * vrwttnmtu # ls -la /var/run/munin/plugin-state/ 1157807866 M * vrwttnmtu total 8 1157807866 M * vrwttnmtu drwxr-xr-x 2 munin munin 59 Sep 9 13:18 . 1157807866 M * vrwttnmtu drwxr-xr-x 3 munin root 46 Sep 9 13:55 .. 1157807866 M * vrwttnmtu -rw-r--r-- 1 root root 0 Sep 8 18:37 .keep 1157807867 M * vrwttnmtu -rw-r--r-- 1 root root 2700 Sep 9 13:18 _proc_net_tcp 1157807869 M * vrwttnmtu -rw-r--r-- 1 root root 489 Sep 9 13:18 _proc_net_tcp6 1157807931 M * vrwttnmtu This is bizarre. 1157808044 J * Revelator ~Efnet@62.128.240.117 1157808065 M * vrwttnmtu daniel_hozac, Just tried to remount /home without usrquota,grpquota 1157808069 M * vrwttnmtu It didn't work 1157808074 M * vrwttnmtu And I get this in syslog on the host 1157808077 M * vrwttnmtu Filesystem "cciss/c0d0p7": Disabling barriers, not supported by the underlying device 1157808145 Q * symtab Ping timeout: 480 seconds 1157808234 M * vrwttnmtu And the weird thing is that the script runs fine if I just run it from bash. 1157808236 M * vrwttnmtu # /etc/munin/plugins/port_993 1157808236 M * vrwttnmtu count.value 1 1157808311 J * shedi ~siggi@inferno.lhi.is 1157808450 M * daniel_hozac as root. 1157808454 M * daniel_hozac try python 1157808455 M * daniel_hozac import os 1157808464 M * daniel_hozac os.setgid(1006) 1157808464 M * matti It is the time... for... 1157808470 M * matti call 0xc0ffee 1157808483 M * matti 8-) 1157808487 M * daniel_hozac os.setgroups([1006]) 1157808517 M * vrwttnmtu daniel_hozac, Seems OK 1157808538 M * daniel_hozac os.system("/etc/munin/plugins/port_993") 1157808553 M * vrwttnmtu >>> os.system("/etc/munin/plugins/port_993") 1157808553 M * vrwttnmtu /var/run/munin/plugin-state/_proc_net_tcp.18371: open: Disk quota exceeded 1157808553 M * vrwttnmtu 31232 1157808554 M * vrwttnmtu :) 1157808561 M * daniel_hozac there you go. 1157808585 M * vrwttnmtu But that's just what I'm getting already? 1157808612 M * daniel_hozac yes, but that clearly shows it's the group thing. 1157808617 M * vrwttnmtu Yes, indeed 1157808630 M * vrwttnmtu But why is the kernel reporting disk quota errors? 1157808649 M * daniel_hozac probably you have some group quota set. 1157808663 M * doener (... or a bug...) 1157808724 M * vrwttnmtu # edquota /home/ 1157808724 M * vrwttnmtu No filesystems with quota detected. 1157808742 M * daniel_hozac what about XFS quota? 1157808745 M * vrwttnmtu Yeah 1157808754 M * vrwttnmtu I was just trying to remember how to do that 1157808792 M * vrwttnmtu I don't even have xfs_quota installed 1157808871 M * vrwttnmtu daniel_hozac, Do you think it's that the partition is mounted usrquota,grpquota, even though it's not used? 1157808929 M * daniel_hozac just mounting it with those options shouldn't make it enforce quotas for random groups. 1157808938 M * vrwttnmtu Yep. 1157808974 M * vrwttnmtu Another question is why munin isn't setgiding properly 1157808978 M * vrwttnmtu But that's an aside 1157809041 M * daniel_hozac you could try making the script do setgid(0). 1157809160 M * vrwttnmtu True 1157809197 M * vrwttnmtu What's the call in perl to do that? 1157809219 M * vrwttnmtu Just setgid? 1157809285 M * daniel_hozac i think so, but i'm not a Perl guy. 1157809644 A * Hollow weeps 1157809647 M * Hollow hde: dma_intr: error=0x40 { UncorrectableError } 1157809649 M * Hollow :(( 1157809824 M * daniel_hozac uh oh. 1157809843 M * Hollow indeed 1157809866 M * Hollow well, otoh, i had no hdd crash since two years or so... :p 1157809923 M * vrwttnmtu daniel_hozac, $( = 0; 1157809923 M * vrwttnmtu $) = 0; 1157809924 M * vrwttnmtu ? 1157809926 M * vrwttnmtu I hate perl 1157809946 M * daniel_hozac lol 1157809952 M * vrwttnmtu How messed up is that? 1157809958 M * vrwttnmtu < and > are uid and euid 1157809966 M * vrwttnmtu ( and ) are gid and egid 1157809971 M * vrwttnmtu Brrrr 1157809975 M * daniel_hozac that makes perfect sense... 1157810012 M * vrwttnmtu Well, the script is working now, but that doesn't explain the weird quota error. 1157810014 M * Hollow "§$%&/() 1157810024 M * Hollow ^ Perl 7 1157810024 M * vrwttnmtu God knows what that does 1157810464 M * doener Hollow: I had a "out of boredom"(?) raid1 rebuild yesterday... no error message, just a rebuild... 1157810483 M * Hollow and all your data was lost? 1157810484 M * Hollow :) 1157810541 J * samuel ~samuel@jupe.quebectelephone.com 1157810543 M * samuel hi 1157810549 M * Hollow hi samuel 1157810605 M * samuel one of my host crashed, all vserver came back execpt the DNS... running on slackware 1157810613 M * samuel i've got a defunct init 1157810632 M * doener Hollow: no, luckily not... but that of a friend of mine... partition table lost on one disk, and after a reboot, a rebuild decided to destroy the second disk 1157810674 M * Hollow well, it only happens on hde6... all other partitions seems to work.. so maybe just some sector got destroyed.. 1157810682 M * Hollow will try to move it to another disk.. 1157810777 M * cehteh Hollow: long smart-test or badblocks may fix that 1157810811 M * cehteh (or tell you if the HD is really broken) 1157810824 M * Hollow does badblocks work on xfs? 1157810831 M * Hollow or is it filesystem independent? 1157810844 M * cehteh you can run badblocks in reaonly mode over the raw device 1157810854 M * cehteh even when mounting 1157810860 M * cehteh mounted 1157810901 M * Hollow ok, thanks, i'll try that 1157810913 M * cehteh modern disk firmwares with replace fading sectors when spare sector are still available 1157810921 M * cehteh if not then throw the disk away 1157810949 A * cehteh has a weekly or monthly badblocks scann over all disks in his crontab ;) 1157810960 M * Hollow how long does that take approx.? 1157810966 M * Hollow 10G 1157810979 M * cehteh just read-scan doesnt take long 1157811003 M * cehteh i dont know hof fast your system is 1157811003 M * Hollow ok, if there is soemthing broken, do i have a chance to fix it? 1157811035 M * Hollow i have absolutely nfc about hdd crashes tbh ;) 1157811047 M * Hollow as i said.. happend two years ago the last time 1157811057 M * cehteh if the sectors are just fading away but the firmware can error correct it it will do it .. 1157811071 M * Hollow ah.. i got a first number.. 1157811086 M * cehteh but if there is really some data lost, then then firmware can only schedule this sectors for replacement on the next write 1157811104 M * Hollow well, since it is /var i guess i could live with it ;) 1157811124 M * cehteh and when the badblocks scan is finished you should reformat the disk 1157811146 M * cehteh (with new writing the damaged sectors will be replaced then) 1157811153 M * Hollow ok, sounds like some massive cp -ra ;) 1157811176 M * cehteh and there is the gnu-ddrescue program which can recover quite a lot data from damaged media 1157811201 M * cehteh so ddrescure the whole fs image to a spare drive (that will take long) 1157811237 M * cehteh then dd it back .. and do a fsck .. 1157811248 M * Hollow ok, will do, thanks for your tips :) 1157811264 M * cehteh but you really want some kind of smart check .. if the disk is out of spare sectors then you have lost the game already 1157811294 M * Hollow ok, will have to get the smart tools first 1157811516 M * Hollow does not look too good... already ~20 bad blocks :/ 1157811815 M * samuel hey, any idea about a defunct init process? 1157811863 M * daniel_hozac defunct meaning what? 1157811891 M * samuel when I start the vserver init goes immediatly defunct 1157811898 M * samuel zombie process 1157811912 M * samuel (init inside the vserver) 1157811940 M * Hollow nasty... i had those with vcd too... the process starting init has setup an sigchld handler and died iirc 1157811958 M * samuel I can enter the vserver, but can't communicate with /dev/initctl 1157811978 M * samuel how did you fix that? 1157811997 M * Hollow good question... it was "fixed" after a rewrite of the startup procedure :) 1157812004 M * samuel hmmm 1157812010 M * samuel ok 1157812034 M * daniel_hozac samuel: what kernel are we talking about? 1157812074 M * samuel 2.6.16-16 vs2.0.2, but all others versers (debian) are back 1157812102 M * samuel only the old slackware vserver is not comming back 1157812126 M * samuel slack 8.1 1157812142 M * daniel_hozac different initstyles? 1157812153 M * samuel slack is 'plain' 1157812163 M * daniel_hozac and the debians are sysv? 1157812167 M * daniel_hozac (default) 1157812169 M * samuel yes 1157812186 N * Bertl_zZ Bertl 1157812191 M * Bertl morning folks! 1157812197 M * samuel hi bertl 1157812204 M * Bertl samuel: sysv does not start an init at all 1157812226 M * Bertl samuel: so if you see a defunct init, that would mean your host's init is defunct :) 1157812254 M * samuel hmmm 1157812330 M * Bertl and when init exits, (assuming plain init style) then it should be reaped by the host child_reaper 1157812339 M * samuel everything is working #1, except that slackware vserver 1157812343 M * samuel ok 1157812359 M * samuel (everything was ok before the crash) 1157812368 M * Bertl what crashed? 1157812376 M * samuel hard reboot 1157812393 M * samuel nothing crashed, just an hard reboot 1157812412 M * Bertl ah, so you accidentially hit the reset button or stumbled over the power cord :) 1157812422 M * samuel kind of... :) 1157812430 M * Bertl should not be a big problem though ... 1157812447 M * Bertl and the debian guests restart fine (or did I get that wrong)? 1157812456 M * samuel yes, debian restart 1157812474 M * Bertl slack doesn't come up 1157812479 M * samuel exactly 1157812490 M * Bertl okay, and slack _is_ plain init style, yes? 1157812500 M * samuel yes 1157812557 M * Hollow cehteh: ok, so i ran ide-smart, but i have nfc of its output, i have a couple of Prefailures 1157812579 M * Bertl samuel: okay, I have no idea about the slackware init process, but it becomes a zombie? 1157812585 M * samuel yes 1157812615 Q * samuel_ Remote host closed the connection 1157812615 Q * samuel Remote host closed the connection 1157812637 J * samuel ~samuel@jupe.quebectelephone.com 1157812639 M * samuel sorry 1157812640 M * Bertl wb 1157812647 M * samuel http://pastebin.ca/165121 1157812695 M * Bertl what's your host system? 1157812726 M * Bertl and what does Zs actually mean? 1157812752 M * samuel beta:/etc/vservers/steamship# uname -a 1157812752 M * samuel Linux beta 2.6.16.16-vs2.0.2-rc20 #3 SMP Tue Jul 18 11:40:50 EDT 2006 i686 GNU/Linux 1157812778 M * samuel Z mean zombie, lets see for s 1157812809 M * samuel s The process is a session leader. 1157812826 M * Bertl aha, okay 1157812881 M * Bertl well, it would be quite interesting why that init isn't reaped (it must be a strange behaviour of the host's init process) 1157812907 M * Bertl aside from that, I assume that something _inside_ the slackware guest causes init to terminate 1157812915 M * samuel ok 1157812919 M * Bertl (you might want to look into the logs inside the guest) 1157812946 M * Bertl so actually you are experiencing the combination of two issues here 1157812950 M * transacid [03:43:00] >>> Bertl<<< welcome transacid! << hello! I'm another happy vserver user thx 2 nox ;) 1157812951 M * samuel nothing interesting inside the log.. 1157812971 M * Bertl a) the guest init 'decides' to terminate (because of something inside the guest) 1157813000 M * Bertl b) the dead child is not reaped by the host's init and becomes a zombie 1157813024 M * Bertl transacid: welcome and, good to hear! 1157813258 M * cehteh Hollow: paste me the output .. 1157813307 M * cehteh Hollow: you likely want to make smartctl -t long /dev/hdX and wait until the test finished (in background, it will tell you how long it takes) 1157813330 M * Hollow yep, just found smartctl :) here is ide-smart info: http://paste.linux-vserver.org/353 1157813330 M * cehteh mhm or since you did the badblock do a -t short 1157813347 M * cehteh -t long may take some hours 1157813370 M * cehteh Hollow: is that some ancient debian? 1157813378 M * Hollow no, bleeding-edge gentoo ;) 1157813398 M * cehteh ah ok not smartctl but ide-smart ;) 1157813406 M * cehteh diffrent format 1157813437 M * cehteh well looks ok 1157813509 M * cehteh not very spooky 1157813539 M * Hollow at least all tests passed ;) 1157813611 M * Hollow cehteh: http://paste.linux-vserver.org/354 1157813681 M * samuel Bertl: what do you mean by reaped? 1157813751 M * cehteh Hollow: mv /dev/hde /dev/null 1157813752 M * samuel there is no way to strace -fff the vserver startup process? 1157813784 M * Hollow cehteh: :( really? what does the error mean? bad sectors? hdd going to die really soon now? 1157813805 M * cehteh did you use -t long already? 1157813809 M * Hollow no 1157813819 M * cehteh try that 1157813833 M * cehteh and not that does not mean that the hdd dies soon 1157813842 M * cehteh it means it is already dead 1157813846 M * Hollow 17 minutes for the long test.. 1157813850 M * Hollow oh 1157813872 M * Hollow well, for it being dead, it still works quite "good" 1157813877 M * Hollow ;) 1157813913 M * cehteh well as i saied ddrescue and copying the image back and then a fsck can sometimes resurrect it 1157813927 M * vrwttnmtu Hollow, cehteh - can you run smartctl on mounted drives? 1157813931 M * Hollow ok, i will at least make a backup asap 1157813933 M * vrwttnmtu To do the tests, I mean? 1157813938 M * Hollow vrwttnmtu: yep 1157813938 M * cehteh vrwttnmtu: sure 1157813942 M * vrwttnmtu :) 1157813943 M * vrwttnmtu OK 1157813947 M * vrwttnmtu Even SATA drives? 1157813953 M * cehteh yes 1157813955 M * vrwttnmtu OK 1157813984 M * cehteh smart checks are implemented in the drives firmware if you run them in the normal mode they are completely transparent 1157813988 M * Bertl samuel: reaping is the thing 'init' or 'parent' processes do with child processes when they die 1157814019 M * cehteh there is also a mode for testing where the drives goes offline until the test completes .. but you really dont want that 1157814021 M * samuel ok 1157814029 M * Bertl samuel: well, you _can_ trace the init process (best way to write a wrapper which contains strace -fF, or to attach right after the init startup) 1157814054 M * samuel the init bin inside the vserver? 1157814059 M * vrwttnmtu cehteh, OK, I'm running a short test. Do I run smartctl again to find the results? 1157814067 M * cehteh Hollow: and dont forget the ddrescued image is precious .. dont alter it directly only work with copies of it 1157814095 M * cehteh vrwttnmtu: yes after some time you can view the outcome usually there is a log 1157814102 M * Bertl samuel: either that or with the configuration (which allows for a separate init command) 1157814108 M * samuel good 1157814133 M * cehteh (or some abort like hollow showed) 1157814151 M * Hollow wtf.. 1157814159 M * Hollow my two brnad new sata disks don't support smart 1157814168 M * cehteh Hollow: they do 1157814175 M * Hollow smartctl says no 1157814182 M * Bertl but sata has some problems :) 1157814184 M * cehteh linux libsata doesnt implement it on all controlers 1157814191 M * Hollow ah 1157814192 M * cehteh yes i agree, that sux 1157814207 M * cehteh thats the reason why i rely on badblock instead 1157814217 M * cehteh smart would be better .. iff it works 1157814225 M * Hollow so, if i plan a fileserver, i shouldn't use sata? ;) 1157814254 M * cehteh well not really ... smart isnt that good 1157814255 M * Bertl well, you might just have luck with the scsi interface 1157814262 M * Bertl (and the status page) 1157814279 M * Hollow if scsi disk wouldn't be so expensive.. 1157814284 M * cehteh i'd seen defect drives reporting that they are fine and the opposite 1157814292 M * Bertl Hollow: well, I meant on the sata drives :) 1157814293 M * Hollow which scsi interfaec are your reffering to? 1157814296 M * Hollow sure.. 1157814314 M * Hollow but i mean building a file server with scsi would probably best option ;) 1157814315 M * cehteh and by time i think they will implement the ioctls in libsata too .. 1157814340 M * Bertl ah, nice my promise controller (sata II) is supported with ide-smart 1157814360 M * Hollow indeed... ide-smart shows info for sata disks too here 1157814362 M * cehteh my promise doesnt work with smartctl 1157814364 M * Bertl didn't check before, but now that you folks mentioned it 1157814365 M * Hollow but smartctl doesn't 1157814371 M * cehteh ok 1157814387 M * cehteh well i guess that will be fixed sometime 1157814416 M * cehteh debian has no ide-smart 1157814442 M * Hollow too bad that all my money vanishes for move to berlin, now new disks.. and i wanted to get the new 24" imac :( 1157814464 M * cehteh then dont buy scsi :P 1157814477 M * Hollow somebody needs to invent trees with 100EUR notes as fruit 1157814479 M * Hollow :D 1157814491 A * Bertl is now checking if the sata interface supports hddtemp too ... 1157814519 A * cehteh has a better solution for that: 1157814553 M * cehteh build the computer in a way that it is *always* properly cooled .. then you dont need to look at the temps 1157814563 M * Hollow hehe 1157814576 M * Hollow glad that i have 5 fans in my box 1157814606 M * Bertl cehteh: well, that wont help you with overheating caused by failure (not bad design :) 1157814630 M * cehteh Bertl: with *always* i meant redundant ;) 1157814651 M * Bertl i.e. two separate boxes a 100km away :) 1157814669 M * cehteh yes 1157814708 M * cehteh or really reachable ... i can check if the fans properly working on by desktop when i reach out my hand 1157814734 M * Bertl hddtemp works fine here ... 1157814785 M * cehteh starbase:~# hddtemp /dev/sda 1157814785 M * cehteh /dev/sda: ATA Maxtor 6B200M0: S.M.A.R.T. not available 1157814785 M * cehteh starbase:~# hddtemp /dev/hde 1157814785 M * cehteh /dev/hde: Maxtor 6B200M0: 34 C 1157814787 M * cehteh :( 1157814796 M * Hollow but well.. to replace those 40G in hde with a new 80G one would only cost 35EUR, i guess i could afford that ;) 1157814797 M * cehteh 4 drives .. 2 diffrent controlers 1157814854 M * Bertl cehteh: are you telling me that you have 4 identical disks? 1157814864 M * cehteh yes 1157814867 M * doener /dev/sda: Maxtor 6Y080M0: 50°C 1157814870 M * doener hmm... ouch 1157814909 J * mkhl bairral@200-148-41-18.dsl.telesp.net.br 1157814909 M * doener hm, down to 45° now... strange 1157814926 M * cehteh doener: 55 is limit for most ide drives (you get less than 20% of the lifespan then) ... with 50° you likely still beyond 50% lifespan 1157814958 M * doener it's about 3 years old now 1157814964 M * Hollow 37°-40° good :) 1157814987 M * cehteh doener: well statistical values ... 1157814993 M * Bertl Hollow: did you try: smartctl -d ata -a /dev/sda 1157815014 M * Hollow Bertl: ahh :) 1157815040 M * cehteh imo if a drived worked 3 years under some conditions it will likely work another 3 years .. most hd's either fail within their first year or last quite longer 1157815047 M * Hollow Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error 1157815047 M * Hollow # 1 Extended offline Completed: read failure 40% 4011 2599871 1157815065 M * Hollow after the long test 1157815080 M * cehteh Hollow: replace it 1157815083 M * Bertl it means it is still running ... 1157815084 M * meandtheshell hi folks - all those data can be very fine be recorded and displayed with munin. Munin then displays graphs for different things (the hdd temperature graph looks so funny if you look at it - something like a flat line except when you're compiling a kernel for example) - following link http://www.debianforum.de/forum/viewtopic.php?t=71029 shows some of those graphs 1157815103 M * cehteh or well .. as i saied, try the ddrescue thing first 1157815125 M * Bertl okay, off for now .. back later in the evening ... 1157815129 M * meandtheshell maybe munin is well known here anyway ... :) 1157815132 N * Bertl Bertl_oO 1157815134 M * meandtheshell Bertl: ciao 1157815146 J * node_ node@c-69-143-148-254.hsd1.md.comcast.net 1157815203 M * Hollow can i run ddrescue while disk is mounted? 1157815211 M * cehteh nope 1157815224 M * cehteh well you can ... but the rescued image is not clean 1157815233 M * cehteh maybe you can readonly mount it 1157815237 M * Hollow hrm... i need to do it from livecd then 1157815238 M * cehteh that should work 1157815265 M * meandtheshell Hollow: right - Knoppix for example - mounts hdd read only in default mode 1157815281 M * cehteh ddrescue doesnt care about mounts 1157815295 M * Hollow guess i have to do it at night, don't want to sit here for two hours doing nothing :P 1157815309 M * cehteh but the image you get has a unclean and likely more broken than before filesystem 1157815321 M * meandtheshell cehteh: i know - but it ensures nothing is written to hdd during ddrescue runs 1157815326 M * Hollow especially as i'm using xfs... bad idea ;) 1157815346 A * cehteh would like a rsync option to handle raw-devices 1157815359 M * cehteh rsyncing disk images could be cool 1157815374 M * cehteh then you can start rsyncing it while readwrite mounted 1157815390 M * cehteh and do a final/fast sync with readonly mounted 1157815421 M * meandtheshell cehteh: well DRBD is something like that ... 1157815477 M * meandtheshell but ... sure not as flexible than rsync for example 1157815510 N * meandtheshell meandtheshell_oO 1157815642 M * cehteh DRBD is a online method .. while rsync would do it as batch job .. wich is likely better in some cases 1157815834 Q * olilo Remote host closed the connection 1157815872 J * olilo hiddenserv@tor.noreply.org 1157816133 Q * samuel Quit: My damn controlling terminal disappeared! 1157816889 N * AndrewLe1 AndrewLee 1157817145 M * Hollow hm, running long test on 4 disks makes quite some noise :o 1157817251 M * MooingLemur there's no practical way to run a dhcpd in a guest, right? :P 1157817333 M * Hollow MooingLemur: you need to configure a broadcast address, then it should work 1157817355 M * MooingLemur hmm.. as in 255.255.255.255? 1157817360 M * Hollow yep 1157817370 M * MooingLemur didn't think of that.. thanks 1157817378 Q * node_ Read error: Connection reset by peer 1157817382 M * Hollow your welcome! 1157817466 J * node_ node@c-69-143-148-254.hsd1.md.comcast.net 1157817561 M * daniel_hozac hmm, i thought dhcpd also required CAP_NET_RAW? 1157817584 M * Hollow hm, right... 1157818589 Q * mkhl 1157820070 Q * Zaki Ping timeout: 480 seconds 1157820211 J * Zaki ~Zaki@212.118.110.224 1157820903 Q * vrwttnmtu Remote host closed the connection 1157826412 Q * ruskie Quit: Disconnecting from stoned server. 1157826607 J * ruskie ~ruskie@ruskie.user.oftc.net 1157827122 J * simon ~simon@cable-213.214.39.10.coditel.net 1157827144 M * simon hi 1157827174 M * simon could it be that message-queues don't work inside a standard vserver ? 1157827237 M * daniel_hozac they should, they're even isolated, IIRC. 1157827306 M * simon hmm I'm unable to create queue as root (using a custom c++ app...) 1157827322 M * simon maybe there's something I need to set or enable in order for them to work inside a guest? 1157827384 M * daniel_hozac what syscall are you using? 1157827409 M * simon msgget 1157827427 M * daniel_hozac kernel? 1157827457 M * simon code: if((qid = msgget( ftok(MQ_KEY,0), MSGGET_FLAGS)) == -1) return -1; 1157827468 M * simon kernel: 2.6.16.18-vs2.1.1-rc21 1157827470 M * daniel_hozac and that's the one that fails? 1157827483 M * simon yes that's it 1157827505 M * simon the exact same code works perfectly on an identical non-vserver server.... 1157827541 M * daniel_hozac and what does it return? 1157827582 M * simon on the guest it returns -1 (fails).... on the working server it returns the queue id 1157827630 M * node_ simon: what is errno set to? 1157827701 M * daniel_hozac strace would also be able to tell you. 1157827721 M * simon node_: 13 1157827735 M * node_ lol, run that thru strerror for me, or run strace 1157827738 M * daniel_hozac EACCES. 1157827744 M * simon sorry :-) 1157827779 M * simon Permission denied 1157827790 M * doener simon: check that there is no existing queue with that key (ipcs) 1157827806 M * simon there is no message queue at all 1157827812 M * daniel_hozac how about on the host? 1157827817 M * node_ simon: run ipcs as root, just to verify 1157827826 M * node_ you wont see mq's owned by root otherwise 1157827845 M * simon ooooooooooooooooooooooooh ok ok 1157827856 M * simon on the host I see the msg queue I was looking for :-) 1157827871 M * doener hm, they should be isolated 1157827883 M * simon why can't I see it inside the guest ? it was created inside the guest by root... 1157827887 M * doener ie. keys should not interfere across context boundaries 1157827901 M * simon there seems to be a bug then ? 1157827912 M * simon i'll remove it and start from scratch...sec 1157827940 M * doener simon: could you update to rc31 before I start digging through the code? IIRC the related stuff is not all that nice to read 1157827995 M * simon the msg queue was actually _not_ created by root, but by a user inside the guest. 1157828003 M * doener hm, I should start to think about splitting my lkml mbox... mutt gets kinda slow when opening it 1157828031 M * simon doing a ipcs as root inside the same guest should list the queue though ? 1157828033 M * daniel_hozac simon: are you sure you didn't create it on the host while testing? 1157828069 M * doener daniel_hozac: even if, it would be a bug if it conflicts with the vserver 1157828089 M * daniel_hozac indeed. 1157828108 M * simon I for sure didn't, as this queue including its name is specific to an app I'm testing inside the guest. But somehow it seems to work now.... which means the queue gets created by the user, and as root I can see it via ipcs 1157828124 M * simon doing an ipcs on the host lists the queue as well.... 1157828205 M * simon doener: I can't upgrade to rc31 right now as I'll have to leave soon.... I'll upgrade later.... 1157828234 M * simon thnx all for helping me 1157828265 M * simon bye 1157828266 Q * simon Remote host closed the connection 1157828299 M * doener this ipc stuff is still suspicious to me... I've heard quite a few reports like that, mostly involving dying Apaches... 1157828324 M * daniel_hozac oh yeah. 1157828349 M * daniel_hozac didn't we fix that one? i remember reproducing it. 1157828364 M * doener really? must have missed it... 1157828380 M * daniel_hozac i don't remember if we did fix it... 1157828430 M * daniel_hozac hmm, maybe you should run ipcs as the user to see it inside the guest? 1157828448 M * daniel_hozac (or do guests get CAP_IPC_OWNER by default?) 1157828527 M * doener simon is already gone ;) 1157828537 M * daniel_hozac i know ;) 1157828553 M * daniel_hozac just thinking out loud. 1157828557 M * doener and as I interpreted it, he can now see the queue as root on the host and in the guest, not sure if he sees it as the user 1157828581 M * daniel_hozac yeah, true. 1157828609 M * doener but keep that CAP_IPC_OWNER in mind... maybe that's related to it (wrong check to skip queues) 1157828823 M * doener *sniff* soooo many rejects with .18-rc6 1157828873 M * daniel_hozac yeah, way too many for my taste :) 1157828963 M * doener almost all were trivial stuff, but time consuming... 1157828973 M * doener (well, those I've fixed) 1157829281 J * Piet hiddenserv@tor.noreply.org 1157829387 Q * Revelator Read error: Connection reset by peer 1157829731 M * doener shouldn't have said that... fs/proc/base.c has lots of real changes :( 1157829869 M * matti They added more bugs? 1157829869 M * matti ;] 1157830039 M * matti .12 have some serious deadlock fix for raid1. 1157832086 M * daniel_hozac just RAID1? 1157833214 Q * fosco hydrogen.oftc.net iridium.oftc.net 1157833215 Q * kaner hydrogen.oftc.net iridium.oftc.net 1157833215 Q * FloodServ hydrogen.oftc.net iridium.oftc.net 1157833215 Q * ruskie hydrogen.oftc.net iridium.oftc.net 1157833215 Q * node_ hydrogen.oftc.net iridium.oftc.net 1157833215 Q * hap hydrogen.oftc.net iridium.oftc.net 1157833215 Q * click hydrogen.oftc.net iridium.oftc.net 1157833215 Q * mugwump hydrogen.oftc.net iridium.oftc.net 1157833215 Q * micah hydrogen.oftc.net iridium.oftc.net 1157833215 Q * bogus hydrogen.oftc.net iridium.oftc.net 1157833215 Q * [PUPPETS]Gonzo hydrogen.oftc.net iridium.oftc.net 1157833215 Q * tokkee hydrogen.oftc.net iridium.oftc.net 1157833215 Q * mcp hydrogen.oftc.net iridium.oftc.net 1157833215 Q * Greek0 hydrogen.oftc.net iridium.oftc.net 1157833215 Q * shedi hydrogen.oftc.net iridium.oftc.net 1157833215 Q * romke hydrogen.oftc.net iridium.oftc.net 1157833215 Q * tso hydrogen.oftc.net iridium.oftc.net 1157833215 Q * s0undt3ch hydrogen.oftc.net iridium.oftc.net 1157833215 Q * harry hydrogen.oftc.net iridium.oftc.net 1157833215 Q * michal_ hydrogen.oftc.net iridium.oftc.net 1157833215 Q * anonc hydrogen.oftc.net iridium.oftc.net 1157833215 Q * derjohn hydrogen.oftc.net iridium.oftc.net 1157833215 Q * ebiederm hydrogen.oftc.net iridium.oftc.net 1157833215 Q * lylix hydrogen.oftc.net iridium.oftc.net 1157833215 Q * Belu_zZz hydrogen.oftc.net iridium.oftc.net 1157833298 M * waldi matti: where? 1157833305 J * ruskie ~ruskie@ruskie.user.oftc.net 1157833305 J * node_ node@c-69-143-148-254.hsd1.md.comcast.net 1157833305 J * shedi ~siggi@inferno.lhi.is 1157833305 J * romke ~romke@acrux.romke.net 1157833305 J * tso ~tso@196-019.adsl.pool.ew.hu 1157833305 J * s0undt3ch ~s0undt3ch@bl7-240-146.dsl.telepac.pt 1157833305 J * harry ~harry@d54C2508C.access.telenet.be 1157833305 J * kaner kaner@strace.org 1157833305 J * michal_ ~michal@www.rsbac.org 1157833305 J * fosco fosco@konoha.devnullteam.org 1157833305 J * mugwump ~samv@watts.utsl.gen.nz 1157833305 J * micah ~micah@micah.riseup.net 1157833305 J * FloodServ services@services.oftc.net 1157833305 J * [PUPPETS]Gonzo gonzo@langweiligneutral.deswahnsinns.de 1157833305 J * hap ~penso@212.27.33.226 1157833305 J * tokkee tokkee@casella.verplant.org 1157833305 J * mcp ~hightower@wolk-project.de 1157833305 J * bogus ~bogusano@fengor.net 1157833305 J * Greek0 ~greek0@85.255.145.201 1157833305 J * click click@ti511110a080-2980.bb.online.no 1157833349 J * anonc ~anonc@staffnet.internode.com.au 1157833349 J * derjohn ~derjohn@80.69.37.19 1157833349 J * ebiederm ~eric@ebiederm.dsl.xmission.com 1157833349 J * lylix ~eric@dynamic-acs-24-154-53-234.zoominternet.net 1157833349 J * Belu_zZz B.Lukas@mail.openvcp.org 1157833358 M * matti Where what? 1157833582 M * waldi .12 only touches the dm mirroring code 1157834531 M * daniel_hozac doener: hmm, the IPC stuff looks pretty broken... 1157834578 M * daniel_hozac i can't see the queue as root in the guest (who created it), on the host, or in the spectator context. 1157834608 M * daniel_hozac (on 2.1.1-rc31.ipv6) 1157834628 M * daniel_hozac root on the guest can remove it though. 1157834649 M * daniel_hozac as well as root on the host. 1157834936 M * daniel_hozac http://people.linux-vserver.org/~dhozac/t/tests/test-ipc.c is what i used to test. 1157834982 M * daniel_hozac (./test-ipc -c -p /tmp/blah -i 502 and ./test-ipc -d -q to be exact) 1157835017 M * daniel_hozac and then ipcs to show them. 1157836748 Q * meandtheshell_oO Quit: bye bye ... 1157837306 M * matti Uhhh. 1157837321 M * matti I just recorded voice sample for my future employer. 1157837348 M * matti Interview through Internet r00x ;p 1157837350 M * matti Hehehe. 1157837469 J * serving ~serving@86.108.80.243 1157837485 M * serving hi all :) 1157837496 M * serving I made lsof in a vserver and I can see files listed as open that were accessed last about 2 years ago. 1157837511 M * serving Is there a way to remove such files from lsof output? Why are they listed to begin with ? 1157837511 M * serving :) 1157837628 Q * Loki|muh Ping timeout: 480 seconds 1157837638 M * daniel_hozac hmm? 1157837663 M * derjohn serving, hi :) 1157837737 J * Loki|muh loki@satanix.de 1157837754 M * derjohn serving, the are probably still open ... try fuser to see from which process 1157837827 M * derjohn daniel_hozac, the incrementa patch from .11 to .12 does not apply clean here on dm-stuff. does the vserver patch touch dm in any way?? 1157837960 M * serving derjohn: hi there :D thanx .. I can see the process .. httpd 1157838012 M * daniel_hozac derjohn: yes. 1157838090 M * daniel_hozac derjohn: the dm devices are xid tagged. 1157838097 M * derjohn is there an updated vser2.1.1 out ? is the primary patch src still 13thfloor or newstyle-wiki? 1157838114 M * daniel_hozac not yet. 1157838126 M * daniel_hozac the conflicts weren't that hard to fix though. 1157838137 M * derjohn hm, tagged? for what reason? 1157838150 M * derjohn i'll do so, i see just "oneliners" 1157838152 M * daniel_hozac same reason loopback devices are tagged, i suppose. 1157838172 M * daniel_hozac i.e. limiting devices to the guest they were mounted in. 1157838185 M * derjohn ah .... yes! dm is not only used for raid, ok, thats makes it clear 1157838219 M * derjohn (hdX devides are not tagged, arent they?) 1157838224 M * derjohn *devices 1157838351 M * daniel_hozac nope. 1157838504 M * daniel_hozac derjohn: i've got a patch for 2.6.17.13 if you want it. 1157838686 M * derjohn daniel_hozac, devel ? 1157838693 M * daniel_hozac right. 1157838702 M * daniel_hozac stable was just some offsets. 1157838730 M * derjohn I did complile stable for months now, as I need the capa masking ... 1157838742 M * daniel_hozac hehe. 1157838748 M * derjohn The patch will be gladly accepted ! 1157838776 M * daniel_hozac http://people.linux-vserver.org/~dhozac/p/k/patch-2.6.17.13-vs2.1.1-rc31.diff 1157838779 M * derjohn maybe put in on you helios dir? 1157838783 M * derjohn race ;) 1157840017 J * Viper0482 ~Viper0482@p54976828.dip.t-dialin.net 1157840022 Q * Viper0482 1157840052 J * Viper0482 ~Viper0482@p54976828.dip.t-dialin.net 1157840076 Q * Viper0482 1157840405 J * Revelator ~Efnet@62.128.240.117 1157841344 M * doener daniel_hozac: well, I'll give the code another look, but the last time it all looked good to me... but it's not that nice to read, so maybe I'm just dumb ;) 1157841478 Q * bonbons Quit: Leaving 1157841483 M * daniel_hozac to be honest, i don't even see how ipcs works. 1157842330 M * daniel_hozac that's interesting, /proc/sysvipc/msg shows the queue (but only inside the guest). 1157842396 M * doener ok, so I didn't fail at checking that part... I just though that it is sth. different ;) 1157842415 M * doener (just figured out that it was proc related...) 1157842541 M * daniel_hozac ah, i have privacy enabled in that kernel, that explains why it's only visible inside the guest. 1157843008 Q * shedi Quit: Leaving 1157843369 J * shedi ~siggi@inferno.lhi.is 1157844037 M * matti :-) 1157844816 M * daniel_hozac the IPC stuff all looks fine... i don't see what makes ipcs fail. 1157844927 M * doener daniel_hozac: I tend towards the MSG_INFO... 1157844933 M * doener ie. that there's some bug 1157844951 M * daniel_hozac but are we changing anything at all in that path? 1157844979 M * daniel_hozac or is it just making dumb assumptions? 1157844998 M * doener nfc 1157845086 M * daniel_hozac hmm, that's progress. my strace now shows MSG_INFO returning EACCES. 1157845145 M * daniel_hozac ugh, MSG_STAT, of course. 1157845158 M * doener ok, was starting to wonder how that works ;) 1157845158 A * daniel_hozac is starting to get a bit too tired. 1157845163 M * daniel_hozac yeah. 1157845278 J * Viper0482 ~Viper0482@p54976828.dip.t-dialin.net 1157845281 Q * Viper0482 1157845870 M * daniel_hozac ah, the lack of CAP_IPC_OWNER and proper permissions for the message queue is what causes my behaviour. so not a bug, just PEBKAC ;) 1157845909 M * doener vserver root has no CAP_IPC_OWNER? 1157845972 M * daniel_hozac nope. 1157846078 M * doener hm, I wonder why, there should be zero problems with it 1157846106 M * daniel_hozac isn't the IPC isolation semi-recent? 1157846112 M * doener it's even pretty easy to check that as CAP_IPC_OWNER is used exactly once, in ipcperms 1157846121 M * doener I don't know 1157846161 M * daniel_hozac nah, 2.0 has it. 1157846221 M * daniel_hozac hmm, even 1.2.11-rc1 has it 1157846282 M * daniel_hozac so yeah, i think that should be added to the default set.