September 4, 2013 
< | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | >
September 4, 2013 [00:10:05] <bleutoo> was reading that esxi 5.5 had some kind of new vGPU support[00:16:41] *** chakatz has quit IRC[00:18:41] <jellydonut> gpu support isnt the problem, i can just install lolux and get gpu passthrough, but that would defeat the point. my storage management would still consist of an antiquated volume manager and a file system whose idea of checksum is fsck post-catastrophe[00:19:25] *** axonpoet has quit IRC[00:21:15] <bleutoo> There's ZFS on Linux...[00:22:01] <bleutoo> I don't know.[00:23:06] *** gbluma has quit IRC[00:24:50] <wesolows> if something is really important to you and you want the benefits of our OS, why not do some work and write the thing you want?[00:25:49] <jellydonut> i don't even know how to write hello world unless i copy it from a tutorial, where on earth do i start?[00:26:25] <wesolows> Buy an introductory book on C and start learning with illumos.[00:26:37] <wesolows> Do you think I was born knowing this stuff?[00:26:55] <jellydonut> well no but i imagine everyone to be the prototypical coder who started doing useful things in their teens[00:27:34] <wesolows> It's never too late. Or, put another way, if you don't start learning now you'll never be able to do it.[00:28:00] <wesolows> And FWIW there are very few people who anything useful in their teens.[00:28:06] <wesolows> In this or any other field.[00:28:39] <jellydonut> so i shouldn't start out with a higher level language and do smaller things because that's what's suggested by.. uh i dunno articles[00:28:57] <wesolows> I can't tell you what method of learning will work for you.[00:29:10] <wesolows> But I can tell you that doing nothing will result in lack of learning. :)[00:29:18] *** utlemming has quit IRC[00:31:27] <bleutoo> jellydonut: what is your profession?[00:32:34] <jellydonut> marine engineer[00:32:42] <jellydonut> my daily tool is a wrench[00:32:44] <jellydonut> not a keyboard[00:32:48] <bleutoo> ah, nice[00:33:40] <jellydonut> (this is when all the coders bang their keyboards against their shields, 300-style)[00:34:12] <bleutoo> coders can like boats too[00:34:46] * bleutoo was in the coast guard[00:35:25] <jellydonut> oh! me too. well, probably not the same country's coast guard[00:35:36] <bleutoo> US[00:35:40] *** cjones_ has quit IRC[00:35:46] <jellydonut> yeah, norway here[00:35:55] <jellydonut> but i'm civilian now.. and happy about that[00:36:02] <bleutoo> same here[00:40:54] <bleutoo> http://cuddletech.com/blog/?p=817[00:41:26] <bleutoo> That was a good read for me. Might help set your mind about programming too.[00:41:30] <jellydonut> well.. i'm not a sysadmin.. and i've never used any programming languages, nor would i boast of such a thing :D[00:42:58] <jellydonut> okay fine i'll try to find a good book on C[00:43:44] <bleutoo> Have you already been using illumos?[00:44:02] <jellydonut> no, i've only used opensolaris before oracle bought sun[00:44:21] <jellydonut> right now i have no home nas running so i haven't actively looked for a replacement[00:45:57] *** emocakes has quit IRC[00:47:24] <bleutoo> I'm completely new to illumos. SmartOS really caught my attention[00:48:49] <bleutoo> Convinced me to upgrade my aging AMD-based home server.[00:52:07] *** izaki has quit IRC[01:01:03] *** elijah-mbp has joined #smartos[01:04:50] *** utlemming has joined #smartos[01:05:46] *** bleutoo has left #smartos[01:14:17] <bixu> jellydonut: If you want to do this for the fun of building it, I'd agree with the others and take a crack at learning new stuff. If you want a practical, clicky tool that get's out of your way, get a Mac and ssh into your SmartOS NAS when you need to. At least, that works well for me.[01:14:41] <bixu> Full disclosure: I don't like computers. I just use them when they are the best tool for the job.[01:14:53] <wesolows> bixu++[01:14:59] <wesolows> computers suck; that shit doesn't work[01:15:21] <jellydonut> well i'd love to do it for the fun of building it but i don't imagine i will have much 'fun'[01:15:40] *** sparq_ has joined #smartos[01:16:02] *** sparq_ has quit IRC[01:16:42] *** papertigers has joined #smartos[01:17:29] *** trentster has left #smartos[01:18:28] *** backjlack has quit IRC[01:21:58] *** sparq_ has joined #smartos[01:42:41] *** chakatz has joined #smartos[01:57:58] *** chakatz has quit IRC[02:03:00] *** axonpoet has joined #smartos[02:03:40] *** altf2o has quit IRC[02:23:00] *** cjones_ has joined #smartos[02:33:28] *** FatDarrel has quit IRC[02:51:17] *** cjones_ has quit IRC[03:05:19] *** sa5bke has joined #smartos[03:15:59] *** groundwater has quit IRC[03:20:13] *** dap has quit IRC[03:20:38] <hile_> c[03:32:05] *** Thrae has quit IRC[03:34:51] *** potatosalad has quit IRC[03:48:24] *** potatosalad has joined #smartos[03:54:39] *** nefilim has joined #smartos[03:55:36] *** cjones_ has joined #smartos[04:02:12] *** potatosalad has quit IRC[04:03:40] *** potatosalad has joined #smartos[04:16:45] *** Thrae has joined #smartos[04:22:11] *** axonpoet has quit IRC[04:24:43] *** julianduque has quit IRC[04:25:41] *** julianduque has joined #smartos[04:26:05] *** potatosalad has quit IRC[04:30:14] *** sparq_ has joined #smartos[04:41:05] *** mary5030 has joined #smartos[04:42:23] *** mary5030 has quit IRC[04:42:55] *** mary5030 has joined #smartos[04:50:36] *** dap has joined #smartos[04:51:40] *** dap1 has joined #smartos[04:52:08] *** cjones_ has quit IRC[05:03:18] *** leecallen35 has joined #smartos[05:06:39] *** leecallen has quit IRC[05:14:57] *** axonpoet has joined #smartos[05:41:58] *** potatosalad has joined #smartos[05:49:01] *** mary5030 has quit IRC[05:56:15] *** hile__ has joined #smartos[05:57:37] *** Garen_ has joined #smartos[05:57:38] *** Teknix has joined #smartos[05:57:51] *** xenol_ has joined #smartos[05:59:23] *** tardisx` has joined #smartos[05:59:42] *** ivan\ has quit IRC[05:59:43] *** xenol has quit IRC[05:59:44] *** Garen has quit IRC[05:59:47] *** hile_ has quit IRC[05:59:48] *** tardisx has quit IRC[05:59:49] *** Tekni has quit IRC[05:59:51] *** defel has quit IRC[05:59:52] *** defel_ has joined #smartos[06:00:18] *** ivan\ has joined #smartos[06:14:12] *** potatosalad has quit IRC[06:31:33] *** cjones_ has joined #smartos[06:33:22] *** cjones_ has quit IRC[06:33:28] *** cjones__ has joined #smartos[06:35:55] *** mary5030 has joined #smartos[06:36:16] *** axonpoet has quit IRC[06:48:36] *** tbatchelli_m has quit IRC[06:48:45] *** julianduque has quit IRC[06:53:32] *** FatDarrel has joined #smartos[06:55:02] *** szaydel has quit IRC[06:56:45] *** julianduque has joined #smartos[07:03:41] *** mary5030 has quit IRC[07:04:12] *** FatDarrel has quit IRC[07:06:06] *** julianduque has quit IRC[07:18:36] *** cjones__ has quit IRC[07:25:40] *** dap1 has quit IRC[07:29:33] *** cjones_ has joined #smartos[07:30:57] *** nefilim has quit IRC[07:41:52] *** cjones_ has quit IRC[08:52:39] *** kollross has quit IRC[08:52:53] *** tonist has joined #smartos[08:56:04] *** yruss972 has joined #smartos[08:58:15] *** mtg` has quit IRC[08:58:22] *** yruss972 has quit IRC[08:58:44] *** altf2o has joined #smartos[08:58:46] *** yruss972 has joined #smartos[08:59:21] *** yruss972 has quit IRC[08:59:47] *** yruss972 has joined #smartos[09:01:14] *** yruss972 has quit IRC[09:02:12] *** mtg has joined #smartos[09:13:07] *** tonist has joined #smartos[09:20:00] *** mamash has joined #smartos[09:20:54] *** texarcana has quit IRC[09:24:29] *** KermitTheFragger has joined #smartos[09:25:02] *** papertigers has quit IRC[09:25:35] *** papertigers has joined #smartos[09:26:11] *** nikolam has quit IRC[09:27:20] *** wiedi has joined #smartos[09:35:50] *** jgrafton_ has joined #smartos[09:46:09] *** mamash has left #smartos[09:53:11] *** mamash has joined #smartos[10:12:26] *** backjlack has joined #smartos[10:16:49] *** kollross has joined #smartos[10:24:14] *** tonist has quit IRC[10:31:27] *** xenol_ is now known as xenol[10:59:18] *** joshie has quit IRC[11:04:29] *** alcir has joined #smartos[11:10:02] <Alasdairrr> anyone ever seen this: multiticks: internal timer error; aborting and all your qemu processes die at once?[11:16:32] *** tonist has joined #smartos[11:18:10] *** joshie has joined #smartos[11:18:57] *** andy_js has joined #smartos[11:44:40] *** Jadelrab has quit IRC[11:45:54] <LnxTx> windows guest question. i have in "custromer_metadata" field "administrator_pw" with admin password and empty field "root_authorized_keys". with mdata-get.exe i can get data from "root_authorized_keys" but i can't from "administrator_pw", error "No metadata for administrator_pw"[11:45:58] <LnxTx> why?[11:46:42] <MerlinDMC> they did move those keys which end on _pw to internal_metadata afaik[11:48:11] <MerlinDMC> LnxTx, https://github.com/joyent/smartos-live/commit/913489fbc4a6e4f9516242ad34713f174bbf1d80[11:48:38] <LnxTx> ok, with test[11:48:41] <LnxTx> *will[11:54:09] *** swaagie has quit IRC[11:58:52] <LnxTx> MerlinDMC: thanks, its works :)[12:06:15] *** mikl has quit IRC[12:10:30] *** mikl has joined #smartos[12:16:39] *** xenol has quit IRC[12:21:33] *** xenol has joined #smartos[12:44:34] *** swaagie has joined #smartos[12:48:16] *** Jadelrab has joined #smartos[13:06:57] *** emocakes has joined #smartos[13:13:07] *** trentster has joined #smartos[13:13:21] *** trentster has left #smartos[13:13:30] *** trentster has joined #smartos[13:19:47] *** potatosalad has joined #smartos[13:26:21] *** nikolam has joined #smartos[13:33:07] <alcir> maybe this is[13:33:20] *** tonist has quit IRC[13:35:33] *** szaydel has joined #smartos[13:35:51] <alcir> zfs contemplate something like worm with retention policy?[13:39:12] <alcir> maybe with snapshots?[13:39:57] <alcir> because I'm looking for something like: I write a file, such file must be unalterable for a month[13:40:56] *** potatosalad has quit IRC[14:04:40] *** oc has joined #smartos[14:10:36] *** emocakes has quit IRC[14:13:15] *** tonist has joined #smartos[14:38:31] *** potatosalad has joined #smartos[14:52:53] *** chakatz has joined #smartos[15:04:29] <xenol> alcir: snapshots can do what you want, you can even hold them so they don't get removed[15:05:27] <mnaser> 4x SSD w/ 2x SSD striped as L2ARC *or* 6x SSD without any L2ARC.. disk space isn't a concern.. thoughts/suggestions?[15:05:47] <xenol> alcir: or you could use file attributes and set indestructable flag and remove it after needed period[15:06:53] <xenol> mnaser: depends, what are you planning on running on those ssds?[15:07:11] <mnaser> xenol: virtual machines with different workloads, so hard to make a decision on the type of workload[15:07:27] <mnaser> can't say if it'll be mostly sequential or random, but with vms, theres bound to be a lot of random[15:07:40] <xenol> how many RAM do you have?[15:07:45] <xenol> how much*[15:08:43] <mnaser> thinking about putting 32GB just for ARC (node has much more but that would be dedicated to ARC)[15:08:50] <mnaser> based on the 20% rule that smartos has anyways[15:10:01] <xenol> 20% rule?[15:10:31] <mnaser> xenol: i believe smartos doesnt allow you to create servers beyond 80% of the server total memory to dedicated the rest for ARC[15:14:30] *** zr0 has quit IRC[15:14:46] <arekinath> I've created vms >80% of ram before without issues[15:15:07] <arekinath> sometimes things are slow while it tries to lock out the ARC and steal back the memory it's using[15:15:28] <arekinath> but only at startup[15:17:02] *** badboy_ has quit IRC[15:18:01] *** badboy_ has joined #smartos[15:19:13] *** jim80net has joined #smartos[15:32:11] <nahamu> mnaser: are all the SSDs identical?[15:32:26] <mnaser> nahamu: they will be[15:33:28] <nahamu> I'm not sure how much of a win it is to use L2ARC devices when the underlying pool will be low latency.[15:33:48] <mnaser> nahamu: that's what im thinking, i was suggested by guys at #zfs to do 3 2-ssd mirrors[15:34:07] <nahamu> yeah, that's my gut sense, but I'm far from an expert.[15:35:51] *** hadret has joined #smartos[15:35:54] *** neophenix has joined #smartos[15:43:36] *** hadret has quit IRC[15:43:53] <badboy_> Hey guys. We're running 2 SmartOS hosts with several VMs in it. We mostly use KVM machines to run Linux or Windows. From time to time we see quite high IO Wait times in the VMs. Any idea what might cause this or how I can look into it to find any deeper problem?[15:52:26] <MerlinDMC> badboy_, afaik all IO inside qemu is synchronous ... so if you don't have a ZIL it would slow down rapidly if some VMs do write at once - i guess you can trace those write with dtrace and if they sum up while iowait is rising ... but I'm not that deep into dtrace :)[15:53:19] <badboy_> Ok.[15:53:45] <badboy_> there are some SSDs in, they SHOULD be used for the ZIL.[15:57:14] *** mary5030 has joined #smartos[15:58:03] *** mary5030 has quit IRC[15:58:39] *** mary5030 has joined #smartos[16:05:19] *** xinkeT has quit IRC[16:05:56] <wesolows> well step 1 might be to verify that[16:06:33] <wesolows> step 2 might be to see if those slow guest I/Os are correlated with slow physical I/Os, to see whether the problem is internal to qemu+guest or related to the host-visible workload[16:06:40] *** xinkeT has joined #smartos[16:06:48] <wesolows> you could use iostat and/or dtrace for that[16:14:38] *** zr0 has joined #smartos[16:16:54] <nahamu> I just gasped with excitement when I notied that -0 support for xargs made it into illumos and illumos-joyent... and my coworker proceeded to mock me accordingly.[16:19:37] *** chakatz has quit IRC[16:19:51] <wesolows> smartos-live is unfortunately not building at the moment[16:20:04] <wesolows> I have one last build fix I'm spinning now; should be integrated later this morning.[16:20:12] <wesolows> Then you can build -0 to your heart's content.[16:23:16] <estibi> from a smartos-discuss:[16:23:17] <estibi> Well I tried to ask for a quotation of Smartdatacenter, nearly a year ago, but joyent accept only queries from[16:23:20] <estibi> big datacenter with servers with 1TB ram or more. As I said we have very small servers with max 64 GB ram.[16:23:23] <estibi> Is that true?[16:23:28] <jperkin> no[16:23:58] <wesolows> I wouldn't know, TBH.[16:24:16] <MerlinDMC> wesolows, if you're the Keith from the degraded disks discussion ... does your current CN smartosyou tested with also have the "2932 support crash dumps to raidz, etc. pools" commit integrated?[16:24:18] <wesolows> If you mean whether we support only individual servers with >1TB RAM *each*, that's emphatically false.[16:24:27] <wesolows> None of our servers are that big.[16:24:27] *** potatosalad has quit IRC[16:24:35] <wesolows> MerlinDMC: yes.[16:24:53] <wesolows> I tested with bits from late last week, newer than anything released as SmartOS.[16:25:12] <MerlinDMC> hmm ...[16:25:39] <MerlinDMC> I hoped for the easy way ;)[16:25:49] <estibi> ok, that said I'm still waiting for a reply from Eric.. I think he just deleted my email :)[16:27:58] *** potatosalad has joined #smartos[16:28:23] *** nefilim has joined #smartos[16:28:51] <wesolows> This problem is either multiple problems or is more complex than thought.[16:29:08] <wesolows> and the fact that not a single SDC user has yet seen it is suspicious in itself.[16:30:16] *** cjones_ has joined #smartos[16:33:28] *** tonist has quit IRC[16:35:06] *** mary5030 has quit IRC[16:40:00] *** cjones_ has quit IRC[16:40:26] *** cjones_ has joined #smartos[16:41:05] <nahamu> does SDC even have support for dump on raidz yet?[16:41:46] <nahamu> I'd imagine SDC7 would, but aren't most customers still on 6.5.x?[16:42:46] <wesolows> I don't know the tally.[16:43:04] <wesolows> There are SDC 7 CNs in JPC, and of course Engineering has been using SDC 7 CNs for months.[16:43:10] <wesolows> Almost years now, actually.[16:43:24] <yofuh> baarf.com :p[16:44:48] *** cjones_ has quit IRC[16:44:57] <wesolows> Fortunately our OS does not support RAID-4 nor RAID-5. :)[16:48:49] *** axonpoet has joined #smartos[16:48:58] *** cjones_ has joined #smartos[16:49:13] *** axonpoet has quit IRC[16:50:17] *** axonpoet has joined #smartos[16:51:22] *** mary5030 has joined #smartos[16:51:36] *** mary5030 has quit IRC[16:52:16] *** mary5030 has joined #smartos[16:52:56] <rmustacc> estibi: Most likely the confusion stems from not wanting to sell SDC to someone whos total servers sum to less than 1 TB of DRAM, not 1 TB in a single box.[16:54:57] <rmustacc> Though obviously I was not not involved in any of that so I can't say.[16:55:23] * nahamu does some math and realizes his blade chassis currently has ~1.2TB of DRAM.[16:56:31] <nahamu> 12 nodes, though.[16:58:47] *** pringlescan has joined #smartos[16:58:55] <rmustacc> I can't say that's always going to be the minimum case for a sale or what not, just that it's most likely that's what they're referring.[16:59:15] *** mary5030 has quit IRC[16:59:27] <pringlescan> hello all, the default receive buffer size in smartos is causing a socket error in ApacheDS[16:59:44] *** tbatchelli_m has joined #smartos[16:59:48] <pringlescan> This ticket explains it well: https://jira.atlassian.com/browse/STASH-3624 it'll affect atlassian software and apacheds[17:00:03] <pringlescan> any ideas how it can be resolved? it's kind of a show stopper for a good number of java apps[17:01:45] <rmustacc> pringlescan: Can you perhaps share what exactly the arguments it's trying to make are?[17:01:49] <rmustacc> It's not very clear what's going on in this case.[17:02:44] <pringlescan> if apacheds is running for a few days, it starts giving me errors, and apparently they related to Apache's Mina which is used in many Java apps, when there is an error most O/S's truncate the buffer, but Solaris throws an error, which apparently means the connection doesn't get cleaned up properly[17:03:17] <natefoo> this is not happening on smartos so feel free to ignore me, but has anyone ever had a case of a faulted disk being "stuck" in the vdev?[17:03:18] *** leecallen35 has quit IRC[17:03:33] *** leecallen has joined #smartos[17:03:34] <rmustacc> pringlescan: It feels like the fix is in Mina.[17:03:37] <pringlescan> "Apache sshd fails to clean up the socket that has just been accepted, resulting in all the file descriptors for the process being consumed."[17:03:47] <rmustacc> Uh...[17:03:50] <rmustacc> That's a bug in apache.[17:04:07] <rmustacc> So if you run pfiles you have 65k fds open?[17:04:13] <natefoo> i've offlined, physically removed/replaced, zpool replaced, and its relacement is online, but the old disk is still just offlien and not removed form the vdev.[17:04:25] <nahamu> "Apache sshd"??[17:04:27] <pringlescan> unfortunately I had to get the service up and running before I could check the log files so I did a reboot[17:04:41] <pringlescan> nahamu, it basically effects anything using apache mina, which includes atlassian products, apacheds, apache sshd[17:04:52] <pringlescan> https://git-wip-us.apache.org/repos/asf?p=mina-sshd.git;a=blob;f=sshd-core/src/main/java/org/apache/sshd/SshServer.java;h=b5c95b673cf588fbecf6c4adcb67c95d3d3a5832;hb=HEAD#l424 is the line in the source code[17:05:30] <rmustacc> So there are two problems then in essence.[17:05:31] <nahamu> I had no idea that apache sshd existing.[17:05:48] <rmustacc> One is that the code doesn't know how to determine the maximum send buffer size.[17:05:58] <rmustacc> Two, it doesn't clean up errors.[17:06:07] <yofuh> ssh server in java? oh....[17:06:23] <pringlescan> ApacheDS has been running for 5 minutes and pfiles shows it having 211 open sockets[17:06:42] <pringlescan> so at that rate, over a few days it would max out[17:06:43] <rmustacc> I have no idea whether that's reasonable or not given your workload.[17:06:49] <natefoo> oh it's probably these data errors in files.[17:07:03] <pringlescan> rmustacc, definitely not[17:08:08] <rmustacc> Well, bad news is no matter what we do for number 1, they need to fix number 2.[17:08:47] <pringlescan> so it's a two part fix?[17:09:06] <pringlescan> I guess I'll just have to restart all of my services at midnight every night until then[17:09:08] <rmustacc> Well, I'm still not entirely clear what' to blame.[17:09:29] <natefoo> for the logs: zpool clear seems to be the answer.[17:09:36] <pringlescan> I just got a frantic call that nobody could log into Google Apps becuase LDAP was down[17:09:39] <rmustacc> Looking at the linked Java bug report in the other bug it seems to indicate it's a bug in more than just S9.[17:09:42] <natefoo> and now i have to re-resilver. =P[17:09:59] <pringlescan> I have LDAP running VRRP and HaProxy but my health check apparently wasn't working properly[17:10:20] <pringlescan> apacheds should just die if it can't accept incoming connections[17:10:40] <rmustacc> And it appears that from the bug report part of the confusing behavior is fixed in Java 7.[17:10:57] <rmustacc> I would take up the question of it dying by default with the apache folks.[17:11:12] <rmustacc> I probably wouldn't opt for the behavior by default as it should mean I have 65k of clients I'm servicing.[17:11:17] <rmustacc> So are you using Java 6 or Java 7?[17:12:25] <rmustacc> Though that only changes the error message it looks like.[17:12:53] <rmustacc> Ultimately it seems like regardless of what we do at the setsockopt layer -- apache has to clean up its code properly in this case.[17:14:45] <pringlescan> java version "1.7.0_25"[17:15:28] <rmustacc> Right, digging into it only changes the error message.[17:16:14] <rmustacc> So you'll need to work with them to fix that bug in mina regardless.[17:16:42] <rmustacc> And then a question to bring up with illumos is whether we should change that behavior to silently truncate, which I'm not sure about personally.[17:16:51] <rmustacc> But I could probably be compelled in either way.[17:16:56] <yofuh> in memoriy to a zombie-thread invasion... had once a problem in an application where not detached threads got leaked as they did not join. appeently that threads just died on linux but not on solaris while that was clearly a fault of the application we can learn something from that: "if the bug doesn't appear on linux, it must be the OSs fault"[17:17:14] *** groundwater has joined #smartos[17:18:11] <rmustacc> It seems like something we should be adding is a way to get the maximum send and receive buffers via getsockopt[17:20:14] <rmustacc> I guess we should start killing random processes so people feel more at home.[17:20:47] <opeth__> :]]] touche'[17:20:48] *** vizanto2 has joined #smartos[17:21:01] *** vizanto2 has quit IRC[17:21:45] <elijah-mbp> :)[17:21:49] <rmustacc> I mean, yes, a lot of applications program themselves to GNU/Linux and that's something that we have to do as a community.[17:21:58] *** vizant0 has joined #smartos[17:21:59] <pringlescan> Well, I'm here to cheer any efforts to fix any part of this bug as it makes my using zones for mission critical services impossible without Windows-style reboots[17:22:06] <pringlescan> =D[17:22:16] <nahamu> rmustacc: as long as SMF picks up the pieces... :-P[17:22:18] <rmustacc> You'll need to drive the process with the apache folks.[17:23:34] <rmustacc> Whoever is responsible for fixing bugs in mina (I suspect the answer is not me) needs to get that fixe.[17:23:37] <rmustacc> *fixed[17:25:02] <nahamu> pringlescan: and you think this also affects Jira, Confluence, Crowd, etc.?[17:26:15] <yofuh> rmustacc: just like netflix chaos monkey? would bring a lot of "fun" to the smartos community i guess[17:26:29] <yofuh> rmustacc: but please let me svcadm disable it[17:27:07] <nahamu> you could certainly write a chaos monkey to kill JPC instances via the SDC APIs/tools.[17:27:27] <nahamu> probably the responsible thing to do if you decide to run a netflix competitor in the JPC...[17:28:37] <nahamu> I bet the Project FiFo tools would let you do something similar too.[17:29:23] <pringlescan> nahamu: well, stash certaintly[17:29:47] <pringlescan> anything that uses mina, indirectly it effects crowd if you're using java based ldap[17:29:58] <yofuh> as fifo is rather storage focused, it should delete volumes randkomly instead[17:30:13] <jzu_> uhm. we had ZFS cksum errors few days ago, it got repaired but # fmadm faulty is still reporting those errors as 'Diagnosed' - any way I can clear the errors from fmadm faulty output?[17:30:16] <pringlescan> yofuh, I think that goes without saying[17:30:22] <nahamu> I think we're using crowd's internal user directory mechanism...[17:30:35] *** gkyildirim has joined #smartos[17:30:36] <nahamu> jzu_: fmadm acquit?[17:32:56] <jzu_> nahamu: thanks =)[17:33:11] <jzu_> never had to use that one... I've just well - waited the month or whatever it takes for fmadm to repair those by itself[17:33:48] *** alcir has quit IRC[17:34:48] <rmustacc> pringlescan: Here's a different thing you can do.[17:35:03] <rmustacc> pringlescan: Figure out what size it's trying to set it to.[17:35:12] <rmustacc> And tune the maximum settable size to be above that in the zone.[17:35:33] <rmustacc> Now if you're getting an error because of a client socket reset, well, you're still going to be screwed.[17:35:40] <rmustacc> Because it's not cleaning up its fd like it wants to.[17:35:51] *** chorrell has joined #smartos[17:35:52] <rmustacc> But say that's 1-5% of the cases, then that should let you get through.[17:36:07] <Licenser> yofuh fifo storage focused?[17:36:17] <Licenser> but I like the ida[17:36:51] <nahamu> yofuh: how is FiFo storage focused?[17:37:03] <rmustacc> pringlescan: You need to figure out what value it's trying to set it to.[17:37:15] <rmustacc> And then tune max_buf for tcp accordingly via ipadm.[17:37:31] <yofuh> Licenser: if it's not, you should work on your marketing. i actually had never a closer look on that[17:38:06] *** pringlescan1 has joined #smartos[17:38:19] <Licenser> yofuh heh what marketing? :)[17:38:22] <yofuh> just looked at the website at some point and got the impression that it's some kind of web-ui to configure zfs[17:38:45] <Licenser> you're mixing that up with napp-it I think[17:38:57] <yofuh> might be, who knows[17:39:22] <Licenser> :0 I was just curiose where you got the idea from ;) because if the web page makes you think it's storage related then I really have done something wring ^^[17:39:24] *** pringlescan has quit IRC[17:39:36] *** pringlescan has joined #smartos[17:39:44] *** pringlescan1 has quit IRC[17:39:50] <pringlescan> really spotty internet right now, what did I msis?[17:40:11] <rmustacc> pringlescan: you missed me giving you a work around I guess.[17:40:31] <pringlescan> You said to set it in the zone, what property do I need to seT?[17:40:31] <rmustacc> I'll duplicate what I said.[17:40:44] <yofuh> Licenser: right, at the moment it looks like a web-ui for vmadm, still doesn't attact me but well, no storage focus[17:40:49] <nahamu> also http://echelog.com/logs/browse/smartos/1378245600[17:40:51] <rmustacc> pringlescan: You need to figure out what value it's trying to set it to.[17:40:52] <rmustacc> And then tune max_buf for tcp accordingly via ipadm.[17:41:08] <Licenser> yofuh that's OK ;) not wanting to sell it I was just worried the page is that bad[17:41:27] <pringlescan> I think it queries for the max and then sets it to the max[17:41:37] <rmustacc> If that's the case then the bug makes no sense.[17:41:40] <pringlescan> if it fails to find the max, it causes an error[17:41:47] <rmustacc> Because it would always be correct to set that.[17:41:53] <rmustacc> Unless the socket connection got reset.[17:42:09] <pringlescan> what if querying for the max size in a way that you guys don't support causes the socket error/[17:42:11] <rmustacc> And if you're having that many connections get reset and mina isn't cleaning that up, then nothing I can do can fix it.[17:42:27] <szaydel> Along the same lines of networking, I am noticing that with dladm I cannot create aggregates live, get errors about links being busy, when I know they are not used. But, on boot via /usbkey/config aggrs work OK. Is this by design, does anyone know?[17:42:51] <rmustacc> szaydel: Not by design I would think. The question is who or what thinks they're using those nics.[17:43:07] <rmustacc> Answer that question and we'll know what.[17:43:24] <rmustacc> pringlescan: Then I would suggest you use dtrace and determine exactly what getsockopt/setsockopt call is failing.[17:43:30] <szaydel> rmustacc: Yeah, OK figures. I started looking at net-physical to see what all is happening on boot.[17:43:51] <rmustacc> Well, it's unlikely to be anything special in net-physical.[17:44:01] <rmustacc> The question is what in the systems now has open mac clients.[17:44:11] <yofuh> Licenser: it's not your fault anyway, you as well as napp-it are building a web based "something"-management foo, i just don't like that kind of management-uis, no matter what, so i'm not your market anyway, there clearly are people who like such stuff[17:44:13] <szaydel> I have been trying to glean info with truss and dtrace, when I issue the commands, but seems some things are obscured because of doors.[17:44:50] <szaydel> I need to see if I have an effective way of figuring this out.[17:44:58] <rmustacc> It makes the calls to dlmngmtd which will make calls into the kernel.[17:45:09] <rmustacc> Which will check the number of active clients on the mac_t or the mac_client_t[17:45:12] <szaydel> Right, makes sense.[17:45:45] <szaydel> Is there a convenient dcmd in mdb to observe this?[17:45:50] <rmustacc> pringlescan: Ultimately we need a much more concerete understanding of what specific thing is failing.[17:46:18] *** wiedi has quit IRC[17:46:29] <pringlescan> I'm working 80 hours a week on integration, I'll have to stick to reboot scripts for now :-([17:46:54] <rmustacc> szaydel: ::walk mac_client_impl_cache | ::print mac_client_impl_t[17:46:58] <pringlescan> they keep shutting off the power while the network vendor tries to configure the switches, I can't catch a break on much of anything[17:47:08] <szaydel> rmustacc: Thanks, I am sure that'll help![17:47:32] <szaydel> Once I have something figured out, I shall report.[17:47:36] <pringlescan> dtrace would show the errors happening on the smartos side though[17:47:37] <rmustacc> szaydel: You also have ::walk mac_impl_cache | ::print mac_impl_t[17:47:58] <rmustacc> pringlescan: Yes, you could use that to see exactly which getsockopt and setsockopt was failing.[17:48:01] <szaydel> rmustacc: Cool, ty![17:48:16] <rmustacc> pringlescan: Given the original bug report you linked it's not clear that it's correctly getting the max buffer size.[17:49:06] *** pringlescan has quit IRC[17:57:10] *** mary5030 has joined #smartos[17:57:28] *** pringlescan has joined #smartos[17:57:46] *** pringlescan has quit IRC[17:58:54] <szaydel> rmustacc: These are fairly sizable data structures. What can I look at to quickly get a sense for what might be holding a nic busy?[18:02:23] *** mary5030 has quit IRC[18:02:53] *** cjones_ has quit IRC[18:02:56] *** mary5030 has joined #smartos[18:02:58] *** pringlescan has joined #smartos[18:06:51] *** dap has joined #smartos[18:09:39] *** cjones_ has joined #smartos[18:12:14] *** d[^_^]b has quit IRC[18:12:44] *** backjlack has quit IRC[18:13:47] *** d[^_^]b has joined #smartos[18:14:35] <szaydel> rmustacc: I am assuming that this field means that I have something else relying on this mac: mci_client_next = 0xffffff00c7968008\n mci_name = [ "aggr0" ] Even though, as far as I can tell, nothing is using it.[18:17:46] <szaydel> rmustacc: > ::walk mac_impl_cache | ::print mac_impl_t!grep 0xffffff00c7968008[18:17:47] <szaydel> mi_clients_list = 0xffffff00c7968008[18:17:47] <szaydel> mi_single_active_client = 0xffffff00c7968008[18:18:18] <szaydel> I think I need to figure out how to tell what this is: 0xffffff00c7968008.[18:21:10] <szaydel> I think a vnic was causing a problem. I will know shortly.[18:22:42] *** tbatchelli_ has joined #smartos[18:22:49] *** tbatchelli_m has quit IRC[18:23:07] <rmustacc> szaydel: mci_client_next just looks like a next pointer for a list.[18:23:20] <szaydel> I noticed some were 0.[18:23:31] <szaydel> Which I assumed means there is nothing down from them.[18:23:34] <rmustacc> Well, then I'm probably wrong.[18:24:26] <szaydel> I need to determine if I can even start to create an aggregate if a link is in a down state. I have a feeling that's another reason this was giving me busy on my other test system.[18:26:50] <szaydel> To me, this seems like an issue. These should be in unknown state, since they should be used by anything, but really are not. So, I have something to dig into atm. Will report what I see. e1000g1 phys 1500 up -- --[18:26:51] <szaydel> e1000g2 phys 1500 up -- --[18:28:03] <rmustacc> I don't know exactly what you're trying to look at with that.[18:28:29] <rmustacc> It'd help if you used something like pastebin, gist, etc. to more specifically include the command run and the output.[18:28:31] <szaydel> I am just saying that these two links should be in `unknown` state, since nothing should be using them.[18:28:51] <szaydel> They are not, so at least I know I have a real problem and not one I created by being stupid.[18:28:54] <rmustacc> From dladm show-phys?[18:29:02] <szaydel> dladm show-link.[18:29:13] <rmustacc> No reason for the link for the underlying datalink to be up.[18:29:31] <rmustacc> That's independent of having any IP interfaces plumbed over it.[18:29:47] <szaydel> As far as I recall, it used to be status was `unknown` if physical link existed, but nothing in the OS actually used the device.[18:30:19] <szaydel> Mainly, I mean it was not an aggregate or had vlan over it, etc.[18:30:39] <rmustacc> 'unknown' should be a bug.[18:30:39] <szaydel> Or, for that matter just plumbed with ifconfig.[18:30:44] <szaydel> Really?[18:31:03] <rmustacc> Yes, dladm show-phys kind of stuff should be able to tell you the status of the link without having anything active on it.[18:31:25] <rmustacc> eg. by plugging in a cable and having hardware negotiate, we should know the status of it.[18:31:33] <szaydel> I am talking about dladm show-link.[18:31:47] <szaydel> It does not report the same as show-phys as far as I know.[18:31:57] *** tbatchelli_ has quit IRC[18:32:37] <szaydel> This is what I am talking about: http://paste.ubuntu.com/6063244/[18:32:45] <rmustacc> STATE is the same in both.[18:32:54] <rmustacc> It's the state of the underlying datalink.[18:33:01] <szaydel> Yeah, you are right, makes sense.[18:33:02] <rmustacc> If you have a cable plugged in and negotiated it should be up.[18:33:27] <rmustacc> You shouldn't have to try to plumb an IP interface or other thing on top of it to figure that out.[18:33:56] <szaydel> Yeah, agreed. But, this is I am fairly convinced is how it has been for some time.[18:34:04] <szaydel> Have a look at that linky.[18:34:59] <szaydel> Then, once I create an aggregate: http://paste.ubuntu.com/6063255/[18:36:00] <rmustacc> Yeah, I consider that a bug in e1000g[18:36:19] *** pringlescan has quit IRC[18:37:10] <szaydel> Hmmm, well quite likely.[18:37:41] <szaydel> Then, when I try to create an aggregate with links I know are free, I get a busy: http://paste.ubuntu.com/6063271/[18:38:04] <szaydel> I am fairly sure I saw same with igb. Need to test.[18:38:57] *** tbatchelli_m has joined #smartos[18:39:43] <rmustacc> szaydel: I would not be surprised if that was the case.[18:39:57] <rmustacc> They come from common source code after all.[18:41:47] <szaydel> Yeah, agreed.[18:44:27] *** KermitTheFragger has quit IRC[18:58:38] *** FatDarrel has joined #smartos[19:01:15] *** pringlescan has joined #smartos[19:05:48] *** chorrell has quit IRC[19:08:15] *** pringlescan1 has joined #smartos[19:08:33] *** pringlescan has quit IRC[19:19:09] *** pringlescan1 has quit IRC[19:19:19] *** pringlescan has joined #smartos[19:41:02] *** patrickmslattery has joined #smartos[19:45:41] *** link0 has quit IRC[19:45:50] *** link0 has joined #smartos[19:51:33] *** noahmehl has joined #smartos[19:57:06] *** pringlescan has quit IRC[19:59:01] *** jaimef has quit IRC[20:01:37] *** chorrell has joined #smartos[20:03:51] *** chorrell has quit IRC[20:03:55] *** tbatchelli_m has quit IRC[20:04:18] *** jaimef has joined #smartos[20:16:37] *** chorrell has joined #smartos[20:17:16] *** jellydonut has quit IRC[20:18:26] *** tbatchelli_m has joined #smartos[20:21:21] *** tbatchelli_m has quit IRC[20:21:27] *** chorrell has quit IRC[20:23:51] *** jellydonut has joined #smartos[20:25:30] *** chorrell has joined #smartos[20:27:31] *** pringlescan has joined #smartos[20:27:31] *** chorrell has quit IRC[20:29:57] *** Teknix has quit IRC[20:32:17] *** Teknix has joined #smartos[20:34:12] *** chorrell has joined #smartos[20:34:36] *** utlemming has quit IRC[20:36:12] *** pringlescan has quit IRC[20:36:12] *** chorrell has quit IRC[20:36:39] *** cjones_ has quit IRC[20:37:14] *** utlemming has joined #smartos[20:37:37] *** tbatchelli_m has joined #smartos[20:41:33] *** chorrell has joined #smartos[20:44:03] *** chorrell has quit IRC[20:48:42] *** tbatchelli_m has quit IRC[20:49:10] *** chorrell has joined #smartos[20:51:14] *** chorrell has quit IRC[20:54:59] *** pringlescan has joined #smartos[20:59:39] *** chorrell has joined #smartos[21:02:03] *** chorrell has quit IRC[21:03:22] <pringlescan> no smf for isc-dhcp?[21:03:41] <pringlescan> https://gist.github.com/AlainODea/6321603 … naturally[21:04:34] <rmustacc> pringlescan: With the enabling of every package versus ones we have done work with, they don't all have a manifest.[21:06:45] *** chorrell has joined #smartos[21:09:15] *** chorrell has quit IRC[21:14:07] *** chorrell has joined #smartos[21:15:43] *** pringlescan1 has joined #smartos[21:15:43] *** chorrell has quit IRC[21:16:30] *** pringlescan has quit IRC[21:16:55] *** dap has quit IRC[21:18:13] *** pringlescan has joined #smartos[21:19:40] <jperkin> please submit any you generate, though - I'm working on finally getting the SMF stuff in upstream so that they can go direct into pkgsrc, and any we have beforehand will go in at the same time[21:20:24] *** pringlescan1 has quit IRC[21:22:30] *** pringlescan1 has joined #smartos[21:22:51] *** pringlescan has quit IRC[21:23:19] *** backjlack has joined #smartos[21:25:37] *** chorrell has joined #smartos[21:27:23] *** khushildep has joined #smartos[21:27:24] *** chorrell has quit IRC[21:32:57] *** chorrell has joined #smartos[21:35:03] *** chorrell has quit IRC[21:35:59] *** nikolam has quit IRC[21:38:20] *** enmand has quit IRC[21:40:40] *** enmand has joined #smartos[21:41:35] *** chorrell has joined #smartos[21:41:40] *** cjones_ has joined #smartos[21:42:21] *** pringlescan1 has quit IRC[21:43:42] *** chorrell has quit IRC[21:48:52] *** chorrell has joined #smartos[21:51:15] *** chorrell has quit IRC[21:57:03] *** chorrell has joined #smartos[21:57:07] *** potatosalad has quit IRC[21:59:39] *** chorrell has quit IRC[21:59:55] *** julianduque has joined #smartos[22:03:54] *** chorrell has joined #smartos[22:05:32] *** deirdres has joined #smartos[22:05:32] *** chorrell has quit IRC[22:06:27] *** pringlescan has joined #smartos[22:10:26] *** chorrell has joined #smartos[22:12:24] *** Fuzai_ is now known as Fuzai[22:12:24] *** chorrell has quit IRC[22:17:29] *** dap has joined #smartos[22:18:56] *** chorrell has joined #smartos[22:20:46] *** mary5030_ has joined #smartos[22:20:46] *** chorrell has quit IRC[22:21:30] *** elijah-mbp has quit IRC[22:21:40] *** dap has quit IRC[22:23:36] *** elijah-mbp has joined #smartos[22:23:56] *** mary5030 has quit IRC[22:26:03] *** ilovezfs has quit IRC[22:26:55] *** ilovezfs has joined #smartos[22:27:26] *** chorrell has joined #smartos[22:28:26] *** elijah-mbp has quit IRC[22:29:39] *** chorrell has quit IRC[22:29:40] *** tbatchelli_m has joined #smartos[22:30:26] *** cjones_ has quit IRC[22:31:20] *** elijah-mbp has joined #smartos[22:33:43] *** mamash has left #smartos[22:42:22] <joshie> what is equivilent to installing SUNWuiu8 and SUNWulcf packages in a smartos zone[22:42:56] *** noahmehl has quit IRC[22:43:46] *** potatosalad has joined #smartos[22:44:01] *** noahmehl has joined #smartos[22:44:41] *** nikolam has joined #smartos[22:47:44] *** mary5030_ has quit IRC[22:48:14] *** dap has joined #smartos[22:55:20] <wesolows> joshie: 64-bit program?[22:56:32] <wesolows> if so, OS-2412, fixed in the August 8 SmartOS platform release.[22:56:38] *** bens1 has quit IRC[22:58:36] <joshie> :) I hope this machine is configured to reboot correctly[22:58:44] <joshie> thanks for that[22:59:10] <joshie> oh crap im doing a data transfer to another zone i really don't want to kill[22:59:30] <wesolows> Sorry. Unfortunately there's no good way to live-patch the fix into a running system.[23:01:01] <joshie> ill just set the zone up on another system and transfer it later[23:03:37] *** elijah-mbp has quit IRC[23:13:29] *** elijah-mbp has joined #smartos[23:22:56] *** mgls has joined #smartos[23:36:41] <konobi> how do folks work around the which_scm issue during clean builds? just have a local copy in their PATH?[23:39:04] *** pringlescan has quit IRC[23:39:14] *** pringlescan has joined #smartos[23:42:44] *** emocakes has joined #smartos[23:43:11] <rmustacc> konobi: Can you be a little more specific?[23:43:37] <rmustacc> I'm not sure what your actual problem is.[23:44:37] <konobi> during the build it bails out in the nightly script as it's unable to find 'which_scm' relative to t nightly script location or in $PATH[23:45:03] <rmustacc> We do no workarounds from what we've documented for building.[23:45:26] <rmustacc> So if nightly is failing, it's not exiting zero.[23:46:34] <konobi> yup, exit code 1[23:46:52] <rmustacc> We never see that.[23:47:13] <rmustacc> So can you find the first error in your nightly.log?[23:47:23] <konobi> k... if i run gmake world again, it goes on ahead[23:47:44] <rmustacc> It sounds like which_scm is not your problem and something else is.[23:47:46] *** andy_js has quit IRC[23:47:53] <rmustacc> Can you make your entire nightly.log available somewhere?[23:48:20] <konobi> yup[23:50:14] <konobi> konobi.co.uk/nightly.log.gz[23:51:08] <rmustacc> Your first error isn't related to ws_type at all.[23:51:29] <rmustacc> Sorry, I mean which_scm.[23:51:38] <rmustacc> nightly tries really hard to keep making forward progress.[23:51:44] <richlowe> I told you man, which_scm isn't why things bomb.[23:51:54] <richlowe> it's the smartos illumos build being misguided[23:52:05] <rmustacc> Go to line 97495[23:52:18] <rmustacc> It's specifically something stale in perl[23:54:20] <konobi> ta[23:55:48] *** deirdres_ has joined #smartos[23:58:20] *** potatosalad has quit IRC[23:58:31] <konobi> investigating[23:58:38] *** deirdres has quit IRC[23:58:39] *** deirdres_ is now known as deirdres[23:58:48] *** chorrell has joined #smartos