1193184194 P * Yvo 1193185500 J * rorem- ~roremtank@bzq-219-46-202.isdn.bezeqint.net 1193188028 M * onox does somebody knows the difference between mealy and moore? 1193188538 Q * onox Quit: zzzz 1193188827 J * friendly12345 ~friendly@ppp121-44-230-192.lns2.mel4.internode.on.net 1193193620 Q * mnemoc Ping timeout: 480 seconds 1193193696 Q * fatgoose Quit: fatgoose 1193194126 J * mnemoc ~amery@kilo105.server4you.de 1193195417 J * fatgoose ~samuel@132.203.202.104 1193198655 Q * fatgoose Ping timeout: 480 seconds 1193198922 J * dsoul_ darksoul@vice.ii.uj.edu.pl 1193199031 J * ruskie_ ruskie@goatse.co.uk 1193199047 J * _mcp ~hightower@wolk-project.de 1193199085 Q * ruskie Read error: Connection reset by peer 1193199108 Q * baldy Read error: Connection reset by peer 1193199109 Q * Bertl_zZ Read error: Connection reset by peer 1193199109 Q * Guest304 Remote host closed the connection 1193199110 Q * wenchien Ping timeout: 480 seconds 1193199113 Q * phedny Remote host closed the connection 1193199117 Q * transacid Remote host closed the connection 1193199117 J * Bertl_zZ herbert@IRC.13thfloor.at 1193199119 J * phedny_ ~mark@ip56538143.direct-adsl.nl 1193199120 J * eviljonny ~eviljonny@loki.eviljonnys.com 1193199121 J * baldy baldy@brain.servercrew.de 1193199121 Q * eviljonn1 Read error: Connection reset by peer 1193199122 Q * pusling Read error: Connection reset by peer 1193199137 J * transacid ~transacid@transacid.de 1193199146 Q * mnemoc cation.oftc.net kilo.oftc.net 1193199146 Q * mcp cation.oftc.net kilo.oftc.net 1193199146 Q * phreak`` cation.oftc.net kilo.oftc.net 1193199146 Q * bragon cation.oftc.net kilo.oftc.net 1193199146 Q * opuk cation.oftc.net kilo.oftc.net 1193199146 Q * snooze cation.oftc.net kilo.oftc.net 1193199146 Q * [Guy] cation.oftc.net kilo.oftc.net 1193199146 Q * _Medivh cation.oftc.net kilo.oftc.net 1193199146 Q * Adrinael_ cation.oftc.net kilo.oftc.net 1193199146 Q * rob-84x^ cation.oftc.net kilo.oftc.net 1193199146 Q * sladen cation.oftc.net kilo.oftc.net 1193199146 Q * nospoonuser cation.oftc.net kilo.oftc.net 1193199146 Q * ag- cation.oftc.net kilo.oftc.net 1193199146 Q * danman cation.oftc.net kilo.oftc.net 1193199146 Q * matti cation.oftc.net kilo.oftc.net 1193199146 Q * daniel_hozac cation.oftc.net kilo.oftc.net 1193199146 Q * dsoul cation.oftc.net kilo.oftc.net 1193199151 N * _mcp mcp 1193199203 N * ruskie_ ruskie 1193199210 J * mnemoc ~amery@kilo105.server4you.de 1193199210 J * phreak`` ~phreak``@deimos.barfoo.org 1193199210 J * bragon ~bragon@2001:7a8:aa58::1 1193199210 J * opuk ~kupo@c213-100-138-228.swipnet.se 1193199210 J * snooze ~o@1-1-4-40a.gkp.gbg.bostream.se 1193199210 J * [Guy] ~korn@elan.rulez.org 1193199210 J * _Medivh ck@paradise.by.the.dashboardlight.de 1193199210 J * Adrinael_ adrinael@rid7.kyla.fi 1193199210 J * rob-84x^ rob@submarine.ath.cx 1193199210 J * sladen paul@starsky.19inch.net 1193199210 J * nospoonuser ~nospoonus@n18-241.dsl.vianetworks.de 1193199210 J * ag- ~ag@fedaykin.roxor.cx 1193199210 J * danman danman@eliza.wigner.bme.hu 1193199210 J * matti matti@acrux.romke.net 1193199210 J * daniel_hozac ~daniel@c-051472d5.08-230-73746f22.cust.bredbandsbolaget.se 1193199210 J * dsoul darksoul@vice.ii.uj.edu.pl 1193199210 J * Guest370 ~ensc@www.sigma-chemnitz.de 1193199255 Q * dsoul Ping timeout: 480 seconds 1193199961 J * snooze_ ~o@1-1-4-40a.gkp.gbg.bostream.se 1193200070 Q * snooze Ping timeout: 480 seconds 1193200070 Q * FireEgl Read error: Connection reset by peer 1193200085 J * FireEgl FireEgl@4.0.0.0.1.0.0.0.c.d.4.8.0.c.5.0.1.0.0.2.ip6.arpa 1193202651 J * JonB ~NoSuchUse@kg1-98.kollegiegaarden.dk 1193203176 Q * FloodServ charon.oftc.net synthon.oftc.net 1193203176 Q * friendly12345 charon.oftc.net synthon.oftc.net 1193203176 Q * Aiken charon.oftc.net synthon.oftc.net 1193203176 Q * mattzerah charon.oftc.net synthon.oftc.net 1193203176 Q * dowdle charon.oftc.net synthon.oftc.net 1193203176 Q * fb charon.oftc.net synthon.oftc.net 1193203176 Q * Johnsie charon.oftc.net synthon.oftc.net 1193203176 Q * quasisane charon.oftc.net synthon.oftc.net 1193203176 Q * mire charon.oftc.net synthon.oftc.net 1193203176 Q * bored2sleep charon.oftc.net synthon.oftc.net 1193203176 Q * Hollow charon.oftc.net synthon.oftc.net 1193203176 Q * mountie charon.oftc.net synthon.oftc.net 1193203176 Q * brc charon.oftc.net synthon.oftc.net 1193203176 Q * tam_ charon.oftc.net synthon.oftc.net 1193203176 Q * hardwire charon.oftc.net synthon.oftc.net 1193203176 Q * besonen_mobile_ charon.oftc.net synthon.oftc.net 1193203176 Q * micah charon.oftc.net synthon.oftc.net 1193203176 Q * rorem- charon.oftc.net synthon.oftc.net 1193203176 Q * hallyn_ charon.oftc.net synthon.oftc.net 1193203176 Q * SammyWork charon.oftc.net synthon.oftc.net 1193203176 Q * misc-- charon.oftc.net synthon.oftc.net 1193203176 Q * AndrewLee charon.oftc.net synthon.oftc.net 1193203176 Q * dilinger charon.oftc.net synthon.oftc.net 1193203176 Q * Skram charon.oftc.net synthon.oftc.net 1193203176 Q * Supaplex charon.oftc.net synthon.oftc.net 1193203176 Q * MooingLemur charon.oftc.net synthon.oftc.net 1193203176 Q * m_stone charon.oftc.net synthon.oftc.net 1193203176 Q * JonB charon.oftc.net synthon.oftc.net 1193203176 Q * danman charon.oftc.net synthon.oftc.net 1193203176 Q * nospoonuser charon.oftc.net synthon.oftc.net 1193203176 Q * sladen charon.oftc.net synthon.oftc.net 1193203176 Q * rob-84x^ charon.oftc.net synthon.oftc.net 1193203176 Q * _Medivh charon.oftc.net synthon.oftc.net 1193203176 Q * [Guy] charon.oftc.net synthon.oftc.net 1193203176 Q * opuk charon.oftc.net synthon.oftc.net 1193203176 Q * bragon charon.oftc.net synthon.oftc.net 1193203176 Q * mnemoc charon.oftc.net synthon.oftc.net 1193203176 Q * matti charon.oftc.net synthon.oftc.net 1193203176 Q * Adrinael_ charon.oftc.net synthon.oftc.net 1193203176 Q * phreak`` charon.oftc.net synthon.oftc.net 1193203176 Q * daniel_hozac charon.oftc.net synthon.oftc.net 1193203176 Q * ag- charon.oftc.net synthon.oftc.net 1193203176 Q * snooze_ charon.oftc.net synthon.oftc.net 1193203176 Q * baldy charon.oftc.net synthon.oftc.net 1193203176 Q * eviljonny charon.oftc.net synthon.oftc.net 1193203176 Q * Guest370 charon.oftc.net synthon.oftc.net 1193203176 Q * Bertl_zZ charon.oftc.net synthon.oftc.net 1193203176 Q * ruskie charon.oftc.net synthon.oftc.net 1193203176 Q * dsoul_ charon.oftc.net synthon.oftc.net 1193203176 Q * tokkee charon.oftc.net synthon.oftc.net 1193203176 Q * FireEgl charon.oftc.net synthon.oftc.net 1193203176 Q * meebey charon.oftc.net synthon.oftc.net 1193203176 Q * nou charon.oftc.net synthon.oftc.net 1193203176 Q * transacid charon.oftc.net synthon.oftc.net 1193203176 Q * phedny_ charon.oftc.net synthon.oftc.net 1193203176 Q * mcp charon.oftc.net synthon.oftc.net 1193203176 Q * eSa| charon.oftc.net synthon.oftc.net 1193203176 Q * ensc charon.oftc.net synthon.oftc.net 1193203176 Q * yang charon.oftc.net synthon.oftc.net 1193203176 Q * wibble charon.oftc.net synthon.oftc.net 1193203176 Q * Chr0nicles charon.oftc.net synthon.oftc.net 1193203176 Q * mjt charon.oftc.net synthon.oftc.net 1193203176 Q * alex__ charon.oftc.net synthon.oftc.net 1193203176 Q * virtuoso charon.oftc.net synthon.oftc.net 1193203176 Q * eyck_ charon.oftc.net synthon.oftc.net 1193203176 Q * baggins charon.oftc.net synthon.oftc.net 1193203176 Q * ard charon.oftc.net synthon.oftc.net 1193203176 Q * grobie charon.oftc.net synthon.oftc.net 1193203176 Q * ex charon.oftc.net synthon.oftc.net 1193203176 Q * click_ charon.oftc.net synthon.oftc.net 1193203176 Q * maddoc charon.oftc.net synthon.oftc.net 1193203176 Q * sid3windr charon.oftc.net synthon.oftc.net 1193203176 Q * duckx charon.oftc.net synthon.oftc.net 1193203176 Q * djbclark charon.oftc.net synthon.oftc.net 1193203176 Q * zLinux charon.oftc.net synthon.oftc.net 1193203176 Q * bzed charon.oftc.net synthon.oftc.net 1193203176 Q * Loki|muh charon.oftc.net synthon.oftc.net 1193203176 Q * nebuchad` charon.oftc.net synthon.oftc.net 1193203176 Q * vasko charon.oftc.net synthon.oftc.net 1193203236 J * JonB ~NoSuchUse@kg1-98.kollegiegaarden.dk 1193203236 J * FireEgl FireEgl@4.0.0.0.1.0.0.0.c.d.4.8.0.c.5.0.1.0.0.2.ip6.arpa 1193203236 J * snooze_ ~o@1-1-4-40a.gkp.gbg.bostream.se 1193203236 J * Guest370 ~ensc@www.sigma-chemnitz.de 1193203236 J * daniel_hozac ~daniel@c-051472d5.08-230-73746f22.cust.bredbandsbolaget.se 1193203236 J * matti matti@acrux.romke.net 1193203236 J * danman danman@eliza.wigner.bme.hu 1193203236 J * ag- ~ag@fedaykin.roxor.cx 1193203236 J * nospoonuser ~nospoonus@n18-241.dsl.vianetworks.de 1193203236 J * sladen paul@starsky.19inch.net 1193203236 J * rob-84x^ rob@submarine.ath.cx 1193203236 J * Adrinael_ adrinael@rid7.kyla.fi 1193203236 J * _Medivh ck@paradise.by.the.dashboardlight.de 1193203236 J * [Guy] ~korn@elan.rulez.org 1193203236 J * opuk ~kupo@c213-100-138-228.swipnet.se 1193203236 J * bragon ~bragon@2001:7a8:aa58::1 1193203236 J * phreak`` ~phreak``@deimos.barfoo.org 1193203236 J * mnemoc ~amery@kilo105.server4you.de 1193203236 J * transacid ~transacid@transacid.de 1193203236 J * baldy baldy@brain.servercrew.de 1193203236 J * eviljonny ~eviljonny@loki.eviljonnys.com 1193203236 J * phedny_ ~mark@ip56538143.direct-adsl.nl 1193203236 J * Bertl_zZ herbert@IRC.13thfloor.at 1193203236 J * mcp ~hightower@wolk-project.de 1193203236 J * ruskie ruskie@goatse.co.uk 1193203236 J * dsoul_ darksoul@vice.ii.uj.edu.pl 1193203236 J * friendly12345 ~friendly@ppp121-44-230-192.lns2.mel4.internode.on.net 1193203236 J * rorem- ~roremtank@bzq-219-46-202.isdn.bezeqint.net 1193203236 J * mire ~mire@77-105-22-149.adsl-3.sezampro.yu 1193203236 J * Aiken ~james@ppp121-45-206-11.lns1.bne1.internode.on.net 1193203236 J * eSa| ~esa@ip-87-238-2-45.adsl.cheapnet.it 1193203236 J * ensc ~irc-ensc@p54B4D6A7.dip.t-dialin.net 1193203236 J * hallyn_ ~xa@adsl-75-0-157-26.dsl.chcgil.sbcglobal.net 1193203236 J * yang yang@yang.netrep.oftc.net 1193203236 J * tokkee tokkee@ssh.faui2k3.org 1193203236 J * dowdle ~dowdle@scott.coe.montana.edu 1193203236 J * SammyWork ~sammy@anhedonia.sammy.net 1193203236 J * wibble wibble@vortex.ukshells.co.uk 1193203236 J * Chr0nicles ~Primus_@a82-93-138-63.adsl.xs4all.nl 1193203236 J * mjt ~mjt@81.13.94.2 1193203236 J * alex__ ~joe@62-249-237-101.no-dns-yet.enta.net 1193203236 J * misc-- ~misc@122.2.127.232 1193203236 J * virtuoso ~s0t0na@pppoe-234.58.110.89-adsl.spbnit.ru 1193203236 J * eyck_ ~eyck@nat.nowanet.pl 1193203236 J * fb fback@red.fback.net 1193203236 J * baggins ~baggins@kenny.mimuw.edu.pl 1193203236 J * ard ~ard@gw-tweakb16.kwaak.net 1193203236 J * grobie ~grobie@master.schnuckelig.eu 1193203236 J * ex ex@valis.net.pl 1193203236 J * click_ click@ti511110a080-4620.bb.online.no 1193203236 J * maddoc maddoc@social.ostruktur.com 1193203236 J * sid3windr luser@bastard-operator.from-hell.be 1193203236 J * AndrewLee ~andrew@flat.iis.sinica.edu.tw 1193203236 J * duckx ~Duck@tox.dyndns.org 1193203236 J * bored2sleep ~bored2sle@66.111.53.150 1193203236 J * dilinger ~dilinger@mail.queued.net 1193203236 J * Hollow ~hollow@proteus.croup.de 1193203236 J * mountie ~mountie@trb229.travel-net.com 1193203236 J * djbclark dclark@opensysadmin.com 1193203236 J * brc bruce@megarapido.cliquerapido.com.br 1193203236 J * FloodServ services@services.oftc.net 1193203236 J * nou Chaton@causse.larzac.fr.eu.org 1193203236 J * zLinux ~zLinux@88.213.26.14 1193203236 J * mattzerah ~matt@121.50.219.188 1193203236 J * Johnsie ~jdlewis@c-67-163-142-234.hsd1.pa.comcast.net 1193203236 J * Skram ~mark@HERCULES.sentiensystems.net 1193203236 J * tam_ ~tam@gw.nettam.com 1193203236 J * Supaplex supaplex@166-70-62-194.ip.xmission.com 1193203236 J * quasisane ~sanep@c-76-118-191-64.hsd1.nh.comcast.net 1193203236 J * meebey meebey@booster.qnetp.net 1193203236 J * hardwire ~bip@rdbck-3588.palmer.mtaonline.net 1193203236 J * bzed ~bzed@devel.recluse.de 1193203236 J * besonen_mobile_ ~besonen_m@71-220-227-56.eugn.qwest.net 1193203236 J * Loki|muh loki@satanix.de 1193203236 J * nebuchad` ~nebu@zion.asgardr.info 1193203236 J * micah ~micah@micah.riseup.net 1193203236 J * vasko ~vasko@unreal.rainside.sk 1193203236 J * MooingLemur ~troy@shells195.pinchaser.com 1193203236 J * m_stone ~mstone@teach.laptop.org 1193203274 Q * djbclark Remote host closed the connection 1193203284 J * djbclark dclark@opensysadmin.com 1193203285 Q * meebey Ping timeout: 480 seconds 1193203465 Q * rob-84x^ Ping timeout: 480 seconds 1193203578 J * meebey meebey@booster.qnetp.net 1193203584 J * larsivi ~larsivi@101.84-48-201.nextgentel.com 1193203675 Q * daniel_hozac Ping timeout: 480 seconds 1193203700 Q * mnemoc Ping timeout: 480 seconds 1193203746 M * misc-- I've got a weird problem on my guest. I have apache installed and started and listning on its assigned IP but if I telnet to port 80 from another host, it says no route to host (which usually means the host is down). If I do the same thing to port 22, it works. And, port 80 is not in use on my host machine. Any ideas? 1193203848 M * misc-- same deal with samba. It's only listning on the real IP but telnet from another host to the samba port, I get no route to host. However telnetting to the IP from the guest itself works. It's only from other hosts that it doesn't. Strange because 22 is OK 1193203854 Q * mattzerah synthon.oftc.net scorpio.oftc.net 1193203854 Q * friendly12345 synthon.oftc.net scorpio.oftc.net 1193203854 Q * Aiken synthon.oftc.net scorpio.oftc.net 1193204010 Q * nospoonuser Ping timeout: 480 seconds 1193204054 J * friendly12345 ~friendly@ppp121-44-230-192.lns2.mel4.internode.on.net 1193204054 J * Aiken ~james@ppp121-45-206-11.lns1.bne1.internode.on.net 1193204054 J * mattzerah ~matt@121.50.219.188 1193204338 J * mnemoc ~amery@kilo105.server4you.de 1193204398 J * nospoonuser ~nospoonus@n18-241.dsl.vianetworks.de 1193204544 J * daniel_hozac ~daniel@c-051472d5.08-230-73746f22.cust.bredbandsbolaget.se 1193204621 N * snooze_ snooze 1193205418 M * misc-- I've got a weird problem on my guest. I have apache installed and started and listning on its assigned IP but if I telnet to port 80 from another host, it says no route to host (which usually means the host is down). If I do the same thing to port 22, it works. And, port 80 is not in use on my host machine. Any ideas? 1193205423 M * misc-- oops 1193205427 M * misc-- sorry didn't mean to repeat 1193205496 M * misc-- :w 1193205500 M * misc-- ugh 1193205667 M * JonB misc--: another host? on the same network 1193205673 M * JonB or on the same machine? 1193205806 M * misc-- hmm no there is only just one guest running at the moment. The host has no conflicting services that are running (no services running on all interfaces) 1193205854 M * JonB do you have tcpdump on the vserver root/host? 1193205863 M * misc-- it's strange because the telnet to the guest works for port 22 but not 80 1193205877 M * misc-- hmm good idea 1193205883 M * misc-- yeah I do. I'll see if I can see traffic going to it 1193205942 M * misc-- 16:05:27.104827 IP 192.168.1.206.46427 > 192.168.1.1.80: S 3530894034:3530894034(0) win 5840 1193205960 M * misc-- 1.1 is the guest. 1.206 is an external host. So that looks fine. The guest itself can see 206 as well 1193205969 M * misc-- external PC rather 1193206017 M * JonB misc--: well then run tcpdump while doing something from the external host 1193206067 M * misc-- what other things should I be doing from the external host? This is just another machine on the network that is trying to get to it 1193206097 M * JonB misc--: well, maybe run tcpdump on the external pc 1193206099 J * DavidS ~david@193.170.138.34 1193206103 M * JonB and make sure the replies get back 1193206116 M * JonB but i've gotta go now. Good luck with your problem 1193206118 Q * JonB Quit: This computer has gone to sleep 1193206122 M * misc-- I don't think the replies are getting back because that was the only line when I telnet to it, but I'll check anyway 1193206127 M * misc-- ok no worries thanks for the suggestions 1193206131 M * misc-- too late 1193206333 M * misc-- ughhhh... firewall was rejecting packets on the host. Can't believe it 1193206490 J * virtuoso_ ~s0t0na@ppp91-122-26-176.pppoe.avangard-dsl.ru 1193206863 Q * virtuoso Read error: Connection reset by peer 1193207141 Q * ruskie Quit: Changing server... 1193207145 J * ruskie ruskie@goatse.co.uk 1193208401 Q * larsivi Quit: Konversation terminated! 1193208474 J * JonB ~NoSuchUse@kg1-98.kollegiegaarden.dk 1193208602 N * ensc Guest390 1193208611 J * ensc ~irc-ensc@p54B4D94C.dip.t-dialin.net 1193208722 Q * Guest390 Ping timeout: 480 seconds 1193210148 J * pusling pusling@77.75.162.71 1193211034 J * dna ~dna@241-240-dsl.kielnet.net 1193211522 J * larsivi ~larsivi@85.221.53.194 1193211539 Q * Red_Devil Ping timeout: 480 seconds 1193211844 J * Red_Devil ~red@lounge.datux.nl 1193213101 J * gebura ~gebura@77.192.186.197 1193213296 M * gebura hi 1193213769 M * JonB hi? 1193213844 M * gebura ~= hello 1193213892 J * Piet ~piet@tor.noreply.org 1193214689 J * pmenier ~pme@LNeuilly-152-22-72-5.w193-251.abo.wanadoo.fr 1193214692 N * Bertl_zZ Bertl_oO 1193216115 J * Yvo ~yvonne@91.64.217.106 1193216288 M * Yvo good morning! 1193216394 M * misc-- gday 1193216966 M * Hollow daniel_hozac, Bertl_oO: do you still have the address of the previous ML owner? i still get a huge mail every day, asking me to approve 1230 messages to the list from the last 3 years .. *narf* 1193217220 M * sid3windr Martin List-Petersen - martin at list-petersen dot dk 1193217245 M * Hollow thanks 1193218183 J * lilalinux ~plasma@dslb-084-058-221-210.pools.arcor-ip.net 1193220002 Q * JonB Ping timeout: 480 seconds 1193220109 Q * DavidS Quit: Leaving. 1193222229 J * DavidS ~david@vpn.uni-ak.ac.at 1193222299 J * JonB ~NoSuchUse@130.227.63.19 1193222522 Q * FireEgl Quit: Bye... 1193224075 Q * mire Read error: Operation timed out 1193224577 Q * hardwire Read error: Operation timed out 1193224614 Q * phreak`` Quit: leaving 1193225305 J * hardwire ~bip@rdbck-5504.palmer.mtaonline.net 1193225482 J * Julius ~julius@p57B273C9.dip.t-dialin.net 1193225503 Q * Julius Remote host closed the connection 1193227388 Q * Aiken Quit: Leaving 1193227708 Q * eyck_ Quit: leaving 1193227725 J * eyck ~eyck@nat.nowanet.pl 1193227766 Q * larsivi Quit: Konversation terminated! 1193228781 J * mire ~mire@77-105-22-149.adsl-3.sezampro.yu 1193228941 Q * friendly12345 Quit: Leaving. 1193229033 Q * zLinux Remote host closed the connection 1193229064 J * phreak`` ~phreak``@deimos.barfoo.org 1193230071 Q * Piet Quit: Piet 1193231042 J * David1 ~david@p5481172D.dip0.t-ipconnect.de 1193231042 N * DavidS Guest424 1193231042 N * David1 DavidS 1193231173 Q * Guest424 Ping timeout: 480 seconds 1193231525 Q * mire Read error: Operation timed out 1193231636 J * ema ~ema@rtfm.galliera.it 1193231730 Q * mnemoc Ping timeout: 480 seconds 1193231818 Q * pmenier Read error: Connection reset by peer 1193231847 J * pmenier ~pme@LNeuilly-152-22-72-5.w193-251.abo.wanadoo.fr 1193231901 J * mire ~mire@77-105-22-149.adsl-3.sezampro.yu 1193234427 Q * tam_ Ping timeout: 480 seconds 1193234547 J * FireEgl FireEgl@4.0.0.0.1.0.0.0.c.d.4.8.0.c.5.0.1.0.0.2.ip6.arpa 1193234606 Q * mire Read error: Operation timed out 1193234709 Q * SammyWork Quit: Leaving 1193235357 J * tam ~tam@gw.nettam.com 1193235466 J * speedy ~speedy@home.speedy.org 1193235557 J * mnemoc ~amery@kilo105.server4you.de 1193236285 Q * sladen Ping timeout: 480 seconds 1193236508 J * sladen paul@starsky.19inch.net 1193236850 M * wibble Should I see a "root" server in vserver-stat in the lastest stable release? 1193236851 M * wibble # vserver-stat 1193236851 M * wibble CTX PROC VSZ RSS userTIME sysTIME UPTIME NAME 1193236874 M * daniel_hozac no. 1193237665 M * wibble OK. Just wanted to check :) 1193238014 Q * FireEgl Quit: Bye... 1193238899 J * CWC ~CWC@89.215.37.177 1193239209 Q * CWC Read error: Connection reset by peer 1193239210 J * CWC_ CWC@89-215-37-177.2073053861.ddns-lan.pl.ekk.bg 1193239527 J * CWC__ CWC@89-215-37-177.2073053861.ddns-lan.pl.ekk.bg 1193239527 Q * CWC_ Read error: Connection reset by peer 1193239954 Q * gebura Quit: Quitte 1193240190 Q * CWC__ Ping timeout: 480 seconds 1193240217 J * meandtheshell ~markus@85.127.104.108 1193240277 Q * misc-- Quit: Leaving 1193240583 Q * JonB Read error: Connection reset by peer 1193240629 J * JonB ~NoSuchUse@130.227.63.19 1193240708 J * yarihm ~yarihm@84-75-130-73.dclient.hispeed.ch 1193240803 M * JonB how efficient is vhashify? 1193241335 M * dowdle JonB: How efficient is it? You mean in disk savings? 1193241355 M * JonB dowdle: no i was thinking more like in finding identical files 1193241366 M * JonB dowdle: i run something similar on my backup machine 1193241405 M * JonB dowdle: i use find to find all files and echo their size and inode and path/to/file 1193241410 M * mnemoc checksuming every file is not funny 1193241445 M * JonB dowdle: then i use something else that puts lines with the same size into the a file with the sizename 1193241477 M * JonB mnemoc: only after all that will i check files which are identical 1193241481 M * dowdle JonB: I used it across 4 VPSes that were the same distro and it when I unified them, it only took a few seconds.. 1193241538 M * JonB dowdle: you probably dont have 3,6TB data in 7302721 inodes (files) ? 1193241568 M * JonB what i experience is that that find script only seem to process 1 or 2 files pr second 1193241608 M * mnemoc JonB: I think benchmarks are welcomed :) 1193241611 Q * lilalinux Remote host closed the connection 1193241637 M * JonB it seems to pause a long time while another script parses the outout and puts it into a files with a name of the size of the files inside it 1193241656 M * JonB mnemoc: i was more like looking for suggestions how to improve my script 1193241691 M * JonB earlier i sorted it all into one big file based on the file size 1193241722 M * JonB that didnt seem to work well, so i created lots of small files 1193241748 M * dowdle JonB: No, I only had a stock distro install with no additional data. 1193241754 M * JonB dowdle: okay 1193241791 M * dowdle JonB: Unless you have the same non-OS data across your machines, you'll probably only save about 300MB or less per machine... depending on the OS install size. 1193241817 M * JonB okay 1193241820 M * dowdle JonB: But say... for hosting services that have lots and lots of similiar VPSes, they can save a lot of disk space. 1193241850 M * JonB dowdle: nice 1193241851 M * dowdle JonB: I'm a vserver newbie but that is my understanding of it... with the playing I've done. 1193241904 M * dowdle JonB: Supposedly you can also save RAM with shared memory because of unification but I couldn't notice much with the few VPSes I experimented with. 1193241941 M * dowdle JonB: But there are probably scenerios where there are significant RAM savings. 1193242017 J * fatgoose ~samuel@76-10-151-220.dsl.teksavvy.com 1193242498 M * alex__ how do i add a localhost network to a guest? 1193242567 M * mnemoc alex__: what vserver version? 1193242800 M * alex__ latest 1193242830 M * mnemoc lastest stable or lastest devel? 1193242835 M * alex__ stable 1193242848 M * alex__ im running : util-vserver-0.30.213 1193242849 M * mnemoc then you can't 1193242866 M * mnemoc 2.2.0 binds the loopback to the first assigned IP 1193242914 M * alex__ having issues setting up a sql server 1193242935 M * mnemoc which? 1193243085 M * alex__ ERROR 1130 (00000): Host 'moon.naturalservers.com' is not allowed to connect to this MySQL server 1193243116 M * mnemoc set your permissions correctly ,-) 1193243129 M * alex__ how.... ? 1193243158 M * mnemoc the ACL chapter of mysql docs is a good place to start 1193243202 M * alex__ i just need to configure a user called root to have access to all tables 1193243205 M * alex__ from that hos 1193243205 M * alex__ t 1193243369 M * mnemoc try reading the docs, it's not that hard 1193243982 J * _gh_ ~gerrit@c-67-169-199-103.hsd1.or.comcast.net 1193244317 J * larsivi ~larsivi@101.84-48-201.nextgentel.com 1193244865 Q * _Medivh Ping timeout: 480 seconds 1193245104 Q * pmenier Quit: Konversation terminated! 1193245122 Q * JonB Ping timeout: 480 seconds 1193245915 Q * larsivi Quit: Konversation terminated! 1193246185 J * Piet ~piet@tor.noreply.org 1193246479 Q * ema Quit: leaving 1193246561 J * JonB ~NoSuchUse@kg1-98.kollegiegaarden.dk 1193246738 J * hparker ~hparker@linux.homershut.net 1193246800 J * Linus ~Lucifer@bl7-143-125.dsl.telepac.pt 1193247392 Q * eyck Quit: leaving 1193247404 J * eyck ~eyck@nat.nowanet.pl 1193248394 J * kdean06 ~kdean06@pool-70-17-68-96.res.east.verizon.net 1193248575 M * kdean06 I believe I may have found a vserver bug, but I'm not sure it's actually in vserver and it SEEMS like it might be a security issue. Using the Debian Etch vserver kernel ( 2.6.18-4-vserver-amd64) if I SSH into my vserver host system, "vserver server enter" and then run 'grep -irl "something" *" and it returns "bash: /bin/grep: Argument list too long" it will kick me out of the vserver guest and return me to a host prompt. 1193248607 M * kdean06 I'll also report to Debian in the event it's specific to them. 1193248648 M * daniel_hozac hmm? 1193248696 M * daniel_hozac why would it be a vserver bug that bash dies if the argument list is too long? 1193248714 M * daniel_hozac (seems more like a bash bug if you ask me...) 1193248755 M * kdean06 daniel_hozac, I'm not sure, it may well be. I'm not fully cognizant of what vserver is doing underneath. 1193248758 Q * Piet Quit: Piet 1193248777 J * Piet ~piet@tor.noreply.org 1193249065 M * daniel_hozac works fine here with my lenny guest. 1193249155 M * daniel_hozac same with my etch guest. 1193249202 M * kdean06 Hrm... Interesting... 1193249244 M * kdean06 Oh, you're right. Crap, it's not a Debian guest. 1193249285 M * daniel_hozac so what kind of guest is it? 1193249314 M * kdean06 An old version of RHEL migrated from a physical machine. 1193249326 M * kdean06 Very old RHEl. 1193249621 P * kdean06 It's the little things that make Freedom become Not Freedom. 1193250045 Q * DavidS Quit: Leaving. 1193250494 J * ema ~ema@rtfm.galliera.it 1193251227 J * the-dude ~martijn@senturparks.xs4all.nl 1193252122 Q * JonB Quit: This computer has gone to sleep 1193252767 J * mire ~mire@77-105-22-149.adsl-3.sezampro.yu 1193252939 J * larsivi ~larsivi@101.84-48-201.nextgentel.com 1193253287 J * Aiken ~james@ppp121-45-206-11.lns1.bne1.internode.on.net 1193253940 J * JonB ~NoSuchUse@kg1-98.kollegiegaarden.dk 1193255494 Q * ema Quit: leaving 1193255508 M * bzed heh 1193255532 M * bzed MAX_ARGS is your friend... 1193255735 J * DLange ~dlange@p57A30297.dip0.t-ipconnect.de 1193256036 Q * the-dude Remote host closed the connection 1193256758 J * the-dude ~martijn@senturparks.xs4all.nl 1193256834 Q * JonB Quit: This computer has gone to sleep 1193257095 Q * _gh_ Ping timeout: 480 seconds 1193257663 Q * DLange Quit: Bye, bye. Hasta luego. 1193257676 P * Yvo 1193257720 Q * mire Read error: Operation timed out 1193257969 N * dsoul_ dsoul 1193258159 J * besonen_mobile__ ~besonen_m@71-220-227-56.eugn.qwest.net 1193258159 Q * besonen_mobile_ Read error: Connection reset by peer 1193258601 J * mire ~mire@156-171-222-85.adsl.verat.net 1193258813 N * Bertl_oO Bertl 1193258820 M * Bertl greetings! 1193259100 M * daniel_hozac hey Bertl! 1193259117 M * daniel_hozac http://people.linux-vserver.org/~dhozac/p/k/delta-inetdiag-fix01.diff 1193259157 M * daniel_hozac fixes an oops tanjix was seeing. 1193259432 J * _gh_ ~gerrit@bi01p1.co.us.ibm.com 1193259897 M * Bertl daniel_hozac: nice catch 1193259912 Q * larsivi Quit: Konversation terminated! 1193259987 M * Bertl daniel_hozac: anything I missed the last three days? 1193260065 M * daniel_hozac other than that, nothing i can remember. 1193260075 M * daniel_hozac (which unfortunately doesn't mean much) 1193260097 M * Bertl did 'whoeverwasnotusinginitramfs' solve the boot issues? 1193260160 M * daniel_hozac i haven't read anything more from snooze. 1193260327 M * Bertl okay, so we balantly assume it is fine now and wait for the confirmation :) 1193260346 M * daniel_hozac yep :) 1193260414 M * Bertl okay, despite the fact, that I just tried to discuss my latest idea with dilinger, who had only a few minutes for me, I'm now going to bother you with the very same :) 1193260470 J * gyu ~gyu@tollan.csillagkapu.hu 1193260482 M * daniel_hozac hehe, okay, shoot. 1193260489 M * Bertl no, seriously, the problem (he is seeing) is the following: 1193260520 M * Bertl current CoW link breaking can race, and although we handle that gracefully now, userspace might get 'unexpected' results 1193260529 M * Bertl welcome gyu! 1193260538 M * gyu Bertl: hi 1193260544 M * Bertl so, for example, touch, returns with ENOENT 1193260564 M * Bertl (which is not really expected if the directory exists) 1193260570 M * daniel_hozac right 1193260593 M * Bertl this happens because (copy & paste) 1193260632 M * Bertl so, what if we simply handle the 'dentry gone stale' case in such way, that we lookup the path once again, and return whatever that gives back to the caller 1193260661 M * Bertl which IMHO is exactly what userspace expects 1193260693 M * Bertl just to recap, the 'dentry gone stale' case happens exactly when: 1193260707 M * daniel_hozac yeah, on d_unhashed. 1193260718 M * Bertl process A and B 'touch' a CoW target 1193260736 M * Bertl process A finishes the splice and does the rename 1193260750 M * gyu can sy explain this for me? 1193260750 M * gyu root@io:~# vserver-stat 1193260750 M * gyu Segmentation fault (core dumped) 1193260750 M * gyu root@io:~# vserver-info 1193260750 M * gyu Segmentation fault (core dumped) 1193260750 M * Bertl process B figures that the dentry got stale (because of rename) 1193260764 M * daniel_hozac gyu: don't use Ubuntu. :) 1193260769 M * Bertl lol 1193260791 M * Bertl gyu: sounds like a compiler/toolchain issue, and yes ubuntu is a good candidate 1193260800 M * gyu daniel_hozac: ok, a better suggestion towards resolve the problem? 1193260823 M * daniel_hozac gyu: get dietlibc 0.31, supposedly that works fine on Ubuntu. 1193260826 M * Bertl gyu: get a working toolchain, compile dietlibc, use it 1193260847 M * Bertl gyu: complain to the maintainers :) 1193260867 M * gyu is 0.31 neccessery, or 0.30 may be enough? 1193260873 M * daniel_hozac 0.31 is necessary. 1193260881 M * Bertl gyu: even 0.28 is fine, if the toolchain is okay 1193260885 M * daniel_hozac yeah. 1193260901 M * daniel_hozac but getting a functioning toolchain on Ubuntu is a _lot_ of work :) 1193260920 M * Bertl correct, so 0.31 is probably the simpler way to go 1193260933 M * gyu Bertl: ok, i want to forget ubuntu's util-vserver package, and compile a new one, with 0.30.214... 1193260949 M * Bertl excellent idea, take the sources from debian 1193260951 M * daniel_hozac Bertl: so the only case we'd wind up with a stale dentry is if vfs_rename of process A has completed, right? 1193260966 M * daniel_hozac meaning we're all done, and using the new dentry should be perfectly safe? 1193260984 M * Bertl daniel_hozac: IMHO yes (or if some other process has renamed/removed the file) 1193261002 M * gyu but... the compile fails at this point:/bin/bash ./libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I ./lib -I ./ensc_wrappers -D_GNU_SOURCE -D_REENTRANT -DNDEBUG -DNDEBUG -Wall -g -O2 -std=c99 -Wall -pedantic -W -funit-at-a-time -MT lib/lib_libvserver_la-syscall_getiattr.lo -MD -MP -MF lib/.deps/lib_libvserver_la-syscall_getiattr.Tpo -c -o lib/lib_libvserver_la-syscall_getiattr.lo `test -f 'lib/syscall_getiattr.c' || echo './'`lib/syscall_ 1193261002 M * gyu getiattr.c 1193261002 M * gyu gcc -DHAVE_CONFIG_H -I. -I ./lib -I ./ensc_wrappers -D_GNU_SOURCE -D_REENTRANT -DNDEBUG -DNDEBUG -Wall -g -O2 -std=c99 -Wall -pedantic -W -funit-at-a-time -MT lib/lib_libvserver_la-syscall_getiattr.lo -MD -MP -MF lib/.deps/lib_libvserver_la-syscall_getiattr.Tpo -c lib/syscall_getiattr.c -fPIC -DPIC -o lib/.libs/lib_libvserver_la-syscall_getiattr.o 1193261004 M * gyu In file included from lib/ext2fs.h:23, 1193261006 M * gyu from lib/ioctl-getext2flags.hc:24, 1193261008 M * gyu from lib/syscall_getiattr-fscompat.hc:23, 1193261010 M * gyu from lib/syscall_getiattr.c:36: 1193261012 M * gyu /usr/include/ext2fs/ext2_fs.h:578: error: expected specifier-qualifier-list before '__u64' 1193261014 M * Bertl (please use paste.linux-vserver.org for everything longer than 3 lines) 1193261014 M * gyu /usr/include/ext2fs/ext2_fs.h:733: error: expected specifier-qualifier-list before '__u64' 1193261027 M * gyu ehhmm... sry... i didn't thought that this will so long 1193261032 M * Bertl np 1193261035 M * gyu Bertl: ok, thanks 1193261066 M * daniel_hozac gyu: IIRC the Debian package should have a workaround for that. 1193261080 M * daniel_hozac (the one in testing) 1193261083 M * Bertl gyu: yes, that is the ext2 header stuff, right? 1193261090 M * gyu Bertl: yes 1193261129 M * gyu sg with the __u64, which I don't understand at this point... 1193261139 M * Bertl daniel_hozac: did you find a way to work around that in mainline (in a reasonable way) yet? 1193261150 M * gyu I don't know these toolchains well. yet. ;-) 1193261154 M * Bertl gyu: long story ... 1193261175 M * Bertl maybe daniel_hozac wants to explain it ... 1193261245 M * gyu Bertl: there is no long for me today... I fixed the 2.2.0.4 patch to ubuntu's linux-source-2.6.22 package, and built a kernel with this patch... now I only need to start my favourite vservers ;-) 1193261248 M * daniel_hozac gyu: the kernel doesn't define __u64 and __s64 if __STRICT_ANSI__ is set since ANSI C doesn't have (unsigned) long long. the problem is that -std=c99 defines __STRICT_ANSI__ too, leading to that problem. 1193261269 M * Bertl gyu: are you sure you want to do that (kernel part)? 1193261313 M * gyu Bertl: I don't understand your question, since I wrote that part of the story in past time ;-) 1193261331 M * Bertl gyu: well, I was more referring to the 'using' it :) 1193261340 M * gyu root@io:~# uname -a 1193261340 M * gyu Linux io 2.6.22-vs2.2-generic #1 SMP Wed Oct 24 18:27:04 CEST 2007 i686 GNU/Linux 1193261349 M * Bertl gyu: thing is, the kernel you have is probably completely untested 1193261374 M * Bertl gyu: so, hell might break loose once you do a Linux-VServer syscall command :) 1193261412 M * gyu Bertl: yes, that's correct, since I have time to just reboot my machine, and come home (io is my desktop workstation at my workplace) 1193261450 M * Bertl gyu: at least you should run the testme and testfs scripts once util-vserver is compiled and installed 1193261464 M * Bertl gyu: those should catch most of the obvious issues 1193261472 M * gyu Bertl: yes, hell might break... but I intend to use this kernel in the next 365 day, until I want to update my ubuntu again ;-) 1193261498 M * daniel_hozac Bertl: hmm... is there a reason we don't pass the nd to cow_break_link? 1193261500 M * gyu Bertl: yes, I intended to run those ;-) 1193261535 M * Bertl daniel_hozac: we didn't need to do so before, and I'm not sure we always have that (needs to be checked) 1193261542 M * daniel_hozac we do. 1193261576 M * daniel_hozac it doesn't really change anything, but would save us that initial lookup, i think. 1193261630 M * Bertl we can test that, I think we should add/write a cow race test script 1193261656 M * Bertl which tries to trigger the obvious cases and checks for anomalies 1193261720 M * gyu daniel_hozac: hmm... is there any option I can give to ./configure to not use those ansi restrictions? 1193261739 M * daniel_hozac that makes me wonder though... i managed to trigger that bug in COW when doing it on a file that couldn't be looked up. how did the callers get their nds? 1193261750 M * Bertl gyu: check out the debian source, it's probably the easiest way 1193261766 M * Bertl gyu: it has the required patches for 'debian like' issues 1193261797 M * Bertl daniel_hozac: sounds interesting 1193261888 M * gyu Bertl: hmm... ok, so, the situation: i did: apt-get source util-vserver , and after that i wget the new 0.30.214 source into the parent dir, I did uupdate with the new userland, cd into the new one, and started dpkg-buildpackage 1193261911 M * daniel_hozac gyu: and you added lenny to your sources.list before that? 1193261945 M * gyu daniel_hozac: no, it contain's only gutsy-s repos 1193261946 M * gyu yet 1193261958 M * daniel_hozac so you got a package without the required patch... 1193261966 M * gyu maybe 1193261973 M * daniel_hozac more like definitely. 1193261983 M * daniel_hozac get a recent one and you should be fine. 1193262024 M * Bertl gyu: alternatively you can dig through the IRC logs, and do the very same fix once again :) 1193262111 M * gyu Ok, now I build the dietlibc from lenny's source 1193262131 M * gyu just I thought, finally I won't need 0.31 dietlibc 1193262186 M * daniel_hozac you _need_ dietlibc 0.31. 1193262232 M * daniel_hozac (and you need to get that before you attempt to build util-vserver) 1193262338 M * gyu http://paste.linux-vserver.org/7570 1193262410 M * daniel_hozac looks like your gcc is more broken than usual. 1193262471 M * gyu one theological question: why f...g ubuntu can't contain vserver support as debian does?! 1193262505 M * Bertl gyu: because ubuntu is so f...g great :) 1193262506 M * daniel_hozac i'm not sure i see the relation to god... 1193262533 M * daniel_hozac gyu: so why aren't you running Debian? 1193262549 M * Bertl gyu: no, seriously, no ubuntu maintainer showed up yet 1193262565 M * Bertl gyu: so it can be considered 'unmaintained' in this regard 1193262576 M * gyu daniel_hozac: because I use debian on my servers, but for desktop purpose I like ubuntu much more 1193262634 M * Bertl gyu: I can understand that, although I prefer Mandriva for desktops ... (and most servers actually) 1193262703 M * gyu Bertl: ubuntu contain's many... hmm... comfort functions for the desktop users, which is missing from debian. but it is only my humble opinion 1193262725 M * Bertl gyu: as I said, I _can_ understand that 1193262753 M * gyu Bertl: ok, i'm a bit tired... I saw a "not" word where it wasn't... 1193262770 M * Bertl np, happens here too (from time to time) 1193262984 M * Bertl daniel_hozac: how did the comparison say: Debian: Is treated like a leper, but a very friendly one 1193263000 M * daniel_hozac heheh, i think so. 1193263386 M * gyu auch... this hurts me: I didn't install dietlibc, just dietlibc-dev (and dietlibc-dev doesn't depends on dietlibc)... 1193263406 M * gyu after I installed the dietlibc package (0.30) provided in gutsy... 1193263427 M * gyu the util-vserver (the one from lenny) package built 1193263473 M * gyu but... still doesn't work :-S 1193263507 M * daniel_hozac dietlibc-dev is all that's needed. 1193263551 M * Bertl and you definitely need to recompile the tools after you installed it 1193263552 M * daniel_hozac it's known that dietlibc is broken in Ubuntu. you need to build it yourself. 1193263561 M * gyu first of all... I need some working toolchain to create dietlibc 0.31 :'( 1193263590 M * Bertl that should work with the ubuntu toolchain I think 1193263669 M * gyu even the bin-i386/diet command in itself does a segmentation fault... I don't know how, since it's a statically linked mess 1193263695 M * Bertl that sounds like a toolchain issue indeed 1193263706 M * Bertl gyu: you are on x86 or x86_64? 1193263714 M * gyu Bertl: i386 1193263752 M * dowdle x86 platform starts with 2.6.24. :) 1193263762 M * gyu model name : Intel(R) Pentium(R) 4 CPU 2.80GHz 1193263782 M * Bertl hey dowdle! how's going? 1193263831 M * dowdle Bertl: Pretty good. Very busy week. New Zimbra release, new GIMP release, updated RHEL/CentOS kernel. 1193263903 M * daniel_hozac you did all that? 1193263915 Q * _gh_ Ping timeout: 480 seconds 1193263940 M * Bertl LOL 1193263978 M * dowdle daniel_hozac: If you are talking to me... as an end user... I upgraded. :) 1193263981 M * dowdle Lots of machines. 1193264022 M * daniel_hozac well, that's a couple of commands :) 1193264161 M * dowdle Bertl: You were away for a few days yourself? 1193264195 M * Bertl dowdle: kind of, doing some unrelated FOSS development with a friend 1193264249 M * dowdle Bertl: Care to name the unrelated thingie? 1193264279 M * Bertl http://freshmeat.net/projects/mathmap/ 1193264550 J * _gh_ ~gerrit@bi01p1.co.us.ibm.com 1193264766 M * dowdle Bertl: If you haven't checked out the meetthegimp.org video podcast, and have any interest in GIMP (it appears you do), check it out. 1193264794 M * gyu daniel_hozac: do you have a guess, where can I fix this issue? I assume, the easier way, to write some patch to the dietlibc 0.31 to build on this system 1193264825 M * daniel_hozac gyu: try adding -fno-stack-protector-all to CFLAGS. 1193264911 M * gyu then the debian/diff/0005-Don-t-define-WANT_SSP.diff file is what for? 1193265031 M * daniel_hozac remove that diff. 1193265047 M * daniel_hozac vanilla 0.31 should work fine on Ubuntu. 1193265664 M * gyu cc1: error: unrecognized command line option "-fno-stack-protector-all" 1193265680 Q * Linus Ping timeout: 480 seconds 1193265910 M * daniel_hozac just use vanilla 0.31 with no other changes. 1193266084 Q * yarihm Quit: Leaving 1193266703 Q * dowdle Remote host closed the connection 1193266861 M * gyu daniel_hozac: thanks all your help! 1193266867 M * gyu my vserver just started! 1193266874 M * Bertl gyu: congrats! 1193266876 M * gyu happy kingdom!!! :-D 1193266894 M * Bertl gyu: don't forget to complain to ubuntu folks 1193266904 M * Bertl gyu: otherwise they will not change anything 1193266906 M * gyu Bertl: Ok, I will! ;-) 1193266958 M * gyu I plan to write the whole "story" to some wiki 1193266974 M * gyu and publish the modified patch, etc. 1193266988 M * gyu do you have suggestions about this plan? 1193266993 M * Bertl feel free to abuse our wiki ... if you have to :) 1193267030 M * gyu ok, it's open to edit for anyone? needs a registration only? 1193267073 M * daniel_hozac http://linux-vserver.org/Installation_on_Ubuntu seems like a good place... 1193267083 M * daniel_hozac you don't even need to register. 1193267132 M * gyu daniel_hozac: thank's for your help, I'll do it, but now, I have some rest, and sleep ;-) 1193267144 M * daniel_hozac you're welcome! 1193267148 M * gyu good night! 1193267170 Q * gyu Quit: Leaving 1193267198 M * Bertl daniel_hozac: http://paste.linux-vserver.org/7575 1193267219 M * Bertl does that look like a hat-trick? :) 1193267231 M * daniel_hozac haha, it does. 1193267233 Q * igraltist Ping timeout: 480 seconds 1193267244 M * daniel_hozac maybe move it to the front of the message? 1193267261 M * Bertl thought about that, it's quite flexible the way I added it 1193267264 M * daniel_hozac i.e. vxW: %s[#%d]: or so. 1193267284 M * Bertl not sure though, that this is fine for all warnings 1193267299 M * daniel_hozac which ones wouldn't it be fine for? 1193267307 M * Bertl i.e. have to check them, and maybe we want two vxw* macros 1193267362 M * daniel_hozac ah, yeah, the limit checks probably don't make much sense to have a process. 1193267378 M * daniel_hozac (but they need an xid instead) 1193267401 M * Bertl process could be interesting there too 1193267412 M * daniel_hozac will just be the last process, no? 1193267414 Q * _gh_ Read error: Operation timed out 1193267421 M * daniel_hozac i.e. not necessarily the one which caused the problem. 1193267478 M * Bertl ah, you meant the exit messages, yes those are good examples for a process less warning 1193267485 Q * Johnsie Ping timeout: 480 seconds 1193267658 M * Bertl vxpprintk() or vxvprintk() maybe? 1193267676 M * daniel_hozac process and... vxi? 1193267725 M * Bertl or, alternatively, we could add a 'type' as first argument 1193267736 M * Bertl something like: 1193267752 M * Bertl vxwprintk(task, "xxx", ...) 1193267791 M * Bertl but I guess that is just confusing 1193267806 M * Bertl (was thinking of macro expansion magic here) 1193267808 M * daniel_hozac yeah, separate macros are fine. 1193267838 M * Bertl maybe vxw_task_printk vxw_vxi_printk 1193268057 J * Johnsie ~jdlewis@c-67-163-142-234.hsd1.pa.comcast.net 1193268166 J * _gh_ ~gerrit@bi01p1.co.us.ibm.com 1193268252 M * micah daniel_hozac: i'm looking at your response to #445054, and trying to understand what you mean when you say, "As for fixing it for you, I wouldn't want my uids and gids suddenly changing due to an upgrade..." -- how would uids/gids change in the scenario you are describing? 1193268302 M * daniel_hozac they wouldn't, but xids are analogous to uids. 1193268312 M * micah ah 1193268316 M * micah ok, that makes sense 1193268346 M * Bertl (in the future, tags :) 1193268352 M * micah maybe what I will do is include a NEWS file that says that dynamic contexts are deprecated and in order to fix them you must put some unique number in the context file of each guest 1193268387 M * Bertl micah: yes, maybe put that in the 0.30.210 versions too ... just kidding :) 1193268422 M * micah :D 1193268439 M * daniel_hozac Bertl: hmm? 1193268464 M * daniel_hozac we're renaming xid/nid to tags? 1193268467 M * Bertl daniel_hozac: just referring to the tag vs xid without any context 1193268520 M * Bertl daniel_hozac: so don't worry, neither xid nor nid will go away, but the analogon to uid will be tag (but I understand what you meant, and I didn't read #445054) 1193268556 M * daniel_hozac ah, i see. 1193268584 M * Bertl so, in theory, it would be sufficient to keep the 'tag' constant 1193268657 M * daniel_hozac well, loop-devices and similar still use the xid. 1193268688 M * Bertl that's fine, as they will be (hopefully) re-created on restart 1193268707 M * daniel_hozac we don't have anything that frees them on stop though. 1193268736 M * Bertl yes, thought about that for some time ... but it's similar to the dlimits 1193268744 M * daniel_hozac right. 1193268761 M * Bertl maybe we should (at some point) implement a 'zap' functionality 1193268779 M * Bertl to get rid of whatever resource an x/nid is still holding 1193268876 Q * Johnsie Quit: G'bye! 1193268898 M * daniel_hozac that seems like a rather expensive operation. 1193268968 J * Johnnie ~jdlewis@c-67-163-142-234.hsd1.pa.comcast.net 1193268995 M * Bertl yes, but it could help in emergency cases 1193269027 M * daniel_hozac yeah. 1193269171 Q * dna Quit: Verlassend 1193269505 M * Bertl any preference for the warning macros on your side? 1193269885 M * daniel_hozac nah, whichever is fine by me. 1193270216 Q * Piet Quit: Piet 1193270287 M * Bertl okay, I guess I hit the sack for now .. will wrap something up tomorrow ... 1193270304 M * Bertl have a good one everyone! cya! 1193270313 N * Bertl Bertl_zZ 1193270343 M * micah daniel_hozac: vserver start --rescue does what compared to vserver start --rescue-init (and vserver start *)? 1193270353 M * micah I'm fixing up the vserver.8 1193270366 M * micah (which is still for legacy!)