01:02:40 kerneldove: cpuset would pin it to whatever cores you limit it to, rctl would let it run on all but potentially throttle it every second or so 01:34:23 kevans, is the throttling smooth and just slows down jail's usage or is it an abrupt halt kinda thing? 01:34:45 is cpuset more efficient or any other advantage to using it vs setting rctl pcpu to 100%? 02:21:59 kerneldove: my recollection of how the cputime rctl is implemented is that it's not really smooth, but worth trying for yourself anad observing 02:23:38 ok i'll just cpuset 1 core for each jail, then use rctl to limit memory. ty kevans 03:31:45 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=289220 07:24:58 if aesni kernel module is included by default now, why's it still (as of 14.3) added to /boot/loader.conf pls? 07:25:08 specifically aesni_load="YES" 07:35:51 and i see also cryptodev_load="YES" is still in 14.3 /boot/loader.conf, but i thought if aesni is used (and it's included by default in GENERIC supposedly) then cryptodev shouldn't be loaded also 07:37:08 kerneldove: according to usr.sbin/bsdinstall/scripts/zfsboot, it's added automatically if you install on GELI to ensure crypto is accelerated. this seems reasonable because aesni might not be compiled into the kernel 07:37:57 but it's added automatically to GENERIC right? aesni i mean 07:37:58 cryptodev is what lets you use hardware crypto (like AES-NI) from userland, so you need both if you want to do that and your hardware has AES-NI 07:38:11 yes, aesni is in GENERIC, so if you're running GENERIC you can remove that from loader.conf 07:38:34 i searched GENERIC for "aes" didn't find. is it implied with device crypto? 07:41:15 kerneldove: https://cgit.freebsd.org/src/tree/sys/amd64/conf/GENERIC?h=releng/14.3#n308 07:41:47 i was looking at https://github.com/freebsd/freebsd-src/blob/master/sys/amd64/conf/GENERIC 07:41:56 shouldn't they match? 07:43:03 kerneldove: you're looking at the wrong branch, go here: https://github.com/freebsd/freebsd-src/blob/main/sys/amd64/conf/GENERIC 07:43:42 wtf 07:43:54 the master branch should probably be deleted from github, it doesn't exist in src anymore, i'll mention that to imp 07:44:07 tyvm 07:44:20 surprised github didn't give option to redirect master -> main 07:45:25 so if we have aesni loaded, which is automatic with GENERIC, we also want cryptodev loaded so the aesni can be used from userspace? 07:48:27 probably yes, although i'm not sure how userland consumers handle this... AES-NI isn't privileged so they could just call it directly if they have support 07:49:18 hm ok. i read (can't find link now) that dev crypto which is included in GENERIC supercedes cryptodev which is older and slower so cryptodev isn't actually needed anymore. know anything about that? 07:50:45 i don't know the answer to that 07:55:32 ivy found a link https://github.com/opnsense/tools/issues/26 07:56:28 specifically https://github.com/opnsense/tools/issues/26#issuecomment-193367846 07:57:10 that seems like a different issue to do with openssl using cryptodev instead of its own AES-NI implementation... and it's 10 years old so it might have been fixed 07:58:03 > I don't think that OpenVPN requires cryptodev, it uses OpenSSL's evp engine which is capable of using the AES-NI instructions without using the aesni module. If OpenSSL finds cryptodev and aesni is loaded, then it will use cryptodev and slow things down. 08:00:12 but https://redmine.pfsense.org/issues/5976 where it talks about perf being lower it doesn't mention openssl so maybe it's more general? 08:00:30 but yea it is pretty old issue 08:03:36 i guess since 14.3 adds cryptodev_load="YES" i'll use it too. i figure devs would have removed it by now if it was actually better to not have it 08:04:43 do you know how we can see if 15 still adds it? i'll look for " usr.sbin/bsdinstall/scripts/zfsboot" in a 15 branch 08:05:24 i found it with "git grep aesni_load", so try that 08:06:51 https://github.com/freebsd/freebsd-src/blob/main/usr.sbin/bsdinstall/scripts/zfsboot is for 15 right? if so, it doesn't add cryptodev anymore!? 08:07:09 yes, main is 15 (at least for now, it will become 16 shortly when stable/15 is branched) 08:07:47 oh but https://github.com/freebsd/freebsd-src/blob/releng/14.3/usr.sbin/bsdinstall/scripts/zfsboot doesn't have cryptodev in it either 08:09:20 hey check out https://github.com/freebsd/freebsd-src/commit/ffbaa453c1914846ede99d9b8499eb9b52b77e9a 08:09:59 zfsboot adds aesni, not cryptodev, i don't know where cryptodev_load comes from off hand 08:10:52 https://github.com/freebsd/freebsd-src/blob/main/usr.sbin/bsdinstall/scripts/config looks removed 08:11:19 https://github.com/freebsd/freebsd-src/blob/releng/14.3/usr.sbin/bsdinstall/scripts/config#L46 08:11:28 looks like it's on its way out as of 15! 08:13:02 we got to the bottom of it together 08:15:32 https://github.com/freebsd/freebsd-src/blob/main/usr.sbin/bsdinstall/scripts/zfsboot#L1403 looks like aesni_load="YES" IS still added to loader.conf when zfs encryption (geli) is enabled as of 15 08:15:55 so i'll use it too 08:20:21 ty 09:03:59 <_opr> hi everyone, recently i discovered we can run docker in freebsd with docker-machine, for some reason my laptop likes this virtualbox more than bhyve. i'm saying this only because when running bhyve, cpu is going up to 80 degrees but with virtualbox, cpu barely raises temp. I cannot find any source distinguishing these two performance wise, far as I know docker should have the same con as resource consuming 09:04:05 <_opr> as bhyve. anyone has any tips? Thanks. 09:04:53 wow 09:05:15 i thought bhyve was prety mature? 10:02:07 file a bug. 10:28:59 How do I run /usr/local/wine-proton/bin/pkg32.sh install wine-proton mesa-dri in a Jail? I am getting an error: pkg -o ABI_FILE=/usr/lib32/libc.so.7 -o INSTALL_AS_USER=true -o RUN_SCRIPTS=false --rootdir /home/jailuser/.i386-wine-pkg install wine-proton mesa-dri pkg: Unable to determine the ABI, none of the ABI_FILEs can be read. 10:29:32 (there is no /usr/lib32/libc.so.7 in the jail.. presumably for security porpoises :) ) 10:30:44 pertho: you probably need the lib32 set to install 32-bit package, that includes 32-bit libc 10:36:14 I installed the jail with Bastille.. guess I had to modify it . thanks! 10:49:03 what's the best way to make sure linprocs (/proc) is mounted in the jail? 10:50:10 set allow.mount.linprocfs (read the note in jail(8)) then you should be able to mount it in the jail's /etc/fstab 10:50:41 ah right.. so the allow.mount.linprocfs needs setting first then add it to the /etc/fstab? 10:51:14 hm, although looking at the rc script, jails may not mount from fstab 10:52:26 apparently /etc/rc.d/linux is supposed to do this, but it looks like it's not set up to run in a jail 10:54:43 as a workaround you could mount it using a jail-specific fstab on the host (mount.fstab) 10:55:04 bastille has a fstab under jails/jailname/ 10:55:13 but I'm not sure what to put in it to mount /proc 10:55:31 would have thought I would need to nullfs mount /proc from the host? 10:55:34 do you want Linux /proc or FreeBSD /proc? usually linprocfs is mounted on /compat/linux/proc 10:56:56 hmm that's a good question.. I was testing this WINE app with FreeBSD's /proc but I wonder if Linux's /proc would be more compatible with it since this WINE app uses some linuxisms to detect things.. 10:57:54 because I don't fully trust the app, I want to send it to jail :) 10:57:58 Hi 10:58:13 well, either way procfs(4) and linprocfs(4) both document the required fstab entry, so if bastille has an fstab for the jail, you can put it there. normally a jail fstab needs the jail root prepended to the mountpoint, but i don't know if bastille works like that, i've never used it 10:58:42 got another strange staff here :P 11:04:47 I fixed it but wanted to mention that since the new upgrade, I am getting wrong architecture error Msgs when using pkg add; to install some old stuff.. 11:05:04 For example: wrong architecture: FreeBSD:11:amd64 instead of FreeBSD:13:amd64 11:06:00 I even can't force install it, this wasn't happening in 13.2 11:12:53 ivy: 'bastille mount /compat/linux/proc /proc' seems to have done the trick 11:20:30 To make it persistent you should add it to the jail's fstab: `bastille edit fstab` 11:30:54 if I wanted to trace whether a WINE app I'm running is failing due to W^X or ASLR constraints, what's the best tool to determine that? ktrace/kdump doesn't seem to give enough useful output. Do I try dtrace? (I've never used dtrace before) 11:31:23 also the WINE debugging is a bloody nightmare.. produces gigs of logs which are near impossible to parse 11:41:22 Try truss(1) 11:52:14 doesn't seem to help either.. I get a bunch of freebsd32_mmap() calls which end in ERR#12 'Cannot allocate memory' 11:55:00 is it normal for truss to keep running and make the cpu race after the app has quit? 11:56:44 the app I'm truss'ing keeps running in the background somehow 11:56:52 I don't think truss(1) is the right tool for this 12:13:32 If it's some old Windows program you may change the Windows version to an older one in winecfg. Or just run it in a vm 14:28:41 Is there a public progress bar for the package builders? :) 14:29:06 <[tj]> yeah 14:29:32 <[tj]> https://pkg-status.freebsd.org/beefy18/build.html?mastername=main-amd64-default&build=p9652f95ce8e4_sb45a181a74c 14:29:43 <[tj]> is the in progress main build 14:30:49 Oh wow. Just found out why that link didn't work last time I tested -- *.freebsd.org is on my unbound blocklist. Wtf. 14:31:06 rude 14:31:36 Very. 14:32:41 <[tj]> don't leave that page open 14:32:48 <[tj]> its pull a 7MB json file in a loop 18:12:22 Oops. I SSH'ed in and pkill -9 firefox now. Sorry :( 18:22:52 I think we need something like LTS for Freebsd 18:23:59 Still fixing many broken stuff, while I will need to upgrade after 7 months for now.. 18:24:09 *from 18:25:51 LTS ? each major release is LTS 18:29:55 mzar: even minor ones break 18:30:40 Look at Solaris it's LTS lasts for nearly +25 years 18:31:05 we have a hard enough time supporting releases that are only 4-5 years old 18:31:11 realistically we do not have the resources 18:31:41 I am a desktop user, FreeBSD devs need to take care of us 18:32:01 are you funding freebsd development? 18:32:07 the oldest supported Solaris release was released in 2015, which is 10 years ago, comparable to Ubuntu and RHEL, and if you've used Solaris, you know that patches frequently break things - the update releases are just as risky as upgrading FreeBSD x.y to x.y+1 18:32:12 this is very demanding without a plot for where the resourcing comes from 18:32:13 heh, no 18:33:25 the reality is that we're a volunteer project without a real corporate backer to make things like this feasible 18:33:53 kevans: I can make something better, if you need resources I can afford a big part of it 18:34:20 fwiw, if you have money, you're free to provide your own support for older freebsd releases for as long as you want 18:34:35 there's no actual reason freebsd.org needs to do that, necessarily 18:35:33 (also, i tend to think ports support is a much more serious issue, but no one wants to fund that because most large corporate users aren't using ports, because it's not reliable, so kind of a vicious circle) 18:36:12 Then you need resources for ports? 18:36:38 ports is a complicated problem, i don't think you can just throw money at it 18:36:49 Not money 18:36:49 src is pretty straightforward in comparison 18:36:54 but Servers 18:37:08 mosaid: sure, we need, CPU cyccles for building, hands for testing and maintaing ports tree, feel free to help 18:37:20 servers would improve build times, but what it really needs is developers, and maybe management 18:37:44 How much resources do you have right now? 18:37:58 sorry for being dick-ish here, this is a thing that comes up not infrequently and often folks just don't understand how our project is developed 18:38:23 mosaid: TBH, desktop users are key users, don't hesitate to install FreeBSD on you PC 18:39:10 I never used any kind of OS rather than Freebsd for nearly 6 years 18:39:15 and I liked it 18:39:38 OK, that's excellent 18:39:49 But when upgrade time comes.. 18:40:22 I found that when upgrade time comes I often mess things up because I didn't RTFM and still do certain things the same way I've done it for 20+ years :D 18:40:42 I am running old school upgrades, (make ...) that's best, supported since the beginning 18:41:10 mzar: my installation is super complicated, new stuff + old stuff (really really old stuff) 18:41:16 easy to break 18:41:52 I'm trying to setup Skylake GT2 [HD Graphics 520]. Do I only need to install drm-kmod and add i915kms to the kld_list? 18:41:55 every time I update something will surly break 18:42:14 same here, my systems were installed in early 2000s and are continuously upgraded (those from 1990 are already wiped) 18:42:37 Old user then.. nice :) 18:42:50 lessless2: I think yes 18:43:35 https://wiki.freebsd.org/Graphics 18:43:56 see this very useful 18:45:02 Back again to resources, I will try to afford some of my servers in near future 18:45:13 if you needed that 18:50:39 physical resourcing isn't the only consideration in a request like that, though 18:51:17 like, yes, we would need more builders, more space to mirror out packages, etc., but we also need the people-resources to actually backport on that kind of timeline 18:51:36 even just four years down the line, the tree will look significantly different than it does today 18:51:48 things get more and more non-trivial to backport, that time has to come from somewhere 18:56:04 kevans and all involved: good job, thanks for your hard work ! 19:00:38 Some strange question could I run Linuxulator with centos and ubuntu installed in same time? 19:04:50 Like will it cause some problem when sharing the same directories 19:07:34 mosaid: there is a sysctl value: compat.linux.emul_path: Linux runtime environment path. I think that means only one linux emulation environment can be run at the same time. 19:07:46 it defaults to /compat/linux 20:57:38 on all my servers i see like 8 getty command processes running in ttyin state. is that ram going to waste? 21:12:28 * ivy ponders rewriting ports in lua 21:15:49 * asdasd 21:16:03 ivy: how did you write your last msg? 21:16:31 nxjoseph: it's called in action, in most IRC clients "/me does something" is the command for it 21:16:37 s/in action/an action 21:17:07 * nxjoseph tries to try his new knowledge 21:17:15 ivy: thanks! 21:17:28 im new in irc 21:53:41 nxjoseph, Most IRC clients consume lines that start with a / such as /me or /join or /part. But what if you want to start a line with something like /usr/local/bin ? In that case use the /say action. /say /usr/local/bin will not consume the /usr part as a command and will say it. 21:55:42 rwp: / / 21:55:44 kerneldove, Multiple processes will share code pages in memory. You need to have at least one getty running for being able to log into the console. Having a small number of additional of those processes running will consume a miniscule amount of copied-on-written data memory since there is little data there. Having 8 getty processes versus 1 or 2 is insignificant of resources but hugely useful when needed. 21:57:36 It's also a good reason that having swap configured is useful. If the kernel needs memory and there are pages wasted holding something that isn't being used then those pages can be pushed to swap storage and the ram freed up for use for other things. It's all dynamic, automatic, and useful. 21:59:03 ah ok 21:59:21 tyvm 23:02:45 <_opr> kerneldove: yes, that's the beauty of it i'm 100% sure. but what's happening is intersting, running docker microservices for a web doesnt cause as much cpu as bhyve... if i want to fire up like 3 byhve hosts on my laptop, it would burn... not sure why. 23:03:18 <_opr> tsoome: XD they will say go back to dig yourself why. 23:10:08 _opr maybe file a bug with a reproducible case? 23:16:18 <_opr> kerneldove: problem is is this qualified as a bug, no issues when using bhyve and it's solid, just performance wise, eating a lot of CPU and that's it. It's always the case, fireup byhyve host, my laptop CPU is about 70-80 degrees, yet not much impact from those docker containers (3 at least). What I have in mind is these containers are all running in one docker-machine host on virtualbox, but again, it's 23:16:24 <_opr> virtualbox we're talking about. Just my guess. I'll see what I can do. thx guys. 23:24:27 _opr, sure, performance outliers are helpful for devs to know about. just do all you can to make it concise and include reproducibility steps 23:24:42 devs are really good about addressing bug reports when we make it easy for them 23:29:48 Usually I just say "it doesn't work" and pat myself on the back for another fine bug report. /s 23:31:16 <_opr> XD 23:32:03 <_opr> kerneldove: Thanks for the tips. 23:32:10 yw