Switch to DuckDuckGo Search
   September 10, 2019
< | 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

Toggle Join/Part | bottom
[00:00:45] <richlowe> pretty sure if it's a real svr4 it should be in the manual there, too.
[00:00:56] <richlowe> whether you have one of those too, though, harder to guess.
[00:01:50] <richlowe> I think Stevens mentions it somewhat too
[00:01:53] <mackbw> I haven't seen anything about TRANSPARENT ioctl in the source. I've been searching through the Unix System Labs book on streams. It's all very similar. Looking through the Solaris stuff, looks like some common sequences of calls got combined into a single function calls.
[00:02:27] <richlowe> there was a book about the SVr4 design/implementation in general too, but I can't remember it's name.
[00:04:51] <richlowe> rmustacc: I thought the streamy thing with ioctls was they got turned into messages containing the data, and passed downstream?
[00:06:45] <rmustacc> richlowe: Only transparent ioctls get messages with the data automatically.
[00:06:55] <rmustacc> Otherwise you have to build up a state machine and do it yourself.
[00:07:55] <mackbw> A stream is a bidirectional pipe (two queues) - there's a down stream (write direction as looking from user space), and an upstream (read direction). But with TCGETS and TIOCMGET, the address of the argument is passed back up the write queue of the stream.
[00:08:19] <copec> This link working for anyone? http://www.bitsavers.org/pdf/att/unix/System_V_Release_4/
[00:08:57] <copec> It be gone Fred.
[00:09:08] <mackbw> I was able to view the index...
[00:09:20] <alanc> richlowe: thinking of https://www.amazon.com/Magic-Garden-Explained-Internals-Release/dp/0130981389 ?
[00:09:43] <richlowe> alanc: yes!
[00:09:46] <mackbw> copec, that link worked for me.
[00:09:49] <richlowe> copec: that's exactly the streams manual I meant.
[00:10:06] <richlowe> for mackbw, and probably the packaging manual mackbw meant for you :)
[00:11:20] <alanc> Solaris SVR4-style packages have a bunch of extensions over the AT&T/USL original if that matters for whatever you're doing
[00:11:59] <richlowe> like names more than 8 chars long
[00:12:03] <richlowe> not that you'd notice
[00:13:02] <mackbw> lol "Magic Garden Explained," must have been written by a BSD guy.
[00:15:28] *** _Joes_ <_Joes_!~BH23@santoroj.plus.com> has quit IRC (Ping timeout: 245 seconds)
[00:17:41] <copec> I sync'd it to https://unaen.org/System_V_Release_4/ for myself because I can't reach them from my centurylink connection
[00:18:08] *** user888 <user888!~user888@pool-96-242-225-247.nwrknj.fios.verizon.net> has quit IRC (Ping timeout: 268 seconds)
[00:18:55] <richlowe> LeftWing: is the sparc alive and working for builds yet?
[00:18:58] <mackbw> I hope there's something good in there for you copec.
[00:19:54] <LeftWing> richlowe: It is certainly alive, but I'm not sure Peter and Rob have managed to get a build to work on it yet
[00:20:18] <copec> It will be interesting to learn my roots
[00:20:31] <richlowe> "interesting times" interesting, largely.
[00:21:36] <copec> I wish someone would manufacture opensparc T2s with modern fabs to be like alt-ARM board
[00:22:20] <richlowe> Gotta giggle at riscv and openpower though
[00:22:26] <richlowe> Sun really did do everything first, badly.
[00:23:07] <dsockwell> heh
[00:23:13] *** merzo <merzo!~merzo@93-46-133-95.pool.ukrtel.net> has quit IRC (Ping timeout: 246 seconds)
[00:24:53] <copec> Is anyone caring about illumos on ARM these days?
[00:25:36] <copec> I get the impression most devs are being paid and have their nose to the grindstone
[00:26:27] <copec> and so far I've only ever been on the receiving end of many peoples efforts :-P
[00:28:29] <mackbw> I'd like to thank all of you for the help... I will keep banging my fingers against the keyboard - when things get desperate, I'll try my head.
[00:37:04] *** merzo <merzo!~merzo@117-59-132-95.pool.ukrtel.net> has joined #illumos
[01:00:28] *** clapont <clapont!~clapont@unaffiliated/clapont> has quit IRC (Ping timeout: 245 seconds)
[01:14:40] <Reinhilde> Why does pfexec make zsh think it's running as root?
[01:21:31] *** amrfrsh <amrfrsh!~Thunderbi@190.2.145.106> has quit IRC (Quit: amrfrsh)
[01:21:47] *** gwr <gwr!~gwr@151.203.114.175> has quit IRC (Quit: This computer has gone to sleep)
[01:23:05] *** user888 <user888!~user888@pool-96-242-225-247.nwrknj.fios.verizon.net> has joined #illumos
[01:31:01] *** idodeclare <idodeclare!~textual@cpe-76-185-177-63.satx.res.rr.com> has joined #illumos
[02:14:50] <tomww> profiles -l as that user might reveal that there is some elevated rights defined in /etc/user_attr and /etc/security/**
[02:17:00] <tomww> but "make" should not be in profiles ...
[02:17:28] *** mackbw <mackbw!493d113c@73.61.17.60> has left #illumos
[02:18:08] <tomww> oh well...
[02:18:09] <tomww> kommandant tom /etc/security ggrep -r make
[02:18:10] <tomww> exec_attr.d/core-os:Mail Management:solaris:cmd:RO::/usr/sbin/makemap:euid=0
[02:18:10] <tomww> exec_attr.d/core-os:Software Installation:solaris:cmd:RO::/usr/ccs/bin/make:euid=0
[02:19:44] <tomww> so it might be /usr/ccs/bin/make that is run as UID=0 then.
[02:52:50] *** user888 <user888!~user888@pool-96-242-225-247.nwrknj.fios.verizon.net> has quit IRC (Ping timeout: 276 seconds)
[03:02:07] *** Teknix <Teknix!~pds@69.41.134.110> has quit IRC (Ping timeout: 246 seconds)
[03:02:46] *** Teknix <Teknix!~pds@69.41.134.110> has joined #illumos
[03:20:00] *** ed209 <ed209!~ed209@165.225.128.67> has quit IRC (Remote host closed the connection)
[03:20:07] *** ed209 <ed209!~ed209@165.225.128.67> has joined #illumos
[03:53:53] *** jcea <jcea!~Thunderbi@2001:41d0:1:8a82:7670:6e00:7670:6e00> has quit IRC (Quit: jcea)
[04:00:20] *** baojg <baojg!~baojg@162.243.44.213> has joined #illumos
[04:08:42] <richlowe> why are you doing pfexec make if you're not trying to elevate some priv?
[04:08:57] *** user888 <user888!~user888@pool-96-242-225-247.nwrknj.fios.verizon.net> has joined #illumos
[04:09:07] <richlowe> also you can pfexec -P..., if you only want certain ones for that invocation)
[04:10:01] <richlowe> though I don't think you can opt out of profiles that way
[04:10:21] <Reinhilde> richlowe: same reason one would use sudo
[04:11:21] <richlowe> But the point of using sudo would be to elevate your privs and become root for that invocation?
[04:12:07] <richlowe> what am I missing?
[04:47:45] *** idodeclare <idodeclare!~textual@cpe-76-185-177-63.satx.res.rr.com> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…)
[04:51:28] *** idodeclare <idodeclare!~textual@cpe-76-185-177-63.satx.res.rr.com> has joined #illumos
[05:08:26] *** mutin-sa <mutin-sa!~s-mutin@85.234.114.134> has quit IRC (Read error: Connection reset by peer)
[05:09:54] *** mutin-sa <mutin-sa!~s-mutin@85.234.114.134> has joined #illumos
[05:14:12] *** MilkmanDan <MilkmanDan!~dan@wilug/expat/MilkmanDan> has quit IRC (Ping timeout: 245 seconds)
[05:16:18] *** MilkmanDan <MilkmanDan!~dan@wilug/expat/MilkmanDan> has joined #illumos
[05:23:00] *** idodeclare <idodeclare!~textual@cpe-76-185-177-63.satx.res.rr.com> has quit IRC (Read error: Connection reset by peer)
[05:29:09] *** idodeclare <idodeclare!~textual@cpe-76-185-177-63.satx.res.rr.com> has joined #illumos
[05:41:43] *** idodeclare <idodeclare!~textual@cpe-76-185-177-63.satx.res.rr.com> has quit IRC (Ping timeout: 245 seconds)
[05:45:07] *** idodeclare <idodeclare!~textual@cpe-76-185-177-63.satx.res.rr.com> has joined #illumos
[06:17:50] *** idodeclare <idodeclare!~textual@cpe-76-185-177-63.satx.res.rr.com> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…)
[06:22:40] *** Riastradh <Riastradh!~riastradh@netbsd/developer/riastradh> has quit IRC (Ping timeout: 246 seconds)
[06:23:25] *** Riastradh <Riastradh!~riastradh@netbsd/developer/riastradh> has joined #illumos
[07:20:15] *** user888 <user888!~user888@pool-96-242-225-247.nwrknj.fios.verizon.net> has quit IRC (Ping timeout: 246 seconds)
[07:23:44] *** clapont <clapont!~clapont@unaffiliated/clapont> has joined #illumos
[07:36:27] <tsoome> richlowe: thats the modern world, where people seem to think that every unix command starts with sudo…
[07:38:26] <Reinhilde> tsoome: only the ones that require root start with pfexec, sudo or doas
[07:38:55] <tsoome> indeed;)
[07:51:05] *** yuripv_ is now known as yuripv
[08:04:20] *** amrfrsh <amrfrsh!~Thunderbi@190.2.145.106> has joined #illumos
[08:04:26] *** amrfrsh <amrfrsh!~Thunderbi@190.2.145.106> has quit IRC (Client Quit)
[08:09:13] *** yuripv is now known as yuripv_
[08:09:35] *** yuripv_ is now known as yuripv
[08:30:03] <Reinhilde> reached memory exhaustion attempting to compile php73 from pkgsrc
[08:33:08] <Reinhilde> is there a problem inherent in swap on zfs?
[08:35:36] <rmustacc> No. But there's no overcommit by default.
[08:35:58] <rmustacc> This can be rather easy to hit if you're doing large parallel compilations.
[08:37:08] <tsoome> Reinhilde: hos large is yourswap?
[08:37:16] <tsoome> how*
[08:37:31] <Reinhilde> tsoome: 1 mb larger than physical RAM
[08:37:37] <tsoome> .oO sorry, the morning coffee is still about to kick in:)
[08:37:46] <tsoome> and RAM?
[08:37:53] <Reinhilde> 1023MB
[08:38:11] <tsoome> ah, yes, you can add plenty more swap
[08:38:54] <rmustacc> So, we always guarantee virtual memory a place to go as there's no OOM killer.
[08:39:12] <tsoome> the thing with /tmp (tmpfs) is that files there are using virtual memory (ram+swap) and storing large files there will cause problems
[08:39:33] <rmustacc> This means that a program that requests say 1 GiB of anonymous memory, will have 1 GiB charged, even if it doesn't use it all.
[08:39:56] <rmustacc> I had a small VM where I forgot to tune done the make job count and it was pretty easy to hit while building gcc.
[08:40:41] <Reinhilde> wow
[08:41:45] <Reinhilde> why would there not be an OOM killer? seems a very easy way to DoS the system
[08:42:01] <tsoome> oomkiller is doing the same DoS
[08:42:29] <tsoome> I had linux installer killing itself before it was able even to start ...
[08:42:52] <Reinhilde> explains why you use solaris nowadays doesn't it haha
[08:43:10] <Reinhilde> oomkiller does do a DoS but at least it unlocks the system without you having to go to the datacentre and actually put a pencil in the Reset button.
[08:43:15] <tsoome> I have used SunOS since 1993
[08:43:45] <tsoome> And, I have to say, I have *never* missed oomkiller.
[08:43:45] <Reinhilde> that is, as long as PID 1 ensures that sshd or rshd remains running
[08:52:45] *** alanc <alanc!~alanc@129.157.69.38> has quit IRC (Remote host closed the connection)
[08:53:13] *** alanc <alanc!~alanc@129.157.69.38> has joined #illumos
[09:00:14] *** tsoome <tsoome!~tsoome@148-52-235-80.sta.estpak.ee> has quit IRC (Quit: tsoome)
[09:02:10] *** amrfrsh <amrfrsh!~Thunderbi@131.234.43.140> has joined #illumos
[09:10:32] <Reinhilde> rmustacc: so should I add a whole 10gb of swap space?
[09:16:04] *** nexgen2 <nexgen2!~nexgen@144.172.68.147> has joined #illumos
[09:17:15] *** nexgen2 <nexgen2!~nexgen@144.172.68.147> has quit IRC (Remote host closed the connection)
[09:35:45] *** snuff-work <snuff-work!~snuff-wor@202-161-112-134.tpgi.com.au> has quit IRC (Quit: Leaving.)
[09:37:36] *** andy_js <andy_js!~andy@94.12.192.123> has joined #illumos
[09:47:15] *** wiedi <wiedi!~wiedi@ip5b4096a6.dynamic.kabel-deutschland.de> has joined #illumos
[09:50:04] *** wiedi_ <wiedi_!~wiedi@2a01:138:a015:15:dc29:71d:a645:470e> has quit IRC (Ping timeout: 252 seconds)
[09:58:28] *** andy_js <andy_js!~andy@94.12.192.123> has quit IRC (Read error: No route to host)
[09:59:48] *** andy_js <andy_js!~andy@94.12.192.123> has joined #illumos
[10:03:15] *** amrfrsh <amrfrsh!~Thunderbi@131.234.43.140> has quit IRC (Ping timeout: 240 seconds)
[10:05:38] *** amrfrsh <amrfrsh!~Thunderbi@131.234.43.140> has joined #illumos
[10:26:04] *** man_u <man_u!~manu@manu2.gandi.net> has joined #illumos
[10:47:33] *** vila <vila!~vila@2a01:e35:2e63:5f40:689d:7ae4:35d4:cac5> has quit IRC (Ping timeout: 250 seconds)
[10:52:06] *** cartwright <cartwright!~chatting@gateway/tor-sasl/cantstanya> has quit IRC (Remote host closed the connection)
[10:54:23] *** cartwright <cartwright!~chatting@gateway/tor-sasl/cantstanya> has joined #illumos
[10:59:59] *** vila <vila!~vila@2a01:e35:2e63:5f40:7016:4209:2762:de32> has joined #illumos
[11:09:47] <jlevon> andyf: ping
[11:10:02] <andyf> jlevon, pong
[11:10:30] <jlevon> hey. are you sure we really want reboot-needed for the build file? won't that mean that every new commit made to illumos-gate results in a new BE?
[11:10:58] <jlevon> I'm trying to remember the implications of that flag
[11:11:48] <andyf> That's the right implication - file updated => new BE
[11:12:03] <andyf> but I'm not sure I was thinking completely clearly..
[11:12:36] <andyf> ah, I remember
[11:12:52] <andyf> If the file is updated, the kernel won't load the new contents until there is a reboot
[11:13:01] <jlevon> right
[11:13:05] <jlevon> but that seems correct to me
[11:13:16] <jlevon> since the kernel that's running really is based off the old cset?
[11:13:16] <andyf> so if I update the file, don't I want to make sure it's updated in crash dumps etc?
[11:15:21] <jlevon> I'd say no sfor the above two reasons? Although we are likely talking irrelevancies anyway because of the package it lives in. we'll never get a new SUNWcs without reboot-needed indirectly anyway
[11:17:16] <andyf> I was probably working through the OmniOS release process in my head.
[11:17:29] <andyf> We only push out a new SUNWcs along with system/kernel etc. and a reboot update by definition
[11:17:54] <Reinhilde> What is sunwcs?
[11:17:56] <jlevon> yep. this could only really matter if we started delivering the build file in its own package.
[11:17:59] <andyf> We do sometimes use partial SUNWcs updates fwiw
[11:18:06] <andyf> such as to just update /etc/motd
[11:18:29] <andyf> Reinhilde, it's the "core system" software package
[11:18:30] <jlevon> but I still think it's fine for the userspace to not necessarily match the kernel-ingested version, as long as genunix/unix always match what got ingested.
[11:18:57] <Reinhilde> Why does it remain called "sunwcs"?
[11:19:06] <andyf> jlevon, yes you're right, please ignore my previous comment via email
[11:20:03] *** amrfrsh <amrfrsh!~Thunderbi@131.234.43.140> has quit IRC (Ping timeout: 245 seconds)
[11:20:10] <andyf> jlevon, It depends on what ends up in that file - in the future OmniOS might have a service that builds it from fragments under /etc/versions/ delivered in different packages, but that isn't directly relevant to this initial change and what is intended to be in the build file
[11:20:33] <andyf> Reinhilde, most likely because nobody has invested the time to change it
[11:20:45] <jlevon> andyf: yeah that's true. re-evaluate then as needed?
[11:20:52] <jlevon> andyf: you're +1 right now?
[11:21:10] <andyf> jlevon, yes. I'll send an email to the list.
[11:21:15] <jlevon> thanks.
[11:22:08] <Reinhilde> Would it not nowadays be apt to call SUNWcs something like illucs?
[11:22:18] <Reinhilde> Though idk what the w stands for
[11:22:27] <andyf> Probably something like system/core
[11:22:49] <Reinhilde> SUN is obviously Sun Microsystems
[11:23:19] <andyf> SUNW was the stock tag for Sun Microsystems
[11:23:29] <Agnar> SUN Workstations
[11:23:35] <Reinhilde> so SUNW stands for Sun
[11:23:40] <Reinhilde> That's... Fun.
[11:23:43] <Agnar> as sun primarily built workstations in the beginning
[11:24:11] <Reinhilde> What's oracle's stock tag?
[11:24:29] <Agnar> sun changed it later to JAVA btw
[11:24:36] <Reinhilde> ... lol
[11:24:53] <Reinhilde> imagine if they had renamed SUNWcs to JAVAcs
[11:25:09] <Reinhilde> some people would be very confused, others would giggle heartily
[11:25:18] <Agnar> no way, that would have been to expensive to take care for all the dependencies
[11:25:29] <andyf> and others would refuse to install it out of principle :p
[11:26:05] <Reinhilde> Does Joyent sell shares?
[11:26:36] <andyf> Over the years, several things have been taken out of SUNWcs and moved into new packages. There isn't a great deal left in there
[11:27:14] <Agnar> oh, it used to be SUNWcsr and SUNWcsu earlier
[11:27:28] <Agnar> (core solaris root, core solaris usr)
[11:28:25] <gitomat> [illumos-gate] 11581 'debug' loader option is a little obscure -- John Levon <john.levon at joyent dot com>
[11:38:02] *** merzo <merzo!~merzo@117-59-132-95.pool.ukrtel.net> has quit IRC (Ping timeout: 276 seconds)
[11:40:55] *** steph <steph!steph@minos.ber.rdev.info> has quit IRC (Quit: quit)
[11:41:26] *** steph <steph!steph@minos.ber.rdev.info> has joined #illumos
[12:12:32] *** tsoome_ <tsoome_!~tsoome@148-52-235-80.sta.estpak.ee> has joined #illumos
[12:20:00] *** ed209 <ed209!~ed209@165.225.128.67> has quit IRC (Remote host closed the connection)
[12:20:07] *** ed209 <ed209!~ed209@165.225.128.67> has joined #illumos
[12:25:19] *** amrfrsh <amrfrsh!~Thunderbi@131.234.43.140> has joined #illumos
[12:31:45] *** amrfrsh <amrfrsh!~Thunderbi@131.234.43.140> has quit IRC (Ping timeout: 246 seconds)
[12:34:49] *** tsoome_ <tsoome_!~tsoome@148-52-235-80.sta.estpak.ee> has quit IRC (Quit: tsoome_)
[13:07:58] *** jimklimov <jimklimov!~jimklimov@ip-86-49-254-64.net.upcbroadband.cz> has joined #illumos
[13:29:55] <Reinhilde> so wouldn't it be JYNTci nowadays? :P
[13:32:50] <Reinhilde> also, if you're doing any weird shit with openssl as I am, you are going to become friends with hacks such as putting -L/path/to/alternative/openssl/lib in the CC/CCLD variable of makefiles instead of just putting it immediately before -lssl.
[13:33:08] <Reinhilde> move it right to the front of the line so there's no confusion where you want to search first.
[13:39:40] *** tsoome <tsoome!~tsoome@148-52-235-80.sta.estpak.ee> has joined #illumos
[13:45:07] <Reinhilde> tsoome: so the darn system locked up on me again
[13:50:08] <tsoome> did you enlarge swap?:)
[13:52:37] <Reinhilde> tsoome: yes, and it still locked up
[13:52:43] <Reinhilde> upon starting, of all things, an IRC client.
[13:53:56] <Reinhilde> tsoome: failed to allocate memory for DMA in vioblk
[13:54:36] *** Kurlon <Kurlon!~Kurlon@cpe-67-253-141-249.rochester.res.rr.com> has quit IRC (Ping timeout: 268 seconds)
[13:56:19] <Reinhilde> is there anything I can tweak to make it so that illumos sees a memory crisis at a MUCH higher free memory level?
[13:58:42] *** amrfrsh <amrfrsh!~Thunderbi@131.234.43.140> has joined #illumos
[13:59:14] <Reinhilde> this might be connected to my lockup problem.
[13:59:16] <Reinhilde> Sep 10 04:38:44 perihelion.nj.us.umbrellix.net virtio: [ID 218522 kern.warning] WARNING: vioblk0: DMA memory allocation failed (ffffffff)
[14:04:15] <Reinhilde> tsoome: ^
[14:05:37] <Reinhilde> basically, it runs out of memory, because irssi tries to allocate 4gb of ram (the machine only has a sliver under 1gb of ram)
[14:05:54] <Reinhilde> and because it's run out of memory, it can't allocate memory for the disk driver to work
[14:06:44] <Reinhilde> result: because there's no OOM killer that runs about, I have to go into the datacentre and pencil the Reset button (or, in this case, do the virtual machine equivalent).
[14:07:40] *** jellydonut <jellydonut!~quassel@s91904425.blix.com> has joined #illumos
[14:07:53] *** merzo <merzo!~merzo@ll-202.208.223.85.sovam.net.ua> has joined #illumos
[14:09:45] *** tsoome <tsoome!~tsoome@148-52-235-80.sta.estpak.ee> has quit IRC (Quit: tsoome)
[14:09:54] <Reinhilde> and then seconds start counting up in 5s on the system clock.
[14:10:07] *** gh34 <gh34!~textual@cpe-184-58-181-106.wi.res.rr.com> has joined #illumos
[14:15:27] <igork> Reinhilde: virtio framework was updated by LeftWing and probably need try to debug it/ what is base platform of virtualization where you try to use virtio on illumos?
[14:17:05] <Reinhilde> nevermind, turns out you actually can't run anything that uses Glib on illumos because it tries to allocate 4 gigabyte of ram and I don't even have 1
[14:17:43] <yuripv> O_o
[14:18:16] <yuripv> well, you must already have dbus/hald running, and those are linked to glib, so it's simply not true
[14:18:49] <Reinhilde> you may or may not be right
[14:22:27] *** merzo <merzo!~merzo@ll-202.208.223.85.sovam.net.ua> has quit IRC (Ping timeout: 240 seconds)
[14:26:51] <Agnar> why the heck should anything simple glib app alloc 4G of mem? btw. alloc would succeed, but not calloc() (which would on linux and BSDs)
[14:27:40] <Reinhilde> Agnar: whatever happened, the machine crashed because any system calls had a chance to return. I had to pencil the reset button to unlock the machine.
[14:28:47] <Agnar> Reinhilde: sure, but a panic should result in a reset
[14:30:07] <Reinhilde> Agnar: I guess seize is a better word than crash
[14:30:37] <Reinhilde> but the result, for the user, is the same, if the crash does not reset the machine - they have to go into the datacentre and pencil the reset button themselves.
[14:31:10] <Agnar> Reinhilde: sure, so: for lockups we have the kernel watchdog (set snooping=1 in /etc/system)
[14:31:58] <Agnar> Reinhilde: for excessive memory usage rendering the machine unusable, we have rcapd to put memory caps on processes and/or zones
[14:41:51] *** tsoome <tsoome!~tsoome@148-52-235-80.sta.estpak.ee> has joined #illumos
[14:43:42] *** jimklimov <jimklimov!~jimklimov@ip-86-49-254-64.net.upcbroadband.cz> has quit IRC (Ping timeout: 246 seconds)
[14:43:56] <tsoome> Reinhilde: uh, 4GB?!
[14:44:30] <Reinhilde> tsoome: yes, 4gb
[14:44:36] <Reinhilde> 1<<32
[14:44:56] <patdk-lap> hmm, lots of apps can alloc a lot more than 4gb
[14:45:01] <Reinhilde> but yeah turns out you cannot run irssi on illumos because it allocs 4gb
[14:45:18] <tsoome> Reinhilde: if thats really the case, then you just need to make sure you have at least say, 8GB of swap space.
[14:45:19] <Reinhilde> I'm at a stage where I'm surprised anything works
[14:45:31] <Reinhilde> tsoome: i have 11gb of swap space, and without setting resource limits, the machine still hangs.
[14:45:33] <Agnar> Reinhilde: which is funny, because I run irssi on illumos
[14:45:34] <patdk-lap> lots of people get pretty lazy and hardcode caps
[14:45:51] <patdk-lap> like instead of dynamically allocating an array, they will allocate a set amount that is *more than enough*
[14:46:02] <Reinhilde> Agnar: how much physical RAM (not swap) do you have?
[14:46:40] <tsoome> Reinhilde: if you run vmstat 1 for some time, what values from SR column you see?
[14:46:49] * jperkin checks current memory usage of this very irssi process on illumos, connected to multiple networks and channels: 22M/15M
[14:47:03] <Agnar> Reinhilde: I used to run it on a zone with 2G
[14:47:21] <Reinhilde> jperkin: i must have done something wrong
[14:47:22] <Agnar> jperkin: reinhilde suspects an issue with large alloc()
[14:47:28] <jperkin> clearly ;)
[14:47:55] <Reinhilde> tsoome: is there a way to tabulate the output of vmstat so that I'm not forced to go psychotic trying to figure out what SR is
[14:48:13] <tsoome> yes, you can pass it to awk :)
[14:48:31] <Reinhilde> ...
[14:48:37] <tsoome> or cut:)
[14:48:40] <Reinhilde> alternatively, I could just put a bullet in my skull.
[14:48:52] <tsoome> it is unix, use those small tools you have:)
[14:50:09] <tsoome> anyhow, 4G clearly hints about some sort of bug, smells awfully like leak. and fortunately we do have option how to detect leaks:)
[14:50:17] <Reinhilde> vmstat's output is more readable raw
[14:50:55] <Agnar> Reinhilde: vmstat 1 10 | nawk '{print $12}'
[14:51:22] <Reinhilde> Agnar: that works
[14:51:29] <Agnar> btw, sar(1M) has a nice output
[14:51:43] <Agnar> check sar -g 1 10
[14:52:09] <Reinhilde> so you just want me to run irssi until I have to safeword out and then tell you waht I get in the SR column?
[14:52:50] <Agnar> Reinhilde: have you already tried to cap down irssi to let's say 200M?
[14:53:09] <Reinhilde> Agnar: I set a ulimit -v of 500000 and that prevented irssi from starting *at all*
[14:53:18] <Reinhilde> which is good because it means I did not need to deal with it crashing my system.
[14:53:35] <Reinhilde> https://umbrellix.net/~ellenor/srbloat.txt
[14:54:25] <Agnar> erm, probably the vmstat output got garbled by combining two columns
[14:54:40] *** Kurlon <Kurlon!~Kurlon@bidd-pub-03.gwi.net> has joined #illumos
[14:54:50] <Reinhilde> oh?
[14:55:19] <Agnar> Reinhilde: see, the numbers look way too high
[14:56:11] <Reinhilde> Agnar: they look impossible
[14:56:29] <Reinhilde> Agnar: but reload the file
[14:56:34] <Reinhilde> and you will see SAR's version of events
[14:57:12] <Agnar> oh, you do paging
[14:57:12] <Reinhilde> Agnar: since you seem to be doing the impossible, why don't you tell me what you did?
[14:57:28] <Agnar> irssi -n Agnar
[14:57:48] <Reinhilde> which on my system requires me to pencil the Reset button to get a shell prompt.
[14:57:54] <Agnar> $ vmstat -s | grep swap
[14:58:02] <Agnar> ?
[14:58:23] <Reinhilde> what is that meant to tell me?
[14:58:24] <Agnar> and swap -s please
[14:58:46] <Agnar> if and how active your system swaps
[14:58:59] <Reinhilde> reload srbloat.txt again, i have appended exactly that infgo
[14:59:01] <andyf> @danmcd, has 11634 fallen through the cracks between your broken and temporary laptop?
[14:59:11] <danmcd> lemme look...
[14:59:13] <andyf> or is there something outstanding :)
[14:59:42] <Agnar> Reinhilde: you are already running out of memory, your system swaps, i.e. there is not enough memory available
[15:00:04] <danmcd> Fuck.... I didn't keep it marked as unread in my inbox (my signal for finish-this-RTI-up).
[15:00:28] <Agnar> Reinhilde: what does sar -r 1 10 show?
[15:02:09] <Reinhilde> Agnar: reload the file again (I changed the 10 to 99999 for reasons)
[15:02:41] <danmcd> @andyf --> addressed.
[15:02:50] <danmcd> Meanwhile I've a BIG wad to look at this morning.
[15:02:57] <Reinhilde> in the middle there, I spam the system with Ctrl-C to arrest its decline into dementia
[15:04:10] <tsoome> the vmstat sr column is scan rate, it is telling you how much the system is searching for free pages, if it is constantly >0, you should starting to look to increase the RAM.
[15:04:11] <andyf> danmcd, thanks - I'm waiting on that one before my big kayak update
[15:04:33] <danmcd> Meanwhile, TRIM/UNMAP for ZFS is in the RTI queue now...
[15:04:43] <Reinhilde> tsoome: in steady state it is zero
[15:04:44] <tsoome> and installboot?:)
[15:04:51] <Agnar> Reinhilde: so, you have around 500M free mem, until you start irssi. have you already tried moving your ~/.irssi to another location to do a fresh start?
[15:04:53] <andyf> I saw.. do you know which version of TRIM we're getting?
[15:05:06] <Reinhilde> Agnar: my ~/.irssi is COMPLETELY EMPTY.
[15:05:13] <Reinhilde> This is an install as clean as the driven snow.
[15:05:13] <Agnar> Reinhilde: ok
[15:05:23] <Reinhilde> as far as irssi is concerned.
[15:05:41] <danmcd> andyf: https://www.illumos.org/rb/r/2278/
[15:06:03] <Reinhilde> by the way, gdb won't compile, so I can't get anyone from #irssi a backtrace since that is what THEY want
[15:06:27] <Agnar> Reinhilde: use mdb in that case
[15:06:29] <tsoome> Reinhilde: pstack will also give you backtrace
[15:06:34] <Agnar> or pstack
[15:06:40] <andyf> ah, nice. The Nexenta version
[15:07:37] <tsoome> Reinhilde: btw, what type of disk is for your rpool?
[15:08:00] <Reinhilde> virtio
[15:08:08] *** yuripv <yuripv!~yuripv@109.70.144.150> has quit IRC (Ping timeout: 244 seconds)
[15:08:11] <Reinhilde> this is a virtual machine for what it's worth
[15:08:11] <andyf> I just started irssi on OmniOS and it's ticking along around 16MiB of RAM
[15:08:31] <tsoome> ok, and its backing store?
[15:08:40] <Reinhilde> and I don't know.
[15:08:51] <Reinhilde> the guy who sold me it said it was an ssd
[15:08:57] <tsoome> ok
[15:09:00] <andyf> PID USERNAME SIZE RSS STATE PRI NICE TIME CPU PROCESS/NLWP
[15:09:00] <andyf> 7492 af 16M 9996K sleep 59 0 0:00:00 0.0% irssi/2
[15:09:02] <Reinhilde> (the guy who sold me it's website is https://vultr.com for what THAT's worth)
[15:09:35] <Reinhilde> andyf: 32 or 64 bit mode?
[15:09:50] <Reinhilde> and did you compile it yourself or did you get it from somewhere™
[15:09:53] <andyf> 64-bit - it's the `irssi` from the OmniOS package repository
[15:10:03] <Reinhilde> so you got it from IPS
[15:10:11] *** yuripv <yuripv!~yuripv@217.146.82.144> has joined #illumos
[15:10:13] <Agnar> Reinhilde: /usr/bin/irssi: ELF 32-bit LSB executable 80386 Version 1, dynamically linked, not stripped
[15:10:20] <andyf> yep, `pkg install ooce/network/irssi`
[15:10:22] <Agnar> Reinhilde: I use the pkg from openindiana
[15:10:58] <Reinhilde> tell me then, what the fuck am I doing wrong?
[15:11:27] <Reinhilde> what sort of fucked up figure am I compiling into irssi with my dumbass custom compile line that makes it want 1<<32 rams?
[15:11:48] <Agnar> Reinhilde: why not take the package?
[15:12:15] <Reinhilde> that doesn't tell me what I am doing wrong.
[15:12:18] <andyf> fg
[15:12:31] <andyf> No, but it could rule out some things
[15:13:04] <Reinhilde> andyf: wrong terminal syndrome? ;-)
[15:13:23] <andyf> That was from my irssi window
[15:13:28] <jperkin> if you want some DTrace to figure out what allocations are happening you might find my post useful where I used it to fix various memory usage in pkgin: https://www.perkin.org.uk/posts/reducing-ram-usage-in-pkgin.html
[15:13:35] <tsoome> Reinhilde: did you do pkg update?
[15:13:51] <jperkin> that will at least tell you where the large allocations are coming from, and will probably help diagnose what's going on
[15:14:34] <Reinhilde> tsoome: ?
[15:14:43] <Reinhilde> tsoome: that's a red herring
[15:14:50] <tsoome> ?
[15:14:51] *** Kurlon <Kurlon!~Kurlon@bidd-pub-03.gwi.net> has quit IRC (Ping timeout: 240 seconds)
[15:15:17] <Reinhilde> for what it's worth, I installed ooce/network/irssi, and /opt/ooce/bin/irssi starts fine under a ulimit -v of 500000
[15:16:07] <tsoome> 20590 tsoome 1 59 0 8412K 5632K sleep 0:00 0.01% irssi
[15:16:17] <tsoome> just without any connections
[15:16:22] <Agnar> Reinhilde: https://github.com/OpenIndiana/oi-userland/blob/oi/hipster/components/network/irssi/Makefile
[15:16:43] *** tsoome_ <tsoome_!~tsoome@148-52-235-80.sta.estpak.ee> has joined #illumos
[15:16:44] <Agnar> Reinhilde: here you have the compile options for OpenIndianas irssi
[15:17:12] <tsoome> and joined on #illumos: 20590 tsoome 2 59 0 8768K 6036K sleep 0:00 0.00% irssi
[15:17:13] *** Kurlon <Kurlon!~Kurlon@bidd-pub-03.gwi.net> has joined #illumos
[15:17:27] <tsoome> this is OI irrsi btw
[15:17:47] <andyf> and for OmniOS - https://github.com/omniosorg/omnios-extra/blob/master/build/irssi/build.sh
[15:17:52] <andyf> There's nothing special in either of them
[15:18:57] <Reinhilde> The only truly special thing I did in mine was specify that gcc was to be -m64 (sort of redundant, I know), and --enable-true-color
[15:20:17] <Reinhilde> and because the linker was playing silly buggers, I also overrode CCLD to move -L/usr/local/lib to the front of the command line.
[15:20:30] *** idodeclare <idodeclare!~textual@cpe-76-185-177-63.satx.res.rr.com> has joined #illumos
[15:20:31] <tsoome> (in OI)
[15:21:29] <tsoome> only gcc 9 defaults to generate 64-bit binaries rest default to 32-bit.
[15:21:37] <andyf> I ran:
[15:21:38] <andyf> pfexec dtrace -n 'pid$target::malloc:entry{@ = quantize(arg0)}' -c '/opt/ooce/bin/irssi'
[15:21:56] <Reinhilde> andyf: should I run that on my home-compiled irssi too?
[15:22:01] <andyf> and it mostly allocated memory in 16 byte chunks
[15:22:13] <andyf> Reinhilde, worth a try
[15:23:00] <Reinhilde> "value" 8 has the most @s beside it, and shows a conut of 815. I have less than no idea what this means
[15:24:11] <Reinhilde> I've overwritten https://umbrellix.net/~ellenor/srbloat.txt with what I saw on the terminal.
[15:25:03] <tsoome> ou, 4294967296 | 1
[15:25:15] <andyf> Try:
[15:25:19] <andyf> pfexec dtrace -n 'pid$target::malloc:entry/arg0 > 16777216/{ustack();}' -c /path/to/irssi
[15:25:31] <Reinhilde> tsoome: "there's yer praaablem!"
[15:25:47] <tsoome> indeed. and ustack() will tell you where.
[15:26:04] <Reinhilde> irssi`ctcp_register
[15:26:25] <tsoome> someone is trying to do malloc(-1) ?
[15:26:41] <Agnar> ha, the sinfall of irc. ctcp.
[15:26:55] <Reinhilde> I've overwritten https://umbrellix.net/~ellenor/srbloat.txt with the ustack() trace.
[15:27:16] <andyf> ctcp_register+0x3a is the offset into that function
[15:27:24] <tsoome> no, it is not -1
[15:27:31] <andyf> you can look at the source against the disassembly to find the problem line
[15:27:52] <Reinhilde> i have enough information. I'll go looking for wrappers around malloc
[15:27:55] <tsoome> libglib-2.0.so.0.6000.6`g_ascii_strup+0x24
[15:28:21] <andyf> hmm.. ctcp_register is not even in the source tree for irssi that OmniOS builds
[15:28:26] <Reinhilde> at least so I think
[15:28:34] <Reinhilde> that's weird
[15:28:54] <andyf> Ah no, sorry, found it...
[15:29:07] *** jimklimov <jimklimov!~jimklimov@ip-86-49-254-64.net.upcbroadband.cz> has joined #illumos
[15:29:26] <andyf> Reinhilde, let's find out what argument is being passed to ctcp_register
[15:30:44] <Reinhilde> seems innocuous enough.
[15:30:46] <Reinhilde> ctcp_register("ping");
[15:30:48] <Reinhilde> ctcp_register("version");
[15:30:50] <Reinhilde> ctcp_register("time");
[15:30:53] <Reinhilde> ctcp_register("userinfo");
[15:30:54] <Reinhilde> ctcp_register("clientinfo");
[15:31:24] <gitomat> [illumos-gate] 11634 installboot should support ESP updates -- Toomas Soome <tsoome at me dot com>
[15:32:18] <Reinhilde> there are 4 other occurences of g_ascii_strup in the source code
[15:32:30] *** idodeclare <idodeclare!~textual@cpe-76-185-177-63.satx.res.rr.com> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…)
[15:32:34] <andyf> hmm.. are you using your own built libglib?
[15:33:28] <Reinhilde> not that I know of.
[15:33:43] <Reinhilde> [perihelion ellenor]~/src/irssi/irssi/src/irc/core $ ldd /opt/local/bin/irssi | grep glib
[15:33:45] <Reinhilde> libglib-2.0.so.0 => /usr/lib/amd64/libglib-2.0.so.0
[15:35:15] <Reinhilde> meanwhile I'm updating the people in BSD world about this insane situatin
[15:37:10] <andyf> pfexec dtrace -n 'pid$target::g_strndup:entry{printf("%p %d", arg0, arg1)}' -c /path/to/irssi
[15:38:24] <Reinhilde> I'm already calling this the "String that never ends" bug
[15:38:43] <Reinhilde> 0 9724 g_strndup:entry 4f724d 4294967295
[15:39:09] <Reinhilde> I've overwritten https://umbrellix.net/~ellenor/srbloat.txt with what I saw on the terminal.
[15:40:59] *** gwr <gwr!~gwr@151.203.114.175> has joined #illumos
[15:41:20] <Reinhilde> gwr: welcome to the "String that Never Ends" bug
[15:41:50] <patdk-lap> :)
[15:41:55] <tsoome> gnu is never wrong!
[15:42:34] <andyf> Let's try one last one.,..
[15:42:42] <andyf> pfexec dtrace -n 'pid$target::strlen:entry{printf("%s", copyinstr(arg0))}' -n 'pid$target::strlen:return{printf("%d", arg1)}' -c /path/to/irssi
[15:43:01] <andyf> you basically just need to debug it.. and there are lots of tools available
[15:48:32] <tsoome> what was calling that poor g_strndup again?
[15:48:42] <tsoome> ctcp_register() ?
[15:48:43] <andyf> g_ascii_strup
[15:50:18] <tsoome> and it was already called with huge len?
[15:50:33] <andyf> g+_ascii_strup had -1 for the second argument
[15:51:53] <tsoome> ok and it should have called strlen() for such argument
[15:52:10] <Reinhilde> yeah
[15:52:12] <andyf> yes, but I assume it did not..
[15:52:31] <Reinhilde> we're chasing a string that never ends.
[15:52:41] <tsoome> so, but if gssize is 64-bit, then 4294967295 (0x00000000ffffffff) is not -1
[15:52:50] <andyf> Reinhilde, what eveidence do you have for that?
[15:53:11] <andyf> tsoome, right, so the `if (len < 0)` does not match
[15:53:20] <tsoome> I say this is 64-bit build issue.
[15:53:36] <andyf> yes, or 64-bit build with 32-bit header somewhere
[15:53:52] <jperkin> fwiw 64-bit irssi is fine on SmartOS
[15:53:58] <tsoome> the caller did pass 32-bit -1, but gssize is 64-bit.
[15:53:59] <andyf> and on OmniOS
[15:54:50] <tsoome> so whatever did call g_ascii_strup(), was passing bad argument.
[15:54:53] <Reinhilde> am I just a complete and total idiot?
[15:55:18] <tsoome> no, why so?
[15:55:18] <Reinhilde> or do I need to tell ./configure to configure for x86_64-sun-solaris2.11 instead of i386-pc-whatever
[15:55:44] <tsoome> such bugs exist, they have to be identified and fixed.
[15:55:59] <andyf> Your problem is on the boundary between the irssi binary and the glib library
[15:56:13] <jperkin> you shouldn't need to do anything special, but it sounds like from earlier conversations that your builds are somewhat nonstandard and you are modifying variables to pull in libraries from random places, so it's likely just that there's a bad interaction somewhere along the line
[15:56:38] <andyf> for some reason, I think the prototype for g_ascii_strup that irssi is seeing is wrong
[15:57:00] <Reinhilde> jperkin: there is not a glib in the random place I am trying to pull in libs from
[15:57:03] <jperkin> especially if headers end up being pulled from a different build, as glib hardcodes certain assumptions about the build environment
[15:58:42] <Reinhilde> how exactly would I know if the string that never ends is because irssi is compiling as 64 bit while something somewhere is 32 bit?
[15:59:02] <andyf> There is no string...
[15:59:38] <tsoome> tere is no mix of 64 and 32-bit binaries.
[15:59:42] <tsoome> there*
[15:59:53] <Reinhilde> binaries no, but what could be going wrong?
[16:00:16] <andyf> irssi calls g_ascii_strup(char *str, gssize len)
[16:00:21] <andyf> and it sets len = -1
[16:00:22] <Reinhilde> andyf: never said there was. All I was saying is that something somewhere thinks it needs to make room for something that, on a 32 bit machine, never ends.
[16:00:36] <andyf> which should make g_ascii_strup use strlen() to find out the string length
[16:00:48] <andyf> but irssi is passing the 32-bit value of -1
[16:01:12] <andyf> which could mean that it thinks that gssize is a 32-bit type
[16:01:43] <andyf> I do not know why your irssi build would think that
[16:01:46] <Reinhilde> why would gssize be a 32 bit type
[16:02:09] <tsoome> likely because something was assuming it is 32-bit
[16:02:51] <Reinhilde> there's only one glib-2.0
[16:02:56] <Reinhilde> so I don't know where THAT would happen
[16:03:54] <tsoome> dnl Try to figure out whether gssize should be long or int
[16:04:23] <Reinhilde> ?
[16:04:35] *** user888 <user888!~user888@pool-96-242-225-247.nwrknj.fios.verizon.net> has joined #illumos
[16:04:49] <jperkin> diff between 32-bit and 64-bit glibconfig.h: https://gist.github.com/jperkin/9b207d39c521d5baae89234d7a7f18a4
[16:04:58] <jperkin> plenty there to screw things up
[16:05:00] <yuripv> it should be size_t, and done with it
[16:05:40] <andyf> OmniOS has usr/lib/amd64/glib-2.0/include/glibconfig.h
[16:05:40] <andyf> usr/lib/glib-2.0/include/glibconfig.h
[16:05:48] <tsoome> I wonder… the configure (in glib) is rrunning C snippets to detect the size, and if 32-bit build iof the snippet is used for 64-bit glib build, then we are screwed.
[16:06:10] <andyf> Almost certainly the wrong version of glibconfig.h is being included
[16:07:17] <Reinhilde> i fear that you may be right.
[16:07:18] <Reinhilde> GLIB_CFLAGS = -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -pthread
[16:07:59] <andyf> That would do it
[16:08:00] <tsoome> there can not be one set of headers for 32-bit and 64-bit glib.
[16:08:41] <andyf> my irssi build has
[16:08:42] <andyf> 1309:GLIB_CFLAGS='-I/usr/include/glib-2.0 -I/usr/lib/amd64/glib-2.0/include'
[16:09:08] <Reinhilde> how do you invoke ./configure ?
[16:10:37] <andyf> Nothing special.. just --prefix and --sysconfdir
[16:11:27] <Reinhilde> I had to edit Makefile
[16:12:01] <Reinhilde> and I fear that won't do it
[16:12:39] <andyf> Try `pkg-config --cflags glib-2.0
[16:12:39] <andyf> `
[16:13:14] <Reinhilde> $ pkg-config --cflags glib-2.0
[16:13:40] <andyf> That's the 32-bit path
[16:13:44] <andyf> mine is showing the 64-bit one
[16:14:06] <Reinhilde> libpkgconf/pkg.c:515 [pkgconf_pkg_try_specific_path]: found: /usr/lib/pkgconfig/glib-2.0.pc
[16:14:21] <Reinhilde> brb editing more things
[16:14:25] <andyf> env -i pkg-config --cflags glib-2.0
[16:14:36] <Reinhilde> brb stabbing myself
[16:14:52] <Reinhilde> $ env -i pkg-config --cflags glib-2.0
[16:15:00] <andyf> so, it's something in your environment
[16:15:05] <Reinhilde> i do have a changed pkg_config_path
[16:15:31] <Reinhilde> to which I will append /usr/lib/amd64/pkgconfig
[16:17:13] <Reinhilde> this will forever be known as the 4gb string
[16:19:25] <andyf> FWIW,
[16:19:25] <andyf> # ISALIST=i386 pkg-config --cflags glib-2.0
[16:19:34] <andyf> so it works properly in the default environment
[16:20:07] <Reinhilde> so, pkg-config is confused. GTK.
[16:20:30] <andyf> No, just you altered its behaviour by changing your environment
[16:20:34] *** amrfrsh <amrfrsh!~Thunderbi@131.234.43.140> has quit IRC (Quit: amrfrsh)
[16:20:40] <Reinhilde> i.e. confused
[16:21:07] <andyf> It's doing what you told it...
[16:21:19] <andyf> anyway, I'm glad we got to the bottom of the problem, I have to run.
[16:22:27] *** SolarHilde <SolarHilde!~ellenor@perihelion.nj.us.umbrellix.net> has joined #illumos
[16:22:29] <SolarHilde> 07:21 -!- Irssi v1.3-dev-186-g96562e46 - https://irssi.org
[16:22:42] *** SolarHilde <SolarHilde!~ellenor@perihelion.nj.us.umbrellix.net> has quit IRC (Client Quit)
[16:26:06] *** tsoome_ <tsoome_!~tsoome@148-52-235-80.sta.estpak.ee> has quit IRC (Quit: leaving)
[16:32:21] <Reinhilde> that time cmake compels you to use crle because it's too stupid to listen to you when you say "YOU HAVE TO INCLUDE RPATH USR LOCAL LIB IN THE LIBRARIES"
[16:39:43] *** user888 <user888!~user888@pool-96-242-225-247.nwrknj.fios.verizon.net> has quit IRC (Ping timeout: 246 seconds)
[16:46:58] *** jcea <jcea!~Thunderbi@2001:41d0:1:8a82:7670:6e00:7670:6e00> has joined #illumos
[16:54:40] *** jcea <jcea!~Thunderbi@2001:41d0:1:8a82:7670:6e00:7670:6e00> has quit IRC (Ping timeout: 264 seconds)
[16:56:35] *** user888 <user888!~user888@pool-96-242-225-247.nwrknj.fios.verizon.net> has joined #illumos
[17:03:47] *** igork1 <igork1!~igork@91.204.56.74> has joined #illumos
[17:05:53] *** igork <igork!~igork@91.204.56.74> has quit IRC (Ping timeout: 245 seconds)
[17:06:08] *** igork1 is now known as igork
[17:32:38] <gitomat> [illumos-gate] 11648 loader.efi: comconsole should set EFI_SERIAL_REQUEST_TO_SEND bit -- Toomas Soome <tsoome at me dot com>
[17:52:22] *** merzo <merzo!~merzo@ll-202.208.223.85.sovam.net.ua> has joined #illumos
[17:52:44] *** Yogurt <Yogurt!~Yogurt@104-7-67-228.lightspeed.sntcca.sbcglobal.net> has joined #illumos
[17:58:18] *** merzo <merzo!~merzo@ll-202.208.223.85.sovam.net.ua> has quit IRC (Ping timeout: 246 seconds)
[18:14:38] *** jcea <jcea!~Thunderbi@2001:41d0:1:8a82:7670:6e00:7670:6e00> has joined #illumos
[18:38:48] <gitomat> [illumos-gate] 1701 ZFS to support UNMAP/TRIM for SSD -- Brian Behlendorf <behlendorf1 at llnl dot gov>
[18:41:29] <tsoome> whee
[18:41:38] <tsoome> nice one.
[18:46:03] <yuripv> reviewers and contributors lists are nice indeed
[18:46:08] *** man_u <man_u!~manu@manu2.gandi.net> has quit IRC (Quit: man_u)
[18:50:03] *** Kurlon <Kurlon!~Kurlon@bidd-pub-03.gwi.net> has quit IRC (Ping timeout: 245 seconds)
[19:06:28] *** jcea <jcea!~Thunderbi@2001:41d0:1:8a82:7670:6e00:7670:6e00> has quit IRC (Ping timeout: 276 seconds)
[19:13:47] *** Kurlon <Kurlon!~Kurlon@bidd-pub-03.gwi.net> has joined #illumos
[19:15:58] <KungFuJesus> most of the gnu autotools have some subtitle and spectactular failure that happens on anything that's not FreeBSD or Linux
[19:16:05] <KungFuJesus> subtle*
[19:16:18] <KungFuJesus> cmake has similar bugs in their build toolchain
[19:16:56] *** user888 <user888!~user888@pool-96-242-225-247.nwrknj.fios.verizon.net> has quit IRC (Ping timeout: 276 seconds)
[19:17:14] <KungFuJesus> I remember trying to build mysql with Solaris/Sun Studio on Illumos, and it'd fallback some auto populated config.h file to have 32 bit pointers, despite the variables for the test to generate those being run with -m64
[19:18:52] <KungFuJesus> of course, if everything was finally purely a 64 bit userland, that class of bug wouldn't occur anymore
[19:19:24] <tsoome> bugs would still be there, just not revealed...
[19:20:03] <KungFuJesus> sure, you just have to wonder why OI is carrying around that vestige from the ultraSPARC days
[19:20:48] <KungFuJesus> even on SPARC, for the SPARC hardware that's actually supported in Illumos, the benefits of having 32 bit userspace binaries are probably pretty small, aren't they?
[19:21:17] <tsoome> ah, you mean, why we still have 32-bit userland?
[19:21:21] <KungFuJesus> yes
[19:21:26] <tsoome> 2 reasons
[19:21:38] <tsoome> 1 is to support runtime environment
[19:22:01] <tsoome> 2 is because there are no developers converting userland to 64-bit build.
[19:22:04] <KungFuJesus> sure, but you can do that by having a split /lib, /lib32 configuration
[19:22:26] <tsoome> we have split configuration
[19:22:40] <rmustacc> We already support both 32 and 64-bit compilation environments simultaneously.
[19:22:43] <tsoome> lib/i86pc and lib/amd64
[19:22:43] <KungFuJesus> yeah, */lib and */lib/64, or some variant of that
[19:22:46] <KungFuJesus> yep
[19:23:14] <KungFuJesus> rmustacc: what does smartOS use at this point?
[19:23:30] <rmustacc> What do you mean?
[19:23:40] <KungFuJesus> what's the output of file `which ls`?
[19:23:48] <rmustacc> It'll be the illumos default.
[19:23:56] <KungFuJesus> ah, was an elf32 binary
[19:23:59] <KungFuJesus> so an*
[19:24:08] <rmustacc> Well, ls is a bit special as it may be isaexeced, but
[19:24:22] <rmustacc> As a user, it shouldn't make a difference.
[19:24:36] <rmustacc> In fact, 64-bit ls can be more troublesome.
[19:24:41] <tsoome> isaexec has 113 links
[19:24:49] <rmustacc> As it can eat up more memory trying to sort a large directory, haha.
[19:26:12] <tsoome> :D
[19:26:39] <rmustacc> Had a directory with a couple million entries (don't ask) and made the mistake of running ls.
[19:27:02] <KungFuJesus> rmustacc: My file server at work here has the same issue. ImageNET, the full dataset, is 14 million files
[19:27:19] <KungFuJesus> it's somewhat subdivided, but not enough to not destroy the ARC while doing something like find
[19:27:41] <KungFuJesus> like 100kish top level directories, with about 600 something images under each of them
[19:29:25] <KungFuJesus> Illumos is strictly LP64, not ILP64, right?
[19:29:45] <KungFuJesus> I'm guessing ILP64 would make that even worse
[19:31:37] <KungFuJesus> Kind of wish I could edit redmine entries that I create...https://www.illumos.org/issues/11671
[19:33:26] <rmustacc> illumos is LP64.
[19:33:32] <rmustacc> An int is still 32-bit.
[19:33:42] <rmustacc> The 32-bit compilation environment is ILP32.
[19:33:56] <KungFuJesus> Yeah, I never really understood why ILP64 was a thing
[19:34:09] <KungFuJesus> automatically halve your cache performance, hah
[19:36:15] <KungFuJesus> I maybe understood why BLAS did, maybe to deal with a matrix that was greater than 2 billion elements and you were leveraging some massive MPI based thing to deal with a very large linear algebra problem
[19:37:34] <KungFuJesus> Things that wrangle BLAS are dealing with that fallout, though. I've seen bugs related to it in Numpy
[19:44:12] <KungFuJesus> if I'd have added an extension to those attachments in redmine, the previous would probably render
[19:46:32] <KungFuJesus> https://www.illumos.org/issues/11671?next_issue_id=11670 If someone code delete those first 2 attachments...
[19:47:02] <KungFuJesus> s/previous/preview/g
[19:48:43] <yuripv> rmustacc: my mail is still being held by the lists?
[19:52:21] <rmustacc> yuripv: They told me they had fixed it, but I can check in a little bit.
[19:54:47] <KungFuJesus> am I supposed to post redmine bugs to the developer mailing list, or is that strictly for patches?
[19:57:32] <rmustacc> The developer list is for discussion in addition to review.
[19:57:50] <rmustacc> If there's something you're looking to reach a broader audience about or ask for help or whatever, it can be a useful resource.
[19:57:53] *** user888 <user888!~user888@pool-96-242-225-247.nwrknj.fios.verizon.net> has joined #illumos
[19:57:55] <KungFuJesus> Would it be rude to post a link to my bug in redmine?
[20:00:45] <rmustacc> People will sometimes discuss bugs they're trying to sort through. I think as long as you're willing to follow up if folks suggest something, nothing wrong with it.
[20:01:05] <KungFuJesus> ok good :)
[20:07:53] <rmustacc> In general, the only other thing I'd suggest if mailing the list about a bug is what you want someone to do with it.
[20:08:07] <rmustacc> Are you looking for someone to help fix it, help debug, etc.
[20:09:10] <KungFuJesus> help fix it. I can definitely help debug, and I could probably write a patch, even. I'm just not comfortable / familiar enough with PAM to be confident that what I come up with is the _correct_ approach
[20:09:25] <KungFuJesus> I'm pretty sure I found the root cause in the code, though
[20:10:29] <rmustacc> I think that's the kind of thing I'd make sure you include when you send the mial
[20:10:44] <KungFuJesus> ahhh, I definitely sent it prematurely, though
[20:10:51] <KungFuJesus> s/though/then/g
[20:10:54] <KungFuJesus> sorry, can't type today
[20:11:06] <KungFuJesus> https://illumos.topicbox.com/groups/developer/T259d5fc8d2e07df7/pamkrb5-bug
[20:12:19] <rmustacc> It's fine either way. In general, I think being clearer about that stuff will help maximize the chance of getting what you want.
[20:13:10] <denk> rmustacc: do you need some additional info about issue 11609? unfortunately, this lenovo model is eol and no update for bios
[20:16:01] <rmustacc> denk: I haven't had a chance to look at. And again, this isn't 11609.
[20:16:08] <rmustacc> *at it
[20:16:20] <rmustacc> The memory controller drivers don't apply to your platform.
[20:16:43] <rmustacc> Your issue is a side effect of the fact that we're now enumerating all the PCI devices since the BIOS incorrectly stated the last bus and that clearly has triggered some bad assumption in fmtopo.
[20:17:02] <rmustacc> I'll hopefully make some time to look at the core this week.
[20:17:26] <denk> ok, thanks anyway
[20:22:19] *** amrfrsh <amrfrsh!~Thunderbi@190.2.145.106> has joined #illumos
[20:48:35] *** cartwright <cartwright!~chatting@gateway/tor-sasl/cantstanya> has quit IRC (Remote host closed the connection)
[20:50:21] *** cartwright <cartwright!~chatting@gateway/tor-sasl/cantstanya> has joined #illumos
[21:37:14] *** user888 <user888!~user888@pool-96-242-225-247.nwrknj.fios.verizon.net> has quit IRC (Ping timeout: 240 seconds)
[21:46:08] *** mecrobio <mecrobio!~mecrobio@6.red-88-4-17.dynamicip.rima-tde.net> has joined #illumos
[21:47:18] *** user888 <user888!~user888@pool-96-242-225-247.nwrknj.fios.verizon.net> has joined #illumos
[22:09:19] <KungFuJesus> how long is a typical ON build? Doing it for the first time, may play with a potential patch for this pam module
[22:10:04] <yuripv> that heavily depends on your system configuration
[22:11:19] <rmustacc> In a VM on a laptop with an SSD, 2 CPUs, and about 4 GiB it was about 1.5 hours.
[22:11:41] <KungFuJesus> xeon sp silver, 2x8 cores, 2.1GHz (turbo to 3 GHz)
[22:11:41] <rmustacc> On hardare with a lot more DRAM and cores, it was a lot faster.
[22:11:53] <KungFuJesus> 192 GB of memory
[22:12:16] <KungFuJesus> production systems that aren't into production yet make for good build platforms, hah
[22:12:22] <rmustacc> They do.
[22:12:38] <rmustacc> If you have flash, I'd expect that system to do everything in maybe about an hour?
[22:12:42] <rmustacc> Maybe less.
[22:13:03] <rmustacc> I'd recommend doing a full build first and then using bldenv to basically iterate on the component you want.
[22:13:13] <KungFuJesus> rpool is flash, but I'm buliding on a RAIDz2 backed pool with 4 x 6 device vdevs
[22:13:21] <KungFuJesus> yeah, that was my plan
[22:13:31] <yuripv> less, building with all shadows enabled on a 20-core, 32GB VM is less than an hour, and its storage is not that fast
[22:14:02] <KungFuJesus> then I can post it to the mailing list have people suggest to me why my fix is horrible
[22:14:06] <rmustacc> I'd just fire it off in the background and come back to it in a little bit.
[22:14:41] *** gwr <gwr!~gwr@151.203.114.175> has quit IRC (Quit: This computer has gone to sleep)
[22:19:15] *** merzo <merzo!~merzo@117-59-132-95.pool.ukrtel.net> has joined #illumos
[22:19:21] <KungFuJesus> 22min
[22:19:32] <rmustacc> There you go, pretty snappy for everything involved.
[22:20:01] *** ed209 <ed209!~ed209@165.225.128.67> has quit IRC (Remote host closed the connection)
[22:20:07] *** ed209 <ed209!~ed209@165.225.128.67> has joined #illumos
[22:26:23] <KungFuJesus> ok so what's the difference between usr/src/proto/..../usr/lib/security/64/pam_krb5.so.1 and usr/src/proto/..../usr/lib/security/amd64/pam_krb5.so.1?
[22:26:40] <KungFuJesus> md5 says they're different binaries
[22:26:50] <KungFuJesus> does one have ctf applied after the fact or something?
[22:27:59] <rmustacc> They're identical in my environment
[22:28:04] <rmustacc> Those should be the exact same file.
[22:28:17] <rmustacc> 64 is a symlink to amd64 on x86 (or sparcv9 on SPARC, IIRC)
[22:33:51] *** steph <steph!steph@minos.ber.rdev.info> has quit IRC (Ping timeout: 240 seconds)
[22:36:24] <rmustacc> yuripv: I did find some things. I'm not sure why it's happening this time.
[22:36:33] <rmustacc> Maybe you can reach out to support this time? Sorry for the trouble.
[22:36:42] <yuripv> yes, will do, and thanks
[22:37:00] <rmustacc> If you get a support ID, let me know so I can follow up on the other one I have open.
[22:37:13] <rmustacc> If you find anything else missing, don't hesitate to ping me again.
[22:37:50] <KungFuJesus> heh, I see a potential memory leak in this code, though it probably never happens in practice
[22:38:15] <rmustacc> Well, might as well squash it while you're there.
[22:38:44] *** steph <steph!steph@minos.ber.rdev.info> has joined #illumos
[22:39:54] *** neirac <neirac!~cneira@190.162.109.190> has joined #illumos
[22:40:29] *** neirac <neirac!~cneira@190.162.109.190> has left #illumos
[22:41:06] <KungFuJesus> *sigh* I'm not feeling great about this fix to begin with, it certainly doesn't seem like the correct thing to do
[22:42:22] <KungFuJesus> so pam_sm_authenticate() is called from a child pid from sshd. It does all of this crap to authenticate the client, writing stuff to the child process's address space. Then that pid joins, and the parent pid tries to address all that crap that was happening at the pam_sm_authenticate stage
[22:43:12] <KungFuJesus> I can duplicate all the work that thing was doing, but then the authenticate stage of the module's work is basically thrown away, and we're probably just generating and throwing awau krb ticket in doing so
[22:43:25] <KungFuJesus> away*
[22:44:29] <KungFuJesus> the more sensible solution is to modify openssh, but openssh is probably forking to another pid on purpose to minimize privileges? I'm not really sure, but I do see that the portable version has wrappers for leveraging the privileges API in Solaris
[22:45:01] <rmustacc> So, in general they do a bunch of stuff in child processes. Though arekinath knows the design there a lot better than I do.
[22:45:10] <KungFuJesus> I need to share that pam module data somehow, what's the best mechanism?
[22:45:24] <rmustacc> So you need to share PAM data between the child and parent?
[22:45:28] <KungFuJesus> yes
[22:46:00] <KungFuJesus> while still conforming the PAM API
[22:46:04] <KungFuJesus> to the*
[22:46:16] <rmustacc> What is the lifetime of this data supposed to be? Basically should this be tied to the user? To a specific session? To a given parent/child relationship?
[22:46:37] <rmustacc> I'm not that familiar with this part of the system, I'm afraid.
[22:46:58] <KungFuJesus> it's assumed to survive between the auth and setcred stages, at least
[22:47:25] <KungFuJesus> which is why the /dev/console version works, it's not forking, at least in between the authentication stages
[22:47:33] <KungFuJesus> at least not*
[22:48:19] <rmustacc> Maybe when arekinath is awake they'll have a better suggestion here.
[22:48:36] <KungFuJesus> the PAM module clearly expects the setcred stage to be run after the authenticate stage. It's expecting the PAM module data to be there in the process address space
[22:48:53] <KungFuJesus> arekinath: whenever you wake up, all the details you'll need are here: https://www.illumos.org/issues/11671
[22:48:56] <rmustacc> The forking to do parts of it is a bit weird.
[22:49:27] <rmustacc> I mean, I get the idea that it wants to do that to do better privsep and minimize the attack surface, but it seems that if we do, we probably need to communicate something back to the parent?
[22:49:28] *** Kurlon_ <Kurlon_!~Kurlon@bidd-pub-04.gwi.net> has joined #illumos
[22:49:44] <rmustacc> As I imagine openssh isn't forking this in the context of the actual PAM operations, but around the PAM stuff, right?
[22:49:50] <KungFuJesus> yes, I'm kind of curious how other PAM implementations are pulling this off
[22:49:51] *** Yogurt <Yogurt!~Yogurt@104-7-67-228.lightspeed.sntcca.sbcglobal.net> has quit IRC ()
[22:50:17] <rmustacc> Yeah, I was going to ask something similar.
[22:50:27] <rmustacc> Looking at that might give some ideas.
[22:50:40] <rmustacc> There are a lot of ways you can do it, but you'd have to know that you were opting into it.
[22:51:40] <arekinath> hmm I thought OpenSSH was careful to forklift env vars between the PAM functions and others used that for intermediate data... I could be wrong though...
[22:51:49] *** Yogurt <Yogurt!~Yogurt@104-7-67-228.lightspeed.sntcca.sbcglobal.net> has joined #illumos
[22:51:55] <arekinath> also I swear I remember solving this in a zone once before
[22:52:06] <arekinath> and making it get a krb5 ticket on login
[22:52:14] <KungFuJesus> so I'm looking at sshd.c for 7.9, where do_setcred is called
[22:52:28] <KungFuJesus> the authentication looks to be done in a separate pid
[22:53:01] <rmustacc> Yeah, I would have almost thought you'd try to get a krb5 ticket for basically a session as part of logging in and keep that around somehow.
[22:53:23] *** Kurlon <Kurlon!~Kurlon@bidd-pub-03.gwi.net> has quit IRC (Ping timeout: 276 seconds)
[22:53:51] <KungFuJesus> hah, happens in main of all places
[22:54:02] *** Kurlon_ <Kurlon_!~Kurlon@bidd-pub-04.gwi.net> has quit IRC (Ping timeout: 276 seconds)
[22:54:25] <KungFuJesus> sshd.c:2190
[22:56:34] <KungFuJesus> so authentication happens prior to that, in sshpam_thread
[22:56:43] <arekinath> yes, it's part of the privsep design in OpenSSH and quite deliberate
[22:57:21] <arekinath> ah, the zones where we're using pam_krb5 we're using the cross-platform one from pkgsrc
[22:57:26] <arekinath> not the platform one
[22:57:50] <arekinath> that one doesn't try to stash intermediate state in memory like this
[22:58:11] <rmustacc> Where would you stash it otherwise?
[22:58:24] <rmustacc> Or rather, how would you key it across processes? Tie to a session id or?
[23:01:13] <arekinath> hmm
[23:01:36] <rmustacc> Or are you going to tell me the answer is pamd? ;)
[23:03:03] <arekinath> I'm going to have to read a lot of code haha
[23:03:12] <arekinath> gotta move some servers first though, sorry
[23:03:15] <KungFuJesus> hah, looks like on the Linux side of things there's an sssd-pam process that's probably managing this state
[23:03:48] <KungFuJesus> rmustacc: that's a bit worrisome, that might be the current answer
[23:03:54] <arekinath> pamd is a good answer to a lot of PAM problems imho ;)
[23:05:01] <rmustacc> Well, even if pamd existed, we'd still have to figure out what to tie it to.
[23:05:21] <KungFuJesus> and how to talk to it
[23:05:24] <KungFuJesus> unix domain sockets?
[23:05:28] <rmustacc> Well, the how to talk to it is easy.
[23:05:29] <KungFuJesus> dbus?
[23:05:39] <rmustacc> For pamd or the moral equivalent?
[23:05:47] <rmustacc> I'd probably use a door, tbh.
[23:05:54] <rmustacc> It's probably not going to be portable.
[23:06:10] <rmustacc> And we'll want to do a lot of the stuff that sshd and others are doing.
[23:06:15] <KungFuJesus> and it shouldn't need to be for a PAM module
[23:06:27] <rmustacc> But honestly, a uds or doors let you get caller credentials.
[23:06:41] <arekinath> yeah it'd be a door for sure
[23:06:46] <rmustacc> But arekinath is the one who's always whispered pamd to me when I complain, so arekinath should probably sketch it out.
[23:06:50] <arekinath> internal detail of libpam though
[23:07:14] <arekinath> the best part is that processes using PAM would no longer have to be full root
[23:07:14] <rmustacc> Yeha.
[23:07:17] <KungFuJesus> so long as you conform to the external PAM API, I don't think it much matters :-p
[23:07:24] <arekinath> they would just need the PRIV_PAM
[23:07:28] <rmustacc> I forgot that.
[23:07:34] <rmustacc> That'd be so much better.
[23:07:41] *** merzo <merzo!~merzo@117-59-132-95.pool.ukrtel.net> has quit IRC (Ping timeout: 276 seconds)
[23:07:46] <arekinath> and then the door reply would elevate them like a pfexec one
[23:07:56] <arekinath> to their final privs directly
[23:08:00] <arekinath> rather than to root
[23:28:22] *** gwr <gwr!~gwr@151.203.114.175> has joined #illumos
[23:35:31] *** gh34 <gh34!~textual@cpe-184-58-181-106.wi.res.rr.com> has quit IRC (Quit: Textual IRC Client: www.textualapp.com)
[23:38:06] *** jellydonut <jellydonut!~quassel@s91904425.blix.com> has quit IRC (Quit: jellydonut)
[23:38:52] *** gwr <gwr!~gwr@151.203.114.175> has quit IRC (Quit: This computer has gone to sleep)
[23:49:12] *** gwr <gwr!~gwr@151.203.114.175> has joined #illumos
[23:54:19] *** Kurlon <Kurlon!~Kurlon@cpe-67-253-141-249.rochester.res.rr.com> has joined #illumos
[23:56:40] <gitomat> [illumos-gate] 11673 Error setting file times with smbfs and Apple SMB server -- Gordon Ross <gwr at nexenta dot com>
top

   September 10, 2019
< | 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