Re: zfs on hardware raid array
> On Jan 19, 2019, at 2:31 PM, Brian Bilbrey wrote: > > (Bcc’d to the OP) > > You *could* do what I’ve done in the past - make each disk into a single disk > volume presented by the array, then use the presented volumes to make your > mirrors, z2s, etc… I’m not running that anymore, but it was fine and reliable > for years. A failed disk could be replaced in the array, then re-presented to > the OS for rebuild. I actually kept a presented volume back to use as a warm > spare in those circumstances. > > A reasonably inexpensive alternative is to replace the controller with one > that permits JBOD. [ BCC'd to the poster above ] We have some Oracle X5 servers that are also unable to configure the SAS disks as JBOD. We do the same thing, each disk is a separate volume, and we just use ZFS mirrors on the individual volumes. We thought it strange that Oracle would spec hardware (I think it's an LSI controller) that didn't allow JBOD when they themselves recommend not using hardware RAID for ZFS, and also don't support booting from anything other than ZFS (starting with Solaris 11). -- DE ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: DDD hangs on start on 11.1-R
On Mon, 5 Mar 2018, Trond Endrest?l wrote: On Sat, 3 Mar 2018 18:09+0100, Holm Tiffe wrote: can anyone get ddd get to work in 11.1-R or stable? I've more or less given up on devel/ddd, since it relies on the old pty subsystem, now replaced by the new pts subsystem, to communicate with gdb. I build custom kernels containing "device pty", but I'm not sure if that directive is being honoured these days. It's a shame, 'cos ddd is very good at visualizing data structures. Maybe it's possible to patch ddd to use pts instead of pty. I used to like ddd also. You might try devel/gps. It's more than just a debugger, but you can use it just for debugging. Note, it's been a while since I've used it, but worked similarly to ddd. -- DE___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Cross buildworld on amd64 for i386 errors
On Mon, 25 Jan 2016, Daniel Eischen wrote: I'm trying to build an i386 buildworld on an amd64 system. I'm at r294370. I just updated to r294737 and tried again without the -j8. This is what I've tried so far: make TARGET_ARCH=i386 MAKEOBJDIRPREFIX=/opt/foo/obj.x86 -j8 buildworld make TARGET=i386 MAKEOBJDIRPREFIX=/opt/foo/obj.x86 -j8 buildworld Neither of which work. They both result in the error below. What is the standard procedure for cross-building i386 from amd64? This is where it stops now: MAKEOBJDIRPREFIX=/opt/foo/10-stable/src/rescue/rescue make -f rescue.mk exe cc -O2 -pipe -c /opt/foo/10-stable/src/bin/cp/utils.c -o /opt/foo/10-stable/src/bin/cp/utils.o /opt/foo/10-stable/src/bin/cp/utils.c:514:14: error: member reference base type 'void' is not a structure or union aclp = >ats_acl; ~~~^ ~~~ /opt/foo/10-stable/src/bin/cp/utils.c:515:11: error: incomplete definition of type 'struct acl' if (aclp->acl_cnt != 0 && aclsetf(dest_dir, ^ /opt/foo/10-stable/src/bin/cp/utils.c:465:9: note: forward declaration of 'struct acl' struct acl *aclp; ^ 2 errors generated. *** Error code 1 Stop. make[5]: stopped in /opt/foo/10-stable/src/rescue/rescue *** Error code 1 Stop. make[4]: stopped in /opt/foo/10-stable/src/rescue/rescue *** Error code 1 Stop. make[3]: stopped in /opt/foo/10-stable/src/rescue *** Error code 1 Stop. make[2]: stopped in /opt/foo/10-stable/src *** Error code 1 About to rm -rf the obj directory and try again. -- DE ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Cross buildworld on amd64 for i386 errors
I'm trying to build an i386 buildworld on an amd64 system. I'm at r294370. This is what I've tried so far: make TARGET_ARCH=i386 MAKEOBJDIRPREFIX=/opt/foo/obj.x86 -j8 buildworld make TARGET=i386 MAKEOBJDIRPREFIX=/opt/foo/obj.x86 -j8 buildworld Neither of which work. They both result in the error below. What is the standard procedure for cross-building i386 from amd64? --- sbin.all__D --- cc -fpic -DPIC -O2 -pipe -I/opt/foo/src/sbin/geom/class/mirror/../.. -std=gnu99 -Qunused-arguments -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -c /opt/foo/src/sbin/geom/class/mirror/geom_mirror.c -o geom_mirror.So --- sys.all__D --- --- panic.o --- cc -O2 -pipe -DLOADER_NFS_SUPPORT -DBOOT_FORTH -I/opt/foo/src/sys/boot/i386/loader/../../ficl -I/opt/foo/src/sys/boot/i386/loader/../../ficl/i386 -DLOADER_GZIP_SUPPORT -DLOADER_DISK_SUPPORT -DLOADER_GPT_SUPPORT -DLOADER_MBR_SUPPORT -I/opt/foo/src/sys/boot/i386/loader/../../common -I. -Wall -I/opt/foo/src/sys/boot/i386/loader/.. -I/opt/foo/src/sys/boot/i386/loader/../btx/lib -march=i386 -ffreestanding -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -msoft-float -std=gnu99 -Qunused-arguments -c /opt/foo/src/sys/boot/i386/loader/../../common/panic.c -o panic.o --- secure.all__D --- --- comp_err.po --- --- share.all__D --- --- charset.pivot.APPLE --- echo "# APPLE" > charset.pivot.APPLE printf "%-32s%-32s%d\n" ARABIC UCS 1 >> charset.pivot.APPLE printf "%-32s%-32s%d\n" UCS ARABIC 1 >> charset.pivot.APPLE printf "%-32s%-32s%d\n" CELTIC UCS 1 >> charset.pivot.APPLE printf "%-32s%-32s%d\n" UCS CELTIC 1 >> charset.pivot.APPLE printf "%-32s%-32s%d\n" CENTEURO UCS 1 >> charset.pivot.APPLE printf "%-32s%-32s%d\n" UCS CENTEURO 1 >> charset.pivot.APPLE printf "%-32s%-32s%d\n" CROATIAN UCS 1 >> charset.pivot.APPLE printf "%-32s%-32s%d\n" UCS CROATIAN 1 >> charset.pivot.APPLE printf "%-32s%-32s%d\n" CYRILLIC UCS 1 >> charset.pivot.APPLE printf "%-32s%-32s%d\n" UCS CYRILLIC 1 >> charset.pivot.APPLE printf "%-32s%-32s%d\n" DEVANAGA UCS 1 >> charset.pivot.APPLE printf "%-32s%-32s%d\n" UCS DEVANAGA 1 >> charset.pivot.APPLE printf "%-32s%-32s%d\n" DINGBATS UCS 1 >> charset.pivot.APPLE printf "%-32s%-32s%d\n" UCS DINGBATS 1 >> charset.pivot.APPLE printf "%-32s%-32s%d\n" FARSI UCS 1 >> charset.pivot.APPLE --- secure.all__D --- cc -pg -O2 -pipe -DTERMIOS -DANSI_SOURCE -I/opt/foo/src/secure/lib/libcrypto/../../../crypto/openssl -I/opt/foo/src/secure/lib/libcrypto/../../../crypto/openssl/crypto -I/opt/foo/obj.x86/opt/foo/src/secure/lib/libcrypto -DOPENSSL_THREADS -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -DOPENSSL_IA32_SSE2 -DAES_ASM -DVPAES_ASM -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DMD5_ASM -DGHASH_ASM -DRMD160_ASM -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DWHIRLPOOL_ASM -I/opt/foo/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/asn1 -I/opt/foo/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/evp -I/opt/foo/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/modes -std=gnu89 -Qunused-arguments -fstack-protector -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -c /opt/foo/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/comp/comp_err.c -o comp_err.po --- share.all__D --- printf "%-32s%-32s%d\n" UCS FARSI 1 >> charset.pivot.APPLE printf "%-32s%-32s%d\n" GAELIC UCS 1 >> charset.pivot.APPLE printf "%-32s%-32s%d\n" UCS GAELIC 1 >> charset.pivot.APPLE printf "%-32s%-32s%d\n" GREEK UCS 1 >> charset.pivot.APPLE printf "%-32s%-32s%d\n" UCS GREEK 1 >> charset.pivot.APPLE printf "%-32s%-32s%d\n" GUJARATI UCS 1 >> charset.pivot.APPLE printf "%-32s%-32s%d\n" UCS GUJARATI 1 >> charset.pivot.APPLE printf "%-32s%-32s%d\n" GURMUKHI UCS 1 >> charset.pivot.APPLE printf "%-32s%-32s%d\n" UCS GURMUKHI 1 >> charset.pivot.APPLE printf "%-32s%-32s%d\n" HEBREW UCS 1 >> charset.pivot.APPLE printf "%-32s%-32s%d\n" UCS HEBREW 1 >> charset.pivot.APPLE printf "%-32s%-32s%d\n" ICELAND UCS 1 >> charset.pivot.APPLE printf "%-32s%-32s%d\n" UCS ICELAND 1 >> charset.pivot.APPLE printf "%-32s%-32s%d\n" INUIT UCS 1 >> charset.pivot.APPLE printf "%-32s%-32s%d\n" UCS INUIT 1 >> charset.pivot.APPLE printf "%-32s%-32s%d\n" KEYBOARD UCS 1 >> charset.pivot.APPLE printf "%-32s%-32s%d\n" UCS KEYBOARD 1 >> charset.pivot.APPLE printf "%-32s%-32s%d\n" ROMAN UCS 1 >> charset.pivot.APPLE printf "%-32s%-32s%d\n" UCS ROMAN 1 >> charset.pivot.APPLE printf
Re: Cross buildworld on amd64 for i386 errors
On Mon, 25 Jan 2016, Craig Rodrigues wrote: On Mon, Jan 25, 2016 at 1:55 PM, Daniel Eischen <deisc...@freebsd.org> wrote: I'm trying to build an i386 buildworld on an amd64 system. I'm at r294370. This is what I've tried so far: make TARGET_ARCH=i386 MAKEOBJDIRPREFIX=/opt/foo/obj.x86 -j8 buildworld make TARGET=i386 MAKEOBJDIRPREFIX=/opt/foo/obj.x86 -j8 buildworld Neither of which work. They both result in the error below. What is the standard procedure for cross-building i386 from amd64? It looks like you are not alone in encountering these problems. For this build set up by Li-Wen Hsu: https://jenkins.freebsd.org/job/FreeBSD_HEAD_i386 he downloads this image http://ftp.freebsd.org/pub/FreeBSD/releases/i386/i386/10.2-RELEASE/base.txz and then extracts that to create an i386 jail, where the build is performed on an amd64 host. I guess there was a real compilation bug in the version of -stable that I first used. After updating from r294370 to r294747, the problem seems to have been fixed. FYI, the following worked: make TARGET_ARCH=i386 -j4 buildworld -- DE ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Cross buildworld on amd64 for i386 errors
On Mon, 25 Jan 2016, Craig Rodrigues wrote: On Mon, Jan 25, 2016 at 1:55 PM, Daniel Eischen <deisc...@freebsd.org> wrote: I'm trying to build an i386 buildworld on an amd64 system. I'm at r294370. This is what I've tried so far: make TARGET_ARCH=i386 MAKEOBJDIRPREFIX=/opt/foo/obj.x86 -j8 buildworld make TARGET=i386 MAKEOBJDIRPREFIX=/opt/foo/obj.x86 -j8 buildworld Neither of which work. They both result in the error below. What is the standard procedure for cross-building i386 from amd64? It looks like you are not alone in encountering these problems. For this build set up by Li-Wen Hsu: https://jenkins.freebsd.org/job/FreeBSD_HEAD_i386 he downloads this image http://ftp.freebsd.org/pub/FreeBSD/releases/i386/i386/10.2-RELEASE/base.txz and then extracts that to create an i386 jail, where the build is performed on an amd64 host. Currently, I'm just trying to test out the cross-build, but the final result is that I want to use nanobsd to create embedded images, all from amd64. Multiple people here want to be able to do that. I don't really want to have to setup a jail (with LDAP logins, cause that's what we use) or even an x86 box to do that. I thought even ARM and MIPS cross-builds worked, I didn't expect amd64->i386 problems. I think I will ask on -current, as that is also an option for us. -- DE ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Trying to clone a ZFS drive, can't get ashift=12
On Tue, 31 Mar 2015, Peter Wemm wrote: On Wednesday, April 01, 2015 12:30:46 AM Daniel Eischen wrote: I have an Oracle (nee Sun) X4-2 server with identical 300GB SAS drives. I did an MBR ZFS install from FreeBSD 10.1-RELEASE CD and have it updated to p6: [..] # zpool create -o cachefile=/tmp/newpool.cache bootpoolNew label/boot0 # zdb -U /tmp/newpool.cache | grep ashift ashift: 9 What gives? How do I get it to use 4k? Before creating the pool, try: # sysctl vfs.zfs.min_auto_ashift=12 Thanks, and to Dmitri also. This seemed to do the trick. It is interesting that the default in the 10.1-RELEASE CD doesn't match the actual OS that is installed. But watch your alignment of the MBR slices/partitions. I think you'll find it easier to manage with gpt for a data disk, eg: # gpart create -s gpt da1 # gpart add -t freebsd-zfs -a 4k da1 combine that with the sysctl above you should have everything on 4k. Setting -a just sets the rounding for the start/end sectors, it doesn't affect zfs when its sizing the sector size internally. btw; for a 300G drive you might not want 4k - this changes the base allocation size to be 8 times larger. You might find your space efficiency less than ideal if you have a lot of tiny files. The server is a web server and poudriere package builder, with some postgres and mysql databases as backends for the web services. We don't anticipate user data or home/project directories. My first ZFS install was Solaris 11, which recommended (mandated?) that rpool be from a slice not an entire disk, and boot from an SMI (VTOC) disk. So I followed the same convention when installing FreeBSD. -- DE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Trying to clone a ZFS drive, can't get ashift=12
I have an Oracle (nee Sun) X4-2 server with identical 300GB SAS drives. I did an MBR ZFS install from FreeBSD 10.1-RELEASE CD and have it updated to p6: $ uname -a FreeBSD foo 10.1-RELEASE-p6 FreeBSD 10.1-RELEASE-p6 #0: Tue Feb 24 19:00:21 UTC 2015 r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 $ freebsd-version 10.1-RELEASE-p6 The current ZFS setup is: $ zdb | grep ashift ashift: 12 ashift: 12 $ zpool status pool: bootpool state: ONLINE scan: resilvered 486M in 0h0m with 0 errors on Thu Mar 26 09:16:45 2015 config: NAMESTATE READ WRITE CKSUM bootpool ONLINE 0 0 0 diskid/DISK-001442CBEEKF%20%20%20%20%20%20%20%20KFHBEEKFs1a ONLINE 0 0 0 pool: zroot state: ONLINE scan: resilvered 200K in 0h0m with 0 errors on Wed Mar 25 10:51:36 2015 config: NAMESTATE READ WRITE CKSUM zroot ONLINE 0 0 0 diskid/DISK-001442CBEEKF%20%20%20%20%20%20%20%20KFHBEEKFs1d ONLINE 0 0 0 $ gpart show diskid/DISK-001442CBEEKF%20%20%20%20%20%20%20%20KFHBEEKF = 63 585937437 diskid/DISK-001442CBEEKF%20%20%20%20%20%20%20%20KFHBEEKF MBR (279G) 63 585937422 1 freebsd [active] (279G) 585937485 15 - free - (7.5K) $ gpart show diskid/DISK-001442CBEEKF%20%20%20%20%20%20%20%20KFHBEEKFs1 =0 585937422 diskid/DISK-001442CBEEKF%20%20%20%20%20%20%20%20KFHBEEKFs1 BSD (279G) 04194304 1 freebsd-zfs (2.0G) 41943048388608 2 freebsd-swap (4.0G) 12582912 573354510 4 freebsd-zfs (273G) [Why are the disk ids blank %20 filled?] Now I want to create another (sorta) matching setup, but this time want to use labels and 4G (instead of 2G) for bootpool. # gpart create -s MBR da1 # gpart add -t freebsd da1 # gpart create -s BSD da1s1 # gpart add -s 4G -t freebsd-zfs da1s1 # gpart add -s 4G -t freebsd-swap da1s1 # gpart add -t freebsd-zfs da1s1 # gpart show da1 = 63 585937437 da1 MBR (279G) 63 5859374221 freebsd (279G) 585937485 15 - free - (7.5K) # gpart show da1s1 =0 585937422 da1s1 BSD (279G) 08388608 1 freebsd-zfs (4.0G) 83886088388608 2 freebsd-swap (4.0G) 16777216 569160206 4 freebsd-zfs (271G) Except for da1s1a being 4G instead of 2G, everything matches the ZFS setup above. Make the labels. # glabel label boot0 da1s1a # glabel label swap0 da1s1b # glabel label root0 da1s1d Create the ZFS bootpool. # zpool create -o cachefile=/tmp/newpool.cache bootpoolNew label/boot0 # zdb -U /tmp/newpool.cache | grep ashift ashift: 9 The geometry matches, but ashift is 9 not 12. If I try to use 4K, the disk geometry doesn't match the original and ashift is still 9 instead of 12. # gpart create -s MBR da1 # gpart add -a 4k -t freebsd da1 # gpart create -s BSD da1s1 # gpart add -a 4k -s 4G -t freebsd-zfs da1s1 # gpart add -a 4k -s 4G -t freebsd-swap da1s1 # gpart add -a 4k -t freebsd-zfs da1s1 # gpart show da1 = 63 585937437 da1 MBR (279G) 63 63 - free - (32K) 126 5859373591 freebsd [active] (279G) 585937485 15 - free - (7.5K) # gpart show da1s1 =0 585937359 da1s1 BSD (279G) 0 2 - free - (1.0K) 28388608 1 freebsd-zfs (4.0G) 83886108388608 2 freebsd-swap (4.0G) 16777218 569160136 4 freebsd-zfs (271G) 585937354 5 - free - (2.5K) # zpool create -o cachefile=/tmp/newpool.cache bootpoolNew label/boot0 # zdb -U /tmp/newpool.cache | grep ashift ashift: 9 What gives? How do I get it to use 4k? -- DE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: LDAP authentication confusion
On Mon, 15 Jul 2013, Michael Loftis wrote: nss_ldap fulfills most of the get*ent calls, thus based on the bits of your configuration you've exposed I think you're ending up with that behavior and not using pam_ldap at all. Instead the authentication is happening via nsswitch fulfilling getpwent() call's (the passwd: files ldap line in nsswitch.conf) Ok, thanks. But shouldn't the documentation be changed to reflect that? On Mon, Jul 15, 2013 at 11:51 AM, Daniel Eischen deisc...@freebsd.org wrote: There's an article on LDAP authentication on FreeBSD here: http://www.freebsd.org/doc/en/articles/ldap-auth/article.html#client I'm confused as to why pam_ldap and nss_ldap do not need /etc/pam.d entries, as described in the above link in section 3.1.1. Meaning, I do not have any ldap entries in my /etc/pam.d/ or even /usr/local/etc/pam.d/ and ldap logins work (console, ssh, telnet, ftp). $ grep -i ldap /etc/pam.d/* $ grep -i ldap /usr/local/etc/pam.d/* What am I missing? $ uname -v FreeBSD slrtr1 9.1-STABLE FreeBSD 9.1-STABLE #0 r250347... $ uname -m amd64 $ cat /etc/nsswitch.conf group: files ldap hosts: files dns networks: files passwd: files ldap shells: files services: files protocols: files rpc: files -- DE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: LDAP authentication confusion
On Mon, 15 Jul 2013, Jan Bramkamp wrote: On 15.07.2013 21:09, Daniel Eischen wrote: On Mon, 15 Jul 2013, Michael Loftis wrote: nss_ldap fulfills most of the get*ent calls, thus based on the bits of your configuration you've exposed I think you're ending up with that behavior and not using pam_ldap at all. Instead the authentication is happening via nsswitch fulfilling getpwent() call's (the passwd: files ldap line in nsswitch.conf) Ok, thanks. But shouldn't the documentation be changed to reflect that? More than that. In my opinion it should be updated by replacing nss_ldap and pam_ldap with nss-pam-ldapd which splits the job of both into a shared daemon talking to the LDAP server and small stubs linked into the NSS / PAM using process talking to the local daemon. This allows useable timeout handling and client certificates with save permissions. I tried nss-pam-ldapd and it doesn't work for me. I'm not doing anything strange, as you can see by my configuration. It would try to talk to the LDAP server, but would fail. I'm not sure it was correctly picking up the proxyagent password in my /usr/local/etc/nslcd.conf. It was definitely parsing it though, as that is where the LDAP server is defined. I switched to using pam_ldap and nss_ldap, and it worked without any problem. -- DE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: LDAP authentication confusion
On Mon, 15 Jul 2013, Mark Felder wrote: On Mon, Jul 15, 2013, at 14:09, Daniel Eischen wrote: Ok, thanks. But shouldn't the documentation be changed to reflect that? Whoa, I need to test this now, as we are used to being able to turn this on/off by editing /etc/pam.d/system and sshd Wouldn't it be easier just to edit /etc/nsswitch.conf anyway? -- DE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: LDAP authentication confusion
On Mon, 15 Jul 2013, Jan Bramkamp wrote: On 15.07.2013 21:44, Daniel Eischen wrote: On Mon, 15 Jul 2013, Jan Bramkamp wrote: On 15.07.2013 21:09, Daniel Eischen wrote: On Mon, 15 Jul 2013, Michael Loftis wrote: nss_ldap fulfills most of the get*ent calls, thus based on the bits of your configuration you've exposed I think you're ending up with that behavior and not using pam_ldap at all. Instead the authentication is happening via nsswitch fulfilling getpwent() call's (the passwd: files ldap line in nsswitch.conf) Ok, thanks. But shouldn't the documentation be changed to reflect that? More than that. In my opinion it should be updated by replacing nss_ldap and pam_ldap with nss-pam-ldapd which splits the job of both into a shared daemon talking to the LDAP server and small stubs linked into the NSS / PAM using process talking to the local daemon. This allows useable timeout handling and client certificates with save permissions. I tried nss-pam-ldapd and it doesn't work for me. I'm not doing anything strange, as you can see by my configuration. It would try to talk to the LDAP server, but would fail. I'm not sure it was correctly picking up the proxyagent password in my /usr/local/etc/nslcd.conf. It was definitely parsing it though, as that is where the LDAP server is defined. I switched to using pam_ldap and nss_ldap, and it worked without any problem. This is my basic nscld.conf: Thanks, mine is simpler. I just tried again. $ sudo grep -v ^# /usr/local/etc/nslcd.conf | sort -u base dc=foo,dc=bar,dc=com binddn cn=proxyagent,dc=foo,dc=bar,dc=com bindpw ... gid nslcd uid nslcd uri ldap://192.168.3.96/ Everything else is default. All the entries above match the respective settings I used in the working ldap.conf and nss_ldap.conf. We're using Oracle DSEE7 (nee Sun Java Directory Server). -- DE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: LDAP authentication confusion
On Mon, 15 Jul 2013, Jan Bramkamp wrote: On 15.07.2013 21:51, Daniel Eischen wrote: Wouldn't it be easier just to edit /etc/nsswitch.conf anyway? PAM and NSS switch are two different subsystems. NSS is just for resource lookups (users, groups, hosts, ...). PAM is for access control. With ldap in nsswitch.conf for users and groups you can lookup a LDAP user but the user can't log into $service through PAM. This requires pam_ldap.so in pam.d/$service. Minor correction. This requires the ldap PAM library (pam_ldap.so) to be installed. No pam.d entries seem to be needed. None seem to be necessary on Solaris 10 either. -- DE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: LDAP authentication confusion
On Tue, 16 Jul 2013, Jan Bramkamp wrote:
On 16.07.2013 00:47, Ben Morrow wrote:
Quoth Jan Bramkamp cr...@rlwinm.de:
On 15.07.2013 21:51, Daniel Eischen wrote:
Wouldn't it be easier just to edit /etc/nsswitch.conf
anyway?
PAM and NSS switch are two different subsystems. NSS is just for
resource lookups (users, groups, hosts, ...). PAM is for access control.
With ldap in nsswitch.conf for users and groups you can lookup a LDAP
user but the user can't log into $service through PAM. This requires
pam_ldap.so in pam.d/$service.
The default pam_unix.so calls getpwent, so if nss_ldap returns cryptable
passwords in its result I think pam_unix can authenticate against those.
This is not the same as authenticating by LDAP bind, but may end up
accepting the same passwords.
If you want every process to read your hashed passwords and you use
non-portable crypt hashes it could work. The correct solution would be
authenticate users by LDAP binds without allowing anyone to read the
password or to use the {SASL} password style and authenticate users
against Kerberos with saslauthd. Just don't let you users play with
passwords. Either your password policy allows dumb users to pick trivial
password or it forces complex password structures on them resulting in
post-it notes with passwords around every second desk.
I think something is lost on me here. getpwent/getpwuid do
not return the password hashes in the returned struct passwd
unless the calling process is root. So you have to be root in
order to see the hashes anyway. Not all users are going to
have access to the hashes, unless your machine's compromised
or otherwise allows root privileges to others.
--
DE
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: LDAP authentication confusion
On Tue, 16 Jul 2013, Jan Bramkamp wrote:
On 16.07.2013 04:28, Daniel Eischen wrote:
On Tue, 16 Jul 2013, Jan Bramkamp wrote:
On 16.07.2013 00:47, Ben Morrow wrote:
Quoth Jan Bramkamp cr...@rlwinm.de:
On 15.07.2013 21:51, Daniel Eischen wrote:
Wouldn't it be easier just to edit /etc/nsswitch.conf
anyway?
PAM and NSS switch are two different subsystems. NSS is just for
resource lookups (users, groups, hosts, ...). PAM is for access
control.
With ldap in nsswitch.conf for users and groups you can lookup a LDAP
user but the user can't log into $service through PAM. This requires
pam_ldap.so in pam.d/$service.
The default pam_unix.so calls getpwent, so if nss_ldap returns cryptable
passwords in its result I think pam_unix can authenticate against those.
This is not the same as authenticating by LDAP bind, but may end up
accepting the same passwords.
If you want every process to read your hashed passwords and you use
non-portable crypt hashes it could work. The correct solution would be
authenticate users by LDAP binds without allowing anyone to read the
password or to use the {SASL} password style and authenticate users
against Kerberos with saslauthd. Just don't let you users play with
passwords. Either your password policy allows dumb users to pick trivial
password or it forces complex password structures on them resulting in
post-it notes with passwords around every second desk.
I think something is lost on me here. getpwent/getpwuid do
not return the password hashes in the returned struct passwd
unless the calling process is root. So you have to be root in
order to see the hashes anyway. Not all users are going to
have access to the hashes, unless your machine's compromised
or otherwise allows root privileges to others.
If the crypted password can be read by an LDAP client with the
information available to every process in (nss_)ldap.conf you're crypted
passwords are easily accessible for offline attacks. Their is no reason
for an attacker to go through the getpwent/getpwuid API.
The root bind password is kept in a separate file that only
root has read rights to. I don't think the password hashes
are available when binding anonymously or through the proxy
agent.
--
DE
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: LDAP authentication confusion
On Mon, 15 Jul 2013, Daniel Eischen wrote: On Tue, 16 Jul 2013, Jan Bramkamp wrote: On 16.07.2013 04:28, Daniel Eischen wrote: [ ... ] I think something is lost on me here. getpwent/getpwuid do not return the password hashes in the returned struct passwd unless the calling process is root. So you have to be root in order to see the hashes anyway. Not all users are going to have access to the hashes, unless your machine's compromised or otherwise allows root privileges to others. If the crypted password can be read by an LDAP client with the information available to every process in (nss_)ldap.conf you're crypted passwords are easily accessible for offline attacks. Their is no reason for an attacker to go through the getpwent/getpwuid API. The root bind password is kept in a separate file that only root has read rights to. I don't think the password hashes are available when binding anonymously or through the proxy agent. I guess I was wrong - it seems the proxy agent by default (at least with Oracle DSEE7) has read access to the userPassword attribute. I'll have to try adding an ACI, as suggested by Michael Butler, to restrict that. -- DE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Any objections/comments on axing out old ATA stack?
On Thu, 28 Mar 2013, Ian Lepore wrote: On Thu, 2013-03-28 at 09:17 +0200, Alexander Motin wrote: On 28.03.2013 02:43, Adrian Chadd wrote: My main concern with the new stuff is that it requires CAM and that's reasonably big compared to the standalone ATA code. It'd be nice if we could slim down the CAM stack a bit first; it makes embedding it on the smaller devices really freaking painful. Are there many boards now with ATA, but without USB? But I agree, it should be checked. It's not necessarily what the boards have but how they're used. We use industrial SBCs at work that have ata compact flash sockets on the board which we do use, and usb interfaces which we don't use. I've never tested the new ata+cam stuff on some of these boards, most based on Cyrix, Via, Geode, and VortexD86 chipsets. The older ata code works, but not always very well -- for example, we usually have to set hw.ata.ata_dma=0 for absolutely no reason we've ever been able to figure out except that if we leave it enabled we get DMA errors and panics on some CF cards and not on others. I have no idea whether to expect such things to be better, worse, or no different by changing to the ata+cam way of doing things (but I don't really have time to do extensive testing right now either). Woa, I have to set hw.ata.ata_dma=0 also in order to get FreeBSD to boot on a PC104 board. I think ours is a Cyrix or Via also. -- DE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Musings on ZFS Backup strategies
On Fri, 1 Mar 2013, Ben Morrow wrote: Quoth Karl Denninger k...@denninger.net: Dabbling with ZFS now, and giving some thought to how to handle backup strategies. [...] Take a base snapshot immediately and zfs send it to offline storage. Take an incremental at some interval (appropriate for disaster recovery) and zfs send THAT to stable storage. If I then restore the base and snapshot, I get back to where I was when the latest snapshot was taken. I don't need to keep the incremental snapshot for longer than it takes to zfs send it, so I can do: zfs snapshot pool/some-filesystem@unique-label zfs send -i pool/some-filesystem@base pool/some-filesystem@unique-label zfs destroy pool/some-filesystem@unique-label and that seems to work (and restore) just fine. For backup purposes it's worth using the -R and -I options to zfs send rather than -i. This will preserve the other snapshots, which can be important. Am I looking at this the right way here? Provided that the base backup and incremental are both readable, it appears that I have the disaster case covered, and the online snapshot increments and retention are easily adjusted and cover the oops situations without having to resort to the backups at all. This in turn means that keeping more than two incremental dumps offline has little or no value; the second merely being taken to insure that there is always at least one that has been written to completion without error to apply on top of the base. That in turn makes the backup storage requirement based only on entropy in the filesystem and not time (where the tower of Hanoi style dump hierarchy imposed both a time AND entropy cost on backup media.) No, that's not true. Since you keep taking successive increments from a fixed base, the size of those increments will increase over time (each increment will include all net filesystem activity since the base snapshot). In UFS terms, it's equivalent to always taking level 1 dumps. Unlike with UFS, the @base snapshot will also start using increasing amounts of space in the source zpool. I don't know what medium you're backing up to (does anyone use tape any more?) but when backing up to disk I much prefer to keep the backup in the form of a filesystem rather than as 'zfs send' streams. One reason for this is that I believe that new versions of the ZFS code are more likely to be able to correctly read old versions of the filesystem than old versions of the stream format; this may not be correct any more, though. Yes, we still use a couple of DLT autoloaders and have nightly incrementals and weekly fulls. This is the problem I have with converting to ZFS. Our typical recovery is when a user says they need a directory or set of files from a week or two ago. Using dump from tape, I can easily extract *just* the necessary files. I don't need a second system to restore to, so that I can then extract the file. dump (and ufsdump for our Solaris boxes) _just work_, and we can go back many many years and they will still work. If we convert to ZFS, I'm guessing we'll have to do nightly incrementals with 'tar' instead of 'dump' as well as doing ZFS snapshots for fulls. This topic is very interesting to me, as we're at the point now (with Solaris 11 refusing to even boot from anything but ZFS) that we have to consider ZFS. -- DE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Musings on ZFS Backup strategies
On Fri, 1 Mar 2013, Ben Morrow wrote: Quoth Daniel Eischen deisc...@freebsd.org: Yes, we still use a couple of DLT autoloaders and have nightly incrementals and weekly fulls. This is the problem I have with converting to ZFS. Our typical recovery is when a user says they need a directory or set of files from a week or two ago. Using dump from tape, I can easily extract *just* the necessary files. I don't need a second system to restore to, so that I can then extract the file. As Karl said originally, you can do that with snapshots without having to go to your backups at all. With the right arrangements (symlinks to the .zfs/snapshot/* directories, or just setting the snapdir property to 'visible') you can make it so users can do this sort of restore themselves without having to go through you. It wasn't clear that snapshots were traversable as a normal directory structure. I was thinking it was just a blob that you had to roll back to in order to get anything out of it. Under our current scheme, we would remove snapshots after the next (weekly) full zfs send (nee dump), so it wouldn't help unless we kept snapshots around a lot longer. Am I correct in assuming that one could: # zfs send -R snapshot | dd obs=10240 of=/dev/rst0 to archive it to tape instead of another [system:]drive? -- DE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Musings on ZFS Backup strategies
On Fri, 1 Mar 2013, kpn...@pobox.com wrote: On Fri, Mar 01, 2013 at 12:23:31PM -0500, Daniel Eischen wrote: Yes, we still use a couple of DLT autoloaders and have nightly incrementals and weekly fulls. This is the problem I have with converting to ZFS. Our typical recovery is when a user says they need a directory or set of files from a week or two ago. Using dump from tape, I can easily extract *just* the necessary files. I don't need a second system to restore to, so that I can then extract the file. dump (and ufsdump for our Solaris boxes) _just work_, and we can go back many many years and they will still work. If we convert to ZFS, I'm guessing we'll have to do nightly incrementals with 'tar' instead of 'dump' as well as doing ZFS snapshots for fulls. What about extended attributes? ACLs? Are those saved by tar? I think tar (as root or -p) will attempt to preserve those. -- DE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: intel kms, xorg and triple head?
On Mon, 18 Feb 2013, Harald Schmalzbauer wrote: Hello, I wasn't able to find infos about multi-head support for the new intel kms with FreeBSD 9.1 Is it possible to have xorg driving 3 displays? I know of the two-PLL-pipe limitation with intel's IvyBrindge-CPU/GPUs. But I don't know if the new driver supports possible configurations? (e.G. 2x1600x1200 + 1x1920x1200). Has anybody running xorg and 3 displays with i915kms? Or is it at least said to be supported? I barely have one display (laptop) working with KMS. Once X is up, trying to switch to a virtual console leaves you with a blank screen until you reboot. I have 2 graphics controllers in this laptop and have to cut one of them out of my xorg.conf in order for it to work. This laptop isn't meant to use both graphics controllers at the same time, so perhaps your configuration will work much better - I'd be curious to know. -- DE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: SU+J on 9.1-RC2 ISO
On Sat, 3 Nov 2012, Adam Strohl wrote: On 11/2/2012 23:47, Bas Smeelen wrote: Hi Why are journaled soft updates the default when installing a new system from a 9.1-RC2 ISO? I admit I did not pay too much attention when installing a new system from an 9.1-RC2 ISO and found out when taking a snapshot with dump (dump -0Lauf) to clone the system. Other systems (9-STABLE, 9.1-RC2 and 9.1-RC3) have been upgraded from 8.X-RELEASE and earlier, so there are no journaled soft updates enabled, just soft updates, and well there dump with snapshot works just fine. Can SU+J be disabled for the 9.1-RELEASE or do you think this is not going to be a problem for users of FreeBSD? I will have to boot these two systems single user now to disable the soft updates journal, because I use dump + restore on live systems, not a problem for me, it is just an inconvenience. I have to second this sentiment. Unless the dump/snapshot issue has been resolved they journal should be turned off by default. +1 -- DE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Issue with igb and lagg (was Re: Problem with link aggregation + sshd)
On Tue, 18 Sep 2012, David DeSimone wrote: Daniel Eischen deisc...@freebsd.org wrote: My rc.conf is something like this: # # For now, force ath0 to use the same MAC address as xl0. # This works around a bug where lagg is unable to set the # MAC address of the underlying wlan0 interface. # ifconfig_ath0=ether 01:02:03:04:05:06 wlans_ath0=wlan0 ifconfig_wlan0=ssid SSID_FOO_NAME WPA I hope the above isn't literally what you're using for your MAC address. No, of course not :-) I thought it was obvious I elided my actual MAC address. -- DE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Issue with igb and lagg (was Re: Problem with link aggregation + sshd)
On Tue, 11 Sep 2012, Giulio Ferro wrote: Well, there definitely seems to be a problem with igb and lagg. igb alone works as it should, but doesn't seem to work properly in lagg. To be sure I started from scratch from a 9.0 release with nothing but: /etc/rc.conf --- ifconfig_igb0=inet ... ifconfig_igb1=up ifconfig_igb2=up ifconfig_igb3=up cloned_interfaces=lagg0 ifconfig_lagg0=laggproto lacp laggport igb1 laggport igb2 laggport igb3 My rc.conf is something like this: # # For now, force ath0 to use the same MAC address as xl0. # This works around a bug where lagg is unable to set the # MAC address of the underlying wlan0 interface. # ifconfig_ath0=ether 01:02:03:04:05:06 wlans_ath0=wlan0 ifconfig_wlan0=ssid SSID_FOO_NAME WPA ifconfig_xl0=up closed_interfaces=lagg0 ifconfig_lagg0=laggproto failover laggport xl0 laggport wlan0 ifconfig_lagg0_alias0=inet 10.0.0.4 netmask 0xff00 I use aliasX to add the address and netmask. -- DE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Issue with igb and lagg (was Re: Problem with link aggregation + sshd)
On Tue, 11 Sep 2012, Freddie Cash wrote: On Sep 11, 2012 2:12 PM, Giulio Ferro au...@zirakzigil.org wrote: cloned_interfaces=lagg0 ifconfig_lagg0=laggproto lacp laggport igb1 laggport igb2 laggport igb3 192.168.x.x/24 sshd_enable=YES --- This doesn't even manage to start sshd, it just hangs there at boot. Disabling lagg configuration everything works correctly. Just curious: does it work if you split the lagg configuration from the IP config: ifconfig_lagg0=laggproto ... ifconfig_lagg0_alias0=inet 192... I've had problems in the past with cloned interfaces not working right if you do everything in one ifconfig line. Never spent much time debugging it, though, as the split config always worked. This was my experience too, though it's been quite a while since I tried it combined onto the same ifconfig line. -- DE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Results of BIND RFC
On Fri, 2 Apr 2010, Kevin Oberman wrote: Date: Fri, 2 Apr 2010 03:14:54 -0700 From: Jeremy Chadwick free...@jdc.parodius.com Sender: owner-freebsd-sta...@freebsd.org I disagree (so what else is new?) It should be kept out of the base system. KISS: Doug pulling BIND out of the base system / going ports-only = excellent. Doug making a separate port for BIND-esque DNS query/maintenance tools = excellent. Both of the above can be made into packages. Vendors who use FreeBSD can incorporate said package(s) into their build infrastructure. Folks who do not have Internet connections (yet for some reason want said DNS tools) can install the package(s) from CD/DVD/USB. I want the bikeshed to be black. :-) I have very mixed feelings on this. I agree with arguments I have seen on both sides. I like being able to install FreeBSD and have a well integrated system with all of the basic tools installed for basic use. Things play together well. I don't use many of the base system tools. I use cups, postfix, customized ssh, and the ports version of BIND. I don't build the stuff I don't need (src.conf) and I don't mind them being there. On the other hand, for complex, heavy duty ports, keeping up to date with externally maintains tools (contrib) is a pain and the base system can get stuck with rather out of date tools as a result. (Remember perl?) Unless there is very strong support for a contributed tools, it's hopeless and, if the tool is evolving rapidly, as BIND is with DNSSEC, it's still hopeless. I really dread having to update my ports. I hate all the bloated dependencies that a lot of ports have. It's sometimes a hit or miss situtation; you never know whether your ports are going to build (update) fully or not. And it takes forever. Our ports team does a fantastic job, so no diss intended. But I am concerned about moving BIND into ports, even if there is a tools-only port. With BIND in base, I don't have to worry about updating or when to update - someone else decides when to update/patch the base BIND and I am happy with that. All I have to do is buildworld, which I do much more often than update ports. If there is already a WITHOUT_BIND knob, then I really don't see what advantage there is in moving BIND out of base. Anyone that wants to use a different resolver can already do that, with the only limitation that they have to buildworld to remove the base bind. -- DE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Passenger hangs on live and SEGV on tests possible threading / kernel bug?
On Thu, 17 Dec 2009, John Baldwin wrote: On Thursday 17 December 2009 6:12:07 am Steven Hartland wrote: We're having an issue with Passenger on FreeBSD where it will hang and stop processing any more requests the details are attach to the following bug report: http://code.google.com/p/phusion-passenger/issues/detail?id=318#c14 In addition the test suite crashes in what seems to be a very basic test, which I'm at a loss with. http://code.google.com/p/phusion-passenger/issues/detail?id=441 I'm thinking this may be a bugs in the FreeBSD either kernel or thread library as the crashes don't make any sense from the application side. Any advise on debugging or feedback on the stack traces would be much appreciated. For the hang it seems you have a thread waiting in a blocking read(), a thread waiting in a blocking accept(), and lots of threads creating condition variables. However, the pthread_cond_init() in libpthread (libthr on FreeBSD) doesn't call pthread_cleanup_push(), so your stack trace doesn't make sense to me. However, that may be gdb getting confused. The pthread_cleanup_push() frame may be cond_init(). However, it doesn't call umtx_op() (the _thr_umutex_init() call it makes just initializes the structure, it doesn't make a _umtx_op() system call). You might try posting on threads@ to try to get more info on this, but your pthread_cond_init() stack traces don't really make sense. Can you rebuild libc and libthr with debug symbols? Yes, good advice, I have noticed that you can't trust GDB stack traces unless libc and libthr have been built with debug (-g) enabled. -- DE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: pthread.h: typo in #define pthread_cleanup_push/pthread_cleanup_pop
On Wed, 25 Nov 2009, Mark Andrews wrote:
Report it using send-pr. That way the problem will make its way into the
bug tracking system.
In message 86aayc7z4g@zhuzha.ua1, Mikolaj Golub writes:
Hi,
I have problems with compiling our application under 8.0.
It fails due to these definitions in pthread.h that look like a typo or
incorrectly applied patch:
Did someone already reply to this?
I think the problem is in your application. You cannot
have push and pop at different nesting levels. The
start brace in the push is ended by the end brace in
pop on purpose. It is to enforce nesting levels.
170 #define pthread_cleanup_push(cleanup_routine, cleanup_arg)
\
171 {
\
172 struct _pthread_cleanup_info __cleanup_info__;
\
173 __pthread_cleanup_push_imp(cleanup_routine,
clean
up_arg,\
174 __cleanup_info__);
\
175 {
176
177 #define pthread_cleanup_pop(execute)
\
178 }
\
179 __pthread_cleanup_pop_imp(execute);
\
180 }
--
DE
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: pthread.h: typo in #define pthread_cleanup_push/pthread_cleanup_pop
On Wed, 25 Nov 2009, Mark Andrews wrote:
In message 20091124153422.gt2...@deviant.kiev.zoral.com.ua, Kostik Belousov
write
s:
--i616tqyc3hrkKsk2
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Tue, Nov 24, 2009 at 05:18:29PM +0200, Mikolaj Golub wrote:
pthread_cleanup_push/pop are supposed to be used from the common
lexical scope. Citation from SUSv4:
These functions may be implemented as macros. The application shall
ensure that they appear as statements, and in pairs within the same
lexical scope (that is, the pthread_cleanup_push() macro may be
thought to expand to a token list whose first token is '{' with
pthread_cleanup_pop() expanding to a token list whose last token is the
corresponding '}' ).
Your change is wrong.
Basically, the code should do
pthread_cleanup_push(some_func, arh);
something ...
pthread_cleanup_pop(1);
(1 denotes that some_func should be called).
The problem is that that expands to C code that can only be used
with newer C compilers. This expansion should be usable with all
C compilers.
#define pthread_cleanup_push(cleanup_routine, cleanup_arg) \
{ \
struct _pthread_cleanup_info __cleanup_info__; \
__pthread_cleanup_push_imp(cleanup_routine, cleanup
_arg,\
__cleanup_info__)
#define pthread_cleanup_pop(execute) \
__pthread_cleanup_pop_imp(execute);\
} ((void)0)
Hmm, agreed. But note that Solaris 10 does it this way:
#define pthread_cleanup_push(routine, args) { \
_cleanup_t _cleanup_info; \
__pthread_cleanup_push((_Voidfp)(routine), (void *)(args), \
(caddr_t)_getfp(), _cleanup_info);
#define pthread_cleanup_pop(ex) \
__pthread_cleanup_pop(ex, _cleanup_info); \
}
--
DE
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: samba - SIGABRT
On Thu, 8 Oct 2009, Robert Watson wrote: On Thu, 8 Oct 2009, Oliver Lehmann wrote: This was caused by your setting of the following: security.bsd.map_at_zero=0 You can reset that value to 1 and you should be alright to operate like normal otherwise you will have to compile samba over again with the above mentioned configure options. Yeah this caused the problem. I wonder how I could have find this by myself (google is not counting ;)) I mean, the Abort message is not very verbose what the problem is here Hi Oliver-- While it's probably a bug that the Samba port compiles --pie, it's also a bug that our linking bits aren't handling PIE properly either. The goal is to fix PIE with the non-NULL mapping feature in the immediate future, so with any luck the abort message won't matter too much longer. How about reverting this change or defaulting security.bsd.map_at_zero=1 until either ports can handle this properly or our -pie is fixed, and we've had at least a release with pre-built packages that don't have the problem? -- DE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: libthr and daemon()
On Mon, 5 Oct 2009, Matthew Fleming wrote: I have some code that tries to use pthread_cond_wait() and it's getting back EPERM. Upon further investigation, here's what I've found: When the app starts, libthr's _libpthread_init calls init_main_thread() to set the thread id in struct pthread's tid. Is the application threaded before calling daemon()? The app opens a log file then calls daemon(). daemon() calls fork() fork() does not appear to be linked to _fork() in libthr; see below. The app creates a thread to handle signals. The app attempts to wait on a condition variable (pthread_cond_wait(); this gives EPERM). Was the condition variable created before daemon() was called? The picture is not clear to me. POSIX states that only async-signal-safe function calls can be made from a child fork()'d from a threaded application. The intent is that the child should soon after call a function in the exec() family. Certainly, any more threaded calls in the child are invalid. -- DE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: problem with link aggregation failover
On Sun, 27 Sep 2009, Ulrich Sp??rlein wrote: On Sat, 12.09.2009 at 22:34:41 +0200, Maciej Jan Broniarz wrote: Hello, I am trying to configure lagg failover mode on 7.2. I do: # ifconfig xl0 up # ifconfig fxp0 up # ifconfig lagg0 create # ifconfig lagg0 up laggproto failover laggport xl0 laggport fxp0 # dhclient lagg0 And all seems to work ok. Still I disconnect the cable from the master card the connection stops. Although fxp0 becomes active the connection is still dead. If I start pinging any host from that machine the conection comes back to live, but having ping in background all the time is not the solution. Am I doing something wrong or have I missed something in the configuration? Well, where is xl0 and fxp0 connected to? My first bet would be a standard switch, if so try setting both devices to the same MAC address. Otherwise the peers you connect to will send the IP packets to the wrong MAC address and only after a timeout (or a forced push thanks to the ping) will get their ARP cache into shape. lagg should automatically make xl0 and fxp0 appear at the same MAC address. The only time you should have to manually set the MAC address would be on cloned interfaces such as wlan, because the cloned interfaces don't propagate the MAC change down to the interface from which they were cloned. -- DE___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Let's back out LOADER_ZFS_SUPPORT from STABLE
On Sat, 13 Jun 2009, Dan Allen wrote: How do I get to the old loader when the machine boots and immediately stops? There is no ability at this point in the boot process to try and get to the old loader that I know of. Is there a hidden magic key combination that allows this? You are correct that the bulk of the file system is not touched, but the key file partitioning headers get cleared and when you boot off of a DVD -- the only way to get to the system that I know of -- and inspect the file partitioning via whatever means you try, it shows that the root partition is gone. What was your main file system is gone. I learned after many installs that I could NOT do a newfs(8) and the setup program would re-mark things and and files ended up re-appearing. My machine was well backed up so no great loss of data in the end, but it has cost me lots of time to get this figured out. For me the real questions are these: * Why is my system the only one that this happens on? * What makes my machine setup different? * What is the bug in the bootable ZFS loader that munges the partition map? From one of your older emails, you mention you are using ad0s2a as / and ad0s2b as swap, and then say that ad0s2c is unused (I may have the ad0s2 part wrong). But ad0s2c should be the entire slice (or partition depending on the wording you are used to). How about posting a relevent fdisk and disklabel (or gpart show) so we can see what your slices and partitions look like (fdisk /dev/ad0, disklabel /dev/ad0s2). -- DE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Let's back out LOADER_ZFS_SUPPORT from STABLE
On Sun, 14 Jun 2009, Dan Allen wrote: On 14 Jun 2009, at 1:27 AM, Daniel Eischen wrote: From one of your older emails, you mention you are using ad0s2a as / and ad0s2b as swap, and then say that ad0s2c is unused (I may have the ad0s2 part wrong). But ad0s2c should be the entire slice (or partition depending on the wording you are used to). How about posting a relevent fdisk and disklabel (or gpart show) so we can see what your slices and partitions look like (fdisk /dev/ad0, disklabel /dev/ad0s2). ad0s2c is the entire slice as you thought it should be. Here is fdisk and bsdlabel /dev/ad0s2: *** Working on device /dev/ad0 *** parameters extracted from in-core disklabel are: cylinders=232581 heads=16 sectors/track=63 (1008 blks/cyl) Figures below won't work with BIOS for partitions not in cyl 1 parameters to be used for BIOS calculations are: cylinders=232581 heads=16 sectors/track=63 (1008 blks/cyl) Media sector size is 512 Warning: BIOS sector numbering starts with sector 1 Information from DOS bootblock is: The data for partition 1 is: sysid 7 (0x07),(OS/2 HPFS, NTFS, QNX-2 (16 bit) or Advanced UNIX) start 63, size 188747622 (92161 Meg), flag 0 beg: cyl 0/ head 1/ sector 1; end: cyl 1023/ head 10/ sector 63 The data for partition 2 is: sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) start 188747685, size 45688860 (22309 Meg), flag 80 (active) beg: cyl 1023/ head 255/ sector 63; end: cyl 1023/ head 14/ sector 63 The data for partition 3 is: UNUSED The data for partition 4 is: UNUSED # /dev/ad0s2: 8 partitions: #size offsetfstype [fsize bsize bps/cpg] a: 43591708 20971524.2BSD0 0 0 b: 20971520 swap c: 456888600unused0 0 # raw part, don't edit Seems weird to see swap at offset 0 and partition a after swap. I wonder if that is screwing things up. And shouldn't the offset for your first slice start at offset 188747685 (from fdisk)? This is from my system: $ fdisk /dev/ad0 *** Working on device /dev/ad0 *** parameters extracted from in-core disklabel are: cylinders=155061 heads=16 sectors/track=63 (1008 blks/cyl) Figures below won't work with BIOS for partitions not in cyl 1 parameters to be used for BIOS calculations are: cylinders=155061 heads=16 sectors/track=63 (1008 blks/cyl) Media sector size is 512 Warning: BIOS sector numbering starts with sector 1 Information from DOS bootblock is: The data for partition 1 is: sysid 6 (0x06),(Primary DOS, 16 bit FAT (= 32MB)) start 63, size 20964762 (10236 Meg), flag 0 beg: cyl 0/ head 1/ sector 1; end: cyl 1023/ head 254/ sector 63 The data for partition 2 is: sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) start 20964825, size 135331560 (66079 Meg), flag 80 (active) beg: cyl 1023/ head 255/ sector 63; end: cyl 1023/ head 254/ sector 63 The data for partition 3 is: UNUSED The data for partition 4 is: UNUSED $ disklabel /dev/ad0s2 # /dev/ad0s2: 8 partitions: #size offsetfstype [fsize bsize bps/cpg] a: 2097152 209648254.2BSD 2048 16384 28552 b: 4194304 23061977 swap c: 135331560 20964825unused0 0 d: 4194304 272562814.2BSD 2048 16384 28552 e: 4194304 314505854.2BSD 2048 16384 28552 f: 16777216 356448894.2BSD 2048 16384 28552 g: 103874280 524221054.2BSD 2048 16384 28536 -- DE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Unnamed POSIX shared semaphores
On Mon, 1 Jun 2009, Bruce Simpson wrote: Jilles Tjoelker wrote: If process-shared semaphores really work, then the above structure is not a pathological case. Effectively, sem_t is carved in stone. So process-private semaphores should continue to have most of their stuff in a separately allocated structure, to preserve flexibility. There was an inadvertent race in FreeBSD's POSIX semaphores which I fixed in HEAD and STABLE about 6 weeks before 7.2 was released. I believe process-shared POSIX semaphores now work -- the Python 'multiprocessing' regression test now runs to completion with no errors on both HEAD and STABLE. Process-shared semaphores, mutexes, etc, will never work until their public types are structs, not pointers to structs (i.e. allocated by our library functions). The intrinsic *kernel* semaphore functions (ksem) supposedly do support process-shared semantics, but our POSIX functions' use of them cannot be shared across processes. -- DE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: dlopen-ing a library with OpenMP by a non-OpenMP process
On Wed, 12 Nov 2008, Mikhail Teterin wrote: Sent by Kostik Belousov: On Wed, Nov 12, 2008 at 01:09:22PM -0500, Mikhail Teterin wrote: Hello! Currently, when a program built without OpenMP (-fopenmp) is trying to dlopen a library, built with the feature, the result is a crash from bad system call: #0 0x0008009a223c in ksem_init () from /lib/libc.so.7 #1 0x000800998a8f in sem_init () from /lib/libc.so.7 #2 0x0008011a6537 in omp_get_nested () from /usr/lib/libgomp.so.1 #3 0x0008011a3466 in ?? () from /usr/lib/libgomp.so.1 #4 0x0002 in ?? () #5 0x0008005072b2 in dlsym () from /libexec/ld-elf.so.1 #6 0x000800507cd2 in dlopen () from /libexec/ld-elf.so.1 ... Try kldload sem. Uhm... That worked... I see... Shouldn't sem_init be nicer about it, though? Thanks, Or perhaps you should read sem(4) ;-) -- DE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dlopen-ing a library with OpenMP by a non-OpenMP process
On Wed, 12 Nov 2008, Mikhail Teterin wrote: Sent by Daniel Eischen: On Wed, 12 Nov 2008, Mikhail Teterin wrote: Sent by Kostik Belousov: On Wed, Nov 12, 2008 at 01:09:22PM -0500, Mikhail Teterin wrote: Hello! Currently, when a program built without OpenMP (-fopenmp) is trying to dlopen a library, built with the feature, the result is a crash from bad system call: #0 0x0008009a223c in ksem_init () from /lib/libc.so.7 #1 0x000800998a8f in sem_init () from /lib/libc.so.7 Uhm... That worked... I see... Shouldn't sem_init be nicer about it, though? Thanks, Or perhaps you should read sem(4) ;-) Daniel, what are saying? That it is all my own fault? Generic kernel does not have sem in it... I build a port with an option (OpenMP), that make perfect sense, and try to use it. Software crashes... There is a bug -- and you, instead of contemplating a fix, are telling me to read a man-page? Wow... No, I simply meant that you saw it was returning bad system call from sem_init/ksem_init. A little investigation would have turned up the reason. If you want to debate whether or not P1003_1B_SEMAPHORES should be standard, that is another issue, which I might actually agree with. -- DE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Calling malloc from a signal handler
On Fri, 19 Sep 2008, Stephen Montgomery-Smith wrote: I notice that if you use malloc from within a signal handler on FreeBSD-6.x, that you can potentially trigger a recursive call error. But this seems to have changed in FreeBSD-7.x. Is it now permissible to call malloc from within a signal handler in FreeBSD-7.x? If so, should the man page of sigaction(2) be upgraded to say this? You shouldn't call malloc() or any other function that isn't async-signal-safe from a signal handler. I don't think we should say if it works or not, since it is not portable and could change at any given time in future versions of FreeBSD. -- DE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: WARNING: 7-STABLE BROKEN -- please wait to upgrade / Should be OK now
On Fri, 29 Aug 2008, Dan Allen wrote: Well I got bit by this and am dead in the water. Nothing builds. I tried the DEBUG_FLAGS=-g trick but to no avail. I get this: cc: Internal error: segmentation fault: 11 (program ld) I do not have a backup ld. (My bad.) Where can I get a good one? I cannot find any servers with built individual tools. Judging from others regarding this problem, you may need a few utilities. Can you download a 7.0-RELEASE live CD image, burn it, then use the utilities from that? -- DE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: undefined reference to SYS_cpuset
On Mon, 28 Jul 2008, Unga wrote:
Hi all
Today (28th July) I upgraded the FreeBSD sources (/usr/src) using
cvsup and when try to compile a test C program I get following:
echo 'main(){}' dummy.c
cc dummy.c -v -Wl,--verbose
/usr/lib/libc.so: undefined reference to `SYS_cpuset_getaffinity'
/usr/lib/libc.so: undefined reference to `SYS_cpuset'
/usr/lib/libc.so: undefined reference to `SYS_cpuset_setaffinity'
/usr/lib/libc.so: undefined reference to `SYS_cpuset_getid'
/usr/lib/libc.so: undefined reference to `SYS_cpuset_setid'
/usr/lib/libc.so: undefined reference to `SYS_setfib'
collect2: ld returned 1 exit status
I can see in logs following programs compiled without any error:
cpuset_getaffinity.S
cpuset.S
cpuset_setaffinity.S
cpuset_getid.S
cpuset_setid.S
setfib.S
What's gone wrong now? Am I in the middle of a FreeBSD update? or have
I made some mistake? or multiple routing tables update on 20080724
broken something? Any ideas?
Did you build and install the kernel first?
--
DE
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: undefined reference to SYS_cpuset
On Mon, 28 Jul 2008, Unga wrote:
--- On Mon, 7/28/08, Daniel Eischen [EMAIL PROTECTED] wrote:
From: Daniel Eischen [EMAIL PROTECTED]
Subject: Re: undefined reference to SYS_cpuset
To: Unga [EMAIL PROTECTED]
Cc: freebsd-stable@freebsd.org
Date: Monday, July 28, 2008, 9:19 PM
On Mon, 28 Jul 2008, Unga wrote:
Hi all
Today (28th July) I upgraded the FreeBSD sources
(/usr/src) using
cvsup and when try to compile a test C program I get
following:
echo 'main(){}' dummy.c
cc dummy.c -v -Wl,--verbose
/usr/lib/libc.so: undefined reference to
`SYS_cpuset_getaffinity'
/usr/lib/libc.so: undefined reference to
`SYS_cpuset'
/usr/lib/libc.so: undefined reference to
`SYS_cpuset_setaffinity'
/usr/lib/libc.so: undefined reference to
`SYS_cpuset_getid'
/usr/lib/libc.so: undefined reference to
`SYS_cpuset_setid'
/usr/lib/libc.so: undefined reference to
`SYS_setfib'
collect2: ld returned 1 exit status
I can see in logs following programs compiled without
any error:
cpuset_getaffinity.S
cpuset.S
cpuset_setaffinity.S
cpuset_getid.S
cpuset_setid.S
setfib.S
What's gone wrong now? Am I in the middle of a
FreeBSD update? or have
I made some mistake? or multiple routing tables update
on 20080724
broken something? Any ideas?
Did you build and install the kernel first?
I have compiled and installed **only** following to a separate location:
- FreeBSD Headers
- lib/csu
- lib/libc
- lib/msun
- lib/libc_r
And tested with a simple script whether I can compile and link against new libs
successfully before I can proceed with my project. That test, as mentioned in
the original post, failed to link against the new C libraries. That is, it
looks to me, the libc is now broken.
Of course, the system I'm running is old, uname -a shows May 25. I don't think
I have to run the latest kernel for me to separately link against a different
copy of libc, do I?
If there a fix or a patch, I can apply against the libc and let you guys know
the result.
The only supported way is to buildkernel and buildworld. You're on your
own if you choose not to go along with the procedure in src/UPDATING.
--
DE
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: undefined reference to SYS_cpuset
On Mon, 28 Jul 2008, Unga wrote:
--- On Mon, 7/28/08, Daniel Eischen [EMAIL PROTECTED] wrote:
From: Daniel Eischen [EMAIL PROTECTED]
Subject: Re: undefined reference to SYS_cpuset
To: Unga [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED], [EMAIL PROTECTED], freebsd-stable@freebsd.org, [EMAIL
PROTECTED]
Date: Monday, July 28, 2008, 10:26 PM
On Mon, 28 Jul 2008, Unga wrote:
--- On Mon, 7/28/08, Daniel Eischen
[EMAIL PROTECTED] wrote:
From: Daniel Eischen [EMAIL PROTECTED]
Subject: Re: undefined reference to SYS_cpuset
To: Unga [EMAIL PROTECTED]
Cc: freebsd-stable@freebsd.org
Date: Monday, July 28, 2008, 9:19 PM
On Mon, 28 Jul 2008, Unga wrote:
Hi all
Today (28th July) I upgraded the FreeBSD
sources
(/usr/src) using
cvsup and when try to compile a test C program
I get
following:
echo 'main(){}' dummy.c
cc dummy.c -v -Wl,--verbose
/usr/lib/libc.so: undefined reference to
`SYS_cpuset_getaffinity'
/usr/lib/libc.so: undefined reference to
`SYS_cpuset'
/usr/lib/libc.so: undefined reference to
`SYS_cpuset_setaffinity'
/usr/lib/libc.so: undefined reference to
`SYS_cpuset_getid'
/usr/lib/libc.so: undefined reference to
`SYS_cpuset_setid'
/usr/lib/libc.so: undefined reference to
`SYS_setfib'
collect2: ld returned 1 exit status
I can see in logs following programs compiled
without
any error:
cpuset_getaffinity.S
cpuset.S
cpuset_setaffinity.S
cpuset_getid.S
cpuset_setid.S
setfib.S
What's gone wrong now? Am I in the middle
of a
FreeBSD update? or have
I made some mistake? or multiple routing
tables update
on 20080724
broken something? Any ideas?
Did you build and install the kernel first?
I have compiled and installed **only** following to a
separate location:
- FreeBSD Headers
- lib/csu
- lib/libc
- lib/msun
- lib/libc_r
And tested with a simple script whether I can compile
and link against new libs successfully before I can proceed
with my project. That test, as mentioned in the original
post, failed to link against the new C libraries. That is,
it looks to me, the libc is now broken.
Of course, the system I'm running is old, uname -a
shows May 25. I don't think I have to run the latest
kernel for me to separately link against a different copy
of libc, do I?
If there a fix or a patch, I can apply against the
libc and let you guys know the result.
The only supported way is to buildkernel and buildworld.
You're on your
own if you choose not to go along with the procedure in
src/UPDATING.
That may the only way you know how build FreeBSD :(
No, it's not the only way *I* know how to, but if you aren't
going to follow UPDATING, then *you* are expected to figure
it out :-)
Your problem is that you don't have an up-to-date kernel src
(src/sys) directory with includes in your build environment.
Your libc is being built against an old set of includes, so
it is up to you how to want to modify your build environment
to account for this.
--
DE
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: undefined reference to SYS_cpuset
On Mon, 28 Jul 2008, Unga wrote: --- On Mon, 7/28/08, Daniel Eischen [EMAIL PROTECTED] wrote: Your problem is that you don't have an up-to-date kernel src (src/sys) directory with includes in your build environment. I have nothing to do with src/sys. I link against FreeBSD libs for a long time, it just today onwards did not work. That's all. I don't care that *you* have nothing to do with src/sys, but libc (and other base libs and utilities) do care. Your libc is being built against an old set of includes, so it is up to you how to want to modify your build environment to account for this. I install FreeBSD includes from /usr/src/include and libs from /usr/src/lib. From the today onwards if the make in /usr/src/include does not install all the headers required for libs building that should be clearly documented and notified prominently, that I don't see it in UPDATING or any where. FYI, my libc is build against the **latest** set of includes installed by the make in the /usr/src/include and nothing but that, ie, there are no other headers in /mypath/include, the compilation and installation of libc goes **without** any error. So that Your libc is being built against an old set of includes is just pure nonsense, and stupid statement made without knowing what people are doing. It's not nonsense, it is the truth. old set of includes includes /usr/include and everything under it (/usr/include/sys, /usr/include/machine, etc), with sys and machine notably being part of src/sys. The files in /usr/src/include are not the complete set of includes, and a 'make install' from there does not install all the includes. Depending on what you are doing and what you require, you need to at least setup an include directory that includes the files from /usr/src/include, /usr/src/sys/sys (as sys/*.h and /usr/src/sys/arch/include (as machine/*.h). You should do a 'ls -1F /usr/include | grep /' and see just what you are missing by only relying on /usr/src/include. -- DE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: thread scheduling at mutex unlock
On Thu, 15 May 2008, Andriy Gapon wrote:
Or even more realistic: there should be a feeder thread that puts things on
the queue, it would never be able to enqueue new items until the queue
becomes empty if worker thread's code looks like the following:
while(1)
{
pthread_mutex_lock(work_mutex);
while(queue.is_empty())
pthread_cond_wait(...);
//dequeue item
...
pthread_mutex_unlock(work mutex);
//perform some short and non-blocking processing of the item
...
}
Because the worker thread (while the queue is not empty) would never enter
cond_wait and would always re-lock the mutex shortly after unlocking it.
Well in theory, the kernel scheduler will let both threads run fairly
with regards to their cpu usage, so this should even out the enqueueing
and dequeueing threads.
You could also optimize the above a little bit by dequeueing everything
in the queue instead of one at a time.
So while improving performance on small scale this mutex re-acquire-ing
unfairness may be hurting interactivity and thread concurrency and thus
performance in general. E.g. in the above example queue would always be
effectively of depth 1.
Something about lock starvation comes to mind.
So, yes, this is not about standards, this is about reasonable expectations
about thread concurrency behavior in a particular implementation (libthr).
I see now that performance advantage of libthr over libkse came with a price.
I think that something like queued locks is needed. They would clearly reduce
raw throughput performance, so maybe that should be a new (non-portable?)
mutex attribute.
--
DE
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: thread scheduling at mutex unlock
On Thu, 15 May 2008, Daniel Eischen wrote:
On Thu, 15 May 2008, Andriy Gapon wrote:
Or even more realistic: there should be a feeder thread that puts things on
the queue, it would never be able to enqueue new items until the queue
becomes empty if worker thread's code looks like the following:
while(1)
{
pthread_mutex_lock(work_mutex);
while(queue.is_empty())
pthread_cond_wait(...);
//dequeue item
...
pthread_mutex_unlock(work mutex);
//perform some short and non-blocking processing of the item
...
}
Because the worker thread (while the queue is not empty) would never enter
cond_wait and would always re-lock the mutex shortly after unlocking it.
Well in theory, the kernel scheduler will let both threads run fairly
with regards to their cpu usage, so this should even out the enqueueing
and dequeueing threads.
You could also optimize the above a little bit by dequeueing everything
in the queue instead of one at a time.
I suppose you could also enforce your own scheduling with
something like the following:
pthread_cond_t writer_cv;
pthread_cond_t reader_cv;
pthread_mutex_t q_mutex;
...
thingy_q_t thingy_q;
int writers_waiting = 0;
int readers_waiting = 0;
...
void
enqueue(thingy_t *thingy)
{
pthread_mutex_lock(q_mutex);
/* Insert into thingy q */
...
if (readers_waiting 0) {
pthread_cond_broadcast(reader_cv, q_mutex);
readers_waiting = 0;
}
while (thingy_q.size ENQUEUE_THRESHOLD_HIGH) {
writers_waiting++;
pthread_cond_wait(writer_cv, q_mutex);
}
pthread_mutex_unlock(q_mutex);
}
thingy_t *
dequeue(void)
{
thingy_t *thingy;
pthread_mutex_lock(q_mutex);
while (thingy_q.size == 0) {
readers_waiting++;
pthread_cond_wait(reader_cv, q_mutex);
}
/* Dequeue thingy */
...
if ((writers_waiting 0)
thingy_q.size ENQUEUE_THRESHOLD_LOW)) {
/* Wakeup the writers. */
pthread_cond_broadcast(writer_cv, q_mutex);
writers_waiting = 0;
}
pthread_mutex_unlock(q_mutex);
return (thingy);
}
The above is completely untested and probably contains some
bugs ;-)
You probably shouldn't need anything like that if the kernel
scheduler is scheduling your threads fairly.
--
DE
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /usr/bin/objformat is missing
On Mon, 28 Jan 2008, Chris H. wrote: Quoting Jeremy Chadwick [EMAIL PROTECTED]: On Mon, Jan 28, 2008 at 09:33:49AM -0800, Chris H. wrote: Hello, After a failed install of www/apache-ssl - dies with the following error: Syntax error on line 208 of /usr/local/etc/apache/httpsd.conf: Cannot load /usr/local/libexec/apache/mod_mmap_static.so into server: /usr/local /libexec/apache/mod_mmap_static.so: Undefined symbol ap_null_cleanup I did a little research, and wondered if the fact that I am missing: /usr/bin/objformat has anything to do with it. Very unlikely. Are you using the binary package of www/apache-ssl, rather than building the port from source? Building from source that was cvsupped 2008-01-18 Have you at any time migrated from Apache 1.3.x Nope. It's a brand new install. Why don't you use a newer version of Apache, as opposed to 1.3.x? From your error messages, it seems obvious, though you never state it, that you are using apache13. -- DE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SOLVED: qemu: freebsd6_mmap -1 errno 12 Cannot allocate memory
On Sat, 8 Dec 2007, Eugene Grosbein wrote: On Sat, Dec 08, 2007 at 01:09:47PM +0700, Eugene Grosbein wrote: Thank you. Now I wonder, how such thing may happen if qemu was built under 6.2 where there were no libthr.so.3 and libc.so.7? Most likely, you have rebuilt some library that brough in the dependencies. Check with readelf -d (look for NEEDED tags). $ readelf -d `which qemu` | grep NEEDED 0x0001 (NEEDED) Shared library: [libm.so.4] 0x0001 (NEEDED) Shared library: [libz.so.3] 0x0001 (NEEDED) Shared library: [libSDL.so.11] 0x0001 (NEEDED) Shared library: [libutil.so.5] 0x0001 (NEEDED) Shared library: [libpthread.so.2] 0x0001 (NEEDED) Shared library: [libc.so.6] Well, libSDL.so.11 is a culprit here. I'll try to get older version to /usr/local/lib/compat and use libmap.conf to resolve this. The problem is solved with libSDL.so.11 extracted from backup to /usr/local/lib/compat and a section in /etc/libmap.conf: [qemu] libSDL.so.11compat/libSDL.so.11 So qemu just works again. Thank you very much! Please reread my original reply to you. If you are going to be rebuilding or installing new ports, then you really need to do a portupgrade -af. The same thing may happen again for some other library. -- DE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SOLVED: qemu: freebsd6_mmap -1 errno 12 Cannot allocate memory
[ Library incompatiblity problems between major FreeBSD releases ] One of the things that should make life a little easier in FreeBSD 7.0 and subsequent (-current, 8.x, etc) is that we now have symbol versioning in some of our libraries. The libraries that have caused the most problems in the past, libc, libpthread (kse, thr), and libm all have symbol versioning enabled in 7.0. This means that there will be only one version of these libraries (e.g., libc.so.7) for all releases from 7.0 onward (*). So even if there are ABI changes in libc for instance, the compatible ABIs are also left in libc and both new programs linked against the new ABIs and old programs linked against the old ABIs can coexist peacefully. programs also means libraries, like libSDL as was the culprit in this case. (*) There is some talk about restarting our library numbering at 0 (e.g. libc.so.0, libthr.so.0, etc) so it is less confusing about which set of libraries have symbol versioning. This may be done for 8.0, and this would probably force yet another portupgrade -af for 8.x, but could easily be worked around with a few global libmap.conf settings. Anyway, we all feel the pain of maintaining ports, and are trying to make life easier. -- DE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: qemu: freebsd6_mmap -1 errno 12 Cannot allocate memory
On Fri, 7 Dec 2007, Boris Samorodov wrote: On Fri, 7 Dec 2007 22:48:52 +0700 Eugene Grosbein wrote: There is FreeBSD box that was 6.2-STABLE before, now it became 7.0-BETA3 via source upgrade. The kernel has 'options COMPAT_FREEBSD6' How did you upgrade the OS? Did you use make delete-old-libs? Did you install compat-6x? compiled in. However, qemu-0.8.2s.20061225_1 stopped to work, Seems to be a rather old qemu version... it dumps core when started with an error: Fatal error 'Cannot allocate red zone for initial thread' at line 384 in file /usr/local/obj/src/lib/libthr/thread/thr_init.c (errno = 12) You have to either rebuild/install _no_ ports, or rebuild _all_ ports (portupgrade -af). You now seem to have applications or libraries that are linked to multiple FreeBSD library versions (e.g., libc.so.6 and libc.so.7, libthr.so.2 and libthr.so.3, etc) and that doesn't work and is not supported. -- DE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Pthread scheduling in FreeBSD 7
On Tue, 27 Nov 2007, Gregor Maier wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, I have a question concerning *pthread* scheduling with FreeBSD 7. Did this get answered already? I missed it if it did. My goal: I have a multi-threaded application, in which I have a thread that should get higher priority than the other threads. Realtime-Priority for this thread would be nice but is not necessary. My approach so far (which worked for FreeBSD 6.2): Use the libpthread implementation, use pthread_attr_setschedparam() to increase the priority (scope is PTHREAD_SCOPE_SYSTEM, policy is SCHED_RR). For the libpthread implemenation that worked fine and did just what I expected. I also tried it using libthr, but libthr didn't care about the priority. My prolbem in FreeBSD 7: The libpthread implementation seems to have gone and libthr is the default. However libthr still ignores the pthread scheduling parameters. (FreeBSD 7 has a different default priority and policy for libthr than FreeBSD 6 however). I also saw, that libkse is now available as a new M:N pthread implementation, so I tried using that. But libkse is significantly slower than libthr and libkse does not always schedule to all CPUs. As far as I can tell libkse only schedules to all CPUs if the load is small when the threads are created. I have never seen this behaviour with libpthread from FreeBSD 6. And libkse is quite unpredictable: I used a test program with 10 threads (with equal priority) and recorded the wall-runtime of each of them. The runtime of them differs by a factor of up to 5(!). I have to mention however, that I used different machines. The one running FreeBSD 6 is a dual-cpu AMD Athlon with 32bit OS, while the one running FreeBSD 7 is a dual-core Intel running a 64bit OS. In FreeBSD 6 I used SCHED_4BSD in the kernel, while I used SCHED_ULE in FreeBSD 7. My questions: * Can anyone shed some light on this issue? * How can I tune thread scheduling in FreeBSD 7? What happened to the libpthread implementation from FreeBSD 6? It is the same as libkse, just renamed. Other than setting the sysctl kern.threads.virtual_cpu (which defaults to the number of CPUs), there isn't much else. And if all threads are system scope, virtual_cpu 1 isn't of any use. * What triggers the whether libkse schedules to only one or to all CPUs? Is this tuneable? In both cases (system and process-scope threads) it is dependent on the kernel. For process scope threads, there is only one userland run-queue and threads are scheduled onto KSEs as they become available. When threads block in the kernel, an upcall is made and libkse runs another thread in that KSE. When threads unblock, the kernel puts them in the next KSE upcall - they are not bound to any specific upcall. What should be done is that threads should get bound to a specific upcall and they should stay there (N run queues to match N KSEs) and threads should only migrate to average the KSE loading. For system scope threads it is totally dependent on the kernel scheduler. * Do rtprio() and/or nice() work for single threads? I'm not sure about nice(), but rtprio only works if you have superuser privileges. * Any other ideas how I can assign a higher priority to a thread. Maybe even realtime priority? For libthr, priorities are only really used if the process has superuser privileges. Try running (if it is safe) it as root. You should set the scheduling class to SCHED_FIFO or SCHED_RR (see sched_setscheduler(2)). -- DE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: connect() returns EADDRINUSE during massive host-host conn rate
On Wed, 28 Nov 2007, Ivan Voras wrote: Jan Srzednicki wrote: Hello, I have a pair of hosts. One of them performs a massive amount of TCP connections to the other one, all to the same port. This setup mostly works fine, but from time to time (that varies, from once a minute to one a half an hour), the connect(2) syscall fails with EADDRINUSE. The connection rate tops to 50 connection initiations/second. This looks like the old (and probably well known) problem ab has. (ab is apache benchmark, a utility which is bundled with apache and which does repeated connections to the specified address, does transactions and computes some statistics). AFAIK this behaviour was present since at least 5.2, maybe earlier. No known fixes. Could it have anything to do with the listen backlog on the server end? -- DE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 74 hours till next No Buffer Space Available reboot ...
On Sat, 14 Apr 2007, Marc G. Fournier wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - --On Sunday, April 08, 2007 23:04:42 -0400 Dave [EMAIL PROTECTED] wrote: Hello, This is what i get for catching this late. Can you describe your situation? I've got a server, router actually running 6.1-p6 i believe, and lately it's been doing this stop. I can't be any more specific than that, because that's all i know. The box just goes unresponsive, i can get a login prompt on the console, but it's unresponsive. I have to reboot it. This has occurred twice now and i'm starting to get concerned. I've ruled out ram, i recently replaced it's ram for an unrelated reason so i don't think that's it. If your situation is similar can you let me know what you tried? This is a different situation, I think ... first, I'm running 6.2-STABLE, as of about last week, so a much newer kernel then you are running ... and in my case, at least, I can still login to the machine using ssh and force a reboot remotely ... it doesn't seem to be a 'solid hang' ... if I were to hazard a guess as to what it feels like ... it feels like the network interface buffer has filled up, but isn't being released properly ... almost like a memory leak, but on the network ... if I leave it long enough, it will eventually require a tech to power cycle it, but if I catch it early enough, I can still get in to do a reboot ... But ... that said ... when you say 'get a login prompt on the console, but it's unresponse ... do you mean that you can actually type in a userid, and possibly passwd, but after that it just hangs? I will just add that I get this on an old 4-stable router box (for years). It is on an sf interface and I _thought_ it was due to a flaky hub. I got the sendto: no buffer space avail message on the incoming/outgoing interface to the router that was doing NAT and ipfw to our internal LANs. I resorted to writing a cron job that would try to ping the router at the other end of the sf interface and do an 'ifconfig sf0 down; ifconfig sf0 up' whenever the router at the other end could not be ping'd. Something like this: if ping -c 2 remote-router /dev/null; then /usr/bin/true else /sbin/ifconfig sf0 down /bin/sleep 1 /sbin/ifconfig sf0 up fi This router is running 4.11. Without the cronjob, the network would fail every week or two. I gave up trying to figure out what the real problem was. -- DE ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Pthreads signals
On Wed, 28 Mar 2007, Steve Watt wrote: In [EMAIL PROTECTED], Daniel Eischen [EMAIL PROTECTED] wrote: On Wed, 28 Mar 2007, Peter Holmes wrote: How do signals work with pthreads in FreeBSD. How are process signals delivered? The best explanation of signals and threads in general is in the POSIX spec, or Butenhof's book. http://www.opengroup.org/onlinepubs/009695399/functions/xsh_chap02_04.html I suspect the question was rather more specific than that, due to bad experiences with LinuxThreads. Does FreeBSD have a proper signal delivery model, where thread masks are per-signal, and signals sent to the process when all threads within the process have the signal blocked remain pending against the process so any thread may accept the signal using sigwait()/sigtimedwait()/sigwaintinfo(). These are POSIX threads, so if things don't behave as specified by or as allowed by the standard, a bug report should be filed. -- DE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Clamav-90_2 Lockup with freebsd 6.2
On Sun, 4 Mar 2007, Martin Blapp wrote: Hi all, After adding some debug stuff to clamd running with freebsd libpthread.so I found that: looking at the output value of 'ps -auxH | grep clamd | grep -v grep | wc -l' is always staying at 6 threads, but the number of threadpool-thr_alive is going higher and higher. So threadpool-thr_alive isn't decreased and is completly incorrect. In my tests the number of threads with libpthread.so is never going higher than 6 threads. That explains, why a higher load is going to delay all scan operations more and more. With libthr.so the value of threadpool-thr_alive is equal with the output of the ps. It can go very high, but always goes back if no more work is there to do. After the maxthreads limit is reached, clamd becomes completly unresponsive with libpthreads.so. SIGKILL and SIGSTOP don't work because some (unexisting) worker threads block on pthread_cond_timedwait(). Only kill -9 helps. Of course, the counter threadpool-thr_alive is wrong and may cause this problem. Maybe someone with more threads knowledge can help here. I'll now add some debug stuff to see where threadpool-thr_alive is going to be increased and where it is decreased. The strange thing is that this works fine with libthr.so. Make sure clamd is checking the return value of pthread_create() for errors. You can also set LIBPTHREAD_PROCESS_SCOPE=yes or LIBPTHREAD_SYSTEM_SCOPE=yes in your environment to force process scope or system scope threads (libpthread only) for clamd. -- DE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Clamav-90_2 Lockup with freebsd 6.2
On Thu, 1 Mar 2007, Martin Blapp wrote: Hi, Clamd is currently broken with libpthread for some threading-reason. You definitly need to use libthr (which is still CPU hungry, but works better). I don't think it is a problem with libpthread. -- DE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Clamav-90_2 Lockup with freebsd 6.2
On Thu, 1 Mar 2007, Alexander Shikoff wrote: Hi All, On Thu, Mar 01, 2007 at 08:32:55AM -0500, Daniel Eischen wrote: On Thu, 1 Mar 2007, Martin Blapp wrote: Hi, Clamd is currently broken with libpthread for some threading-reason. You definitly need to use libthr (which is still CPU hungry, but works better). I don't think it is a problem with libpthread. FYI: https://wwws.clamav.net/bugzilla/show_bug.cgi?id=307#c8 I have no idea what this bug report says. This link and any other link I can find to clamav bug reports is not working or down. -- DE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Apache13/MoinMoin/Python vs PATH? What changed?
On Thu, 1 Mar 2007, Andrew Reilly wrote: Hi Daniel, On Wed, Feb 28, 2007 at 08:41:00AM -0500, Daniel Eischen wrote: On Wed, 28 Feb 2007, Andrew Reilly wrote: Funny thing happened after the last upgrade (upgraded to 6-STABLE yesterday): the moinmoin wiki that I've been playing with stopped working. A little fiddling found that I could make it work again by changing the shebang at the top of /usr/local/www/wiki/moin.cgi (ScriptAlias points there, in httpd.conf) from #!/usr/bin/env python to #!/usr/local/bin/python See this thread: http://groups.google.com/group/mailing.freebsd.cvs/browse_thread/thread/a0344851d94df36f/e94a3c524ff22732?lnk=stq=rnum=3#e94a3c524ff22732 If that link doesn't work, search groups.google.com, /usr/bin/env python group:*freebsd* and see the cvs commit: src/etc rc.subr thread. Thanks for the link: it worked fine for me. I'm a little surprised that I appear to be the first one bringing up a problem with this change, given that it happened three months ago. Since there was no warning in UPDATING, were all of the python ports patched at about the same time? (I haven't done a portupgrade all that recently: just FreeBSD itself.) What is the approved fix for this problem? Setting a PATH that includes /usr/local/bin in /usr/local/etc/rc.d/apache.sh? Or the shebang patch to the python script itself, that I have already made? Has anyone answered this yet? I do not know myself. -- DE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Apache13/MoinMoin/Python vs PATH? What changed?
On Wed, 28 Feb 2007, Andrew Reilly wrote: Hi all, Funny thing happened after the last upgrade (upgraded to 6-STABLE yesterday): the moinmoin wiki that I've been playing with stopped working. A little fiddling found that I could make it work again by changing the shebang at the top of /usr/local/www/wiki/moin.cgi (ScriptAlias points there, in httpd.conf) from #!/usr/bin/env python to #!/usr/local/bin/python Now, it appears that * python is in /usr/local/bin, as expected * /usr/local/bin is still in the default path in /etc/login.conf * none of the Apache or MoinMoin config files have been touched since November last year, when I set it up. It seems that apache-1.3 went through an upgrade on Jan 17 (here), probably the last time that I ran portupgrade. Has it changed, to filter /usr/local/bin out of the PATH that cgi scripts see? I'm not very adept at Apache configuration, but I don't see anything in the httpd.conf file that talks about PATH. Any thoughts? See this thread: http://groups.google.com/group/mailing.freebsd.cvs/browse_thread/thread/a0344851d94df36f/e94a3c524ff22732?lnk=stq=rnum=3#e94a3c524ff22732 If that link doesn't work, search groups.google.com, /usr/bin/env python group:*freebsd* and see the cvs commit: src/etc rc.subr thread. -- DE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Clamav-90_2 Lockup with freebsd 6.2
On Wed, 28 Feb 2007, Dimuthu Parussalla wrote: Hi, I can confirm the same situation. My dual xeon x236 server runs very high cpu utilisation with clamav. Also tried with maxthreads to 1. Result is the same but frequency of locked process seems to be reduced. I think clamav has a bug somewhere. I seem to recall some other application having bad assumptions about sockets, but can't remember exactly what it was. I do know that a close() on a file descriptor does not wakeup and return an error to all threads waiting on it. FreeBSD and supposedly Linux have this behavior, but Solaris will return an error to all threads. I'm not sure this has anything to do with it, but after seeing the bug report of clamd having a lot of threads waiting in accept(), it might be a place to start investigating... -- DE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: libiconv.la
On Thu, 23 Nov 2006, Matt Smith wrote: I sure do :) If you say you have libiconv installed via ports, please be kind enough to show more detailed information, as in: $ pkg_info | grep libiconv libiconv-1.9.2_2A character set conversion library $ pkg_info -L libiconv-1.9.2_2 Information for libiconv-1.9.2_2: Files: /usr/local/man/man1/iconv.1.gz /usr/local/man/man3/iconv.3.gz /usr/local/man/man3/iconv_open.3.gz /usr/local/man/man3/iconv_close.3.gz /usr/local/bin/iconv /usr/local/include/iconv.h /usr/local/include/libcharset.h /usr/local/include/localcharset.h /usr/local/lib/libcharset.a /usr/local/lib/libcharset.la /usr/local/lib/libcharset.so /usr/local/lib/libcharset.so.1 /usr/local/lib/libiconv.a /usr/local/lib/libiconv.la /usr/local/lib/libiconv.so /usr/local/lib/libiconv.so.3 /usr/local/libdata/charset.alias /usr/local/share/doc/libiconv/iconv.1.html /usr/local/share/doc/libiconv/iconv.3.html /usr/local/share/doc/libiconv/iconv_close.3.html /usr/local/share/doc/libiconv/iconv_open.3.html I have an older system with libiconv-1.9.2_1 installed that doesn't have libiconv.la, so you may need to update your port: $ pkg_info -L libiconv-1.9.2_1 | grep lib Information for libiconv-1.9.2_1: /usr/local/include/libcharset.h /usr/local/lib/libcharset.a /usr/local/lib/libcharset.so /usr/local/lib/libcharset.so.1 /usr/local/lib/libiconv.a /usr/local/lib/libiconv.so /usr/local/lib/libiconv.so.3 /usr/local/libdata/charset.alias /usr/local/share/doc/libiconv/iconv.1.html /usr/local/share/doc/libiconv/iconv.3.html /usr/local/share/doc/libiconv/iconv_close.3.html /usr/local/share/doc/libiconv/iconv_open.3.html -- DE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Ports Update: Failed to Generate INDEX
On Tue, 5 Sep 2006, Ron Tarrant wrote:
Hi all,
While trying to update ports for FreeBSD 6.1-STABLE using this command:
/usr/local/sbin/portsdb -Uu
I've seen errors similar to yours when your Mk files are out of
date with the rest of your ports tree. As root:
# cd /usr/ports/Mk
# cvs -R update -P -d
I'm assuming that the rest of your ports tree has also been
updated accordingly ('cd /usr/ports; cvs -R update -P -d').
--
DE
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: _malloc_prefork not found
On Wed, 23 Aug 2006, S.N.Grigoriev wrote: Hi All, I've updated from amd64 6.1-RELEASE to 6-STABLE. All works fine. The only problem: when xmms or firefox starts the following message appears: /libexec/ld-elf.so.1: /lib/libpthread.so.2: Undefined symbol _malloc_prefork The Ports tree is fresh. Both xmms and firefox have been rebuilt. Who knows what have I do to fix the problem? Your system is not consistent. There is no _malloc_prefork() (or _malloc_foofork()) in -stable; it only exists in -current. You've got -current libraries (at least libpthread) on -stable. libpthread is installed in /usr/lib in RELENG_6, not /lib. So if you've downgraded from -current, you'll need to remove the -current libraries that have different locations in RELENG_6 (no, I don't think there is an automated way to do this). -- DE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gcc -pthread
On Thu, 15 Jun 2006, Mark Andrews wrote: Is there any good reason why gcc -pthread links in -lpthead except when -shared is specified? Because one may want to build applications to use different threading libraries. Application A may work better with libthr, while application B prefers libpthread. Both applications may also rely on libfoo which needs a threading library in order to be MT-safe. If libfoo records a dependency on libpthread, and application A uses libthr, then that won't work (crashy crashy). I think we took the approach a long time ago that there were basically 2 reasons for a library to require threading: 1) To be MT-safe when used in the presence of a threaded application; and 2) To create threads behind the scenes in support of an application (i.e., a hypothetical libaio). In the case of 1, the library can use #pragma weak on pthread_create and detect whether or not a threads library is present and only use locking when pthread_create != NULL (libc provides stubs for all the pthread functions necessary for locking). In the case of 2, applications should know what libraries need threads and be required to supply -lpthread (or -lthr, or -pthread) when they are built. This may or may not change in the future because all the UNIX world is Linux :( (And for possible problems when using symbol versioning.) Also the gcc man page does not match reality. -pthread Link a user-threaded process against libc_r instead of libc. man pthread mentions these libraries but provided no discussion on if or when you should include them on the command line. Nor does it mention -pthread. LIBRARY POSIX Threads Library (libpthread, -lpthread) 1:1 Threading Library (libthr, -lthr) Reentrant C Library (libc_r, -lc_r) The hacker handbook seems to indicate that you shouldn't need to use -lpthread or -lc_r. http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/dads-pthread.html That's the porters handbook and they prefer to use PTHREAD_LIBS so one can override the default threading library when building the port. PTHREAD_LIBS defaults to -pthread because -pthread does the right thing on different archs where the default threading library varies (x86, amd64, ia64 use libpthread, sparc64 uses libthr, etc). -- DE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [HACKERS] semaphore usage port based?
On Mon, 3 Apr 2006, Andrew Thompson wrote: On Mon, Apr 03, 2006 at 01:23:59AM -0300, Marc G. Fournier wrote: taking it off of pgsql-hackers, so that we don't annoy them unnecessarily ... 'k, looking at the code, not that most of it doesn't go over my head ... but ... in kern/kern_jail.c, I can see the prison_check() call ... wouldn't one want to make the change a bit further up? say in kern_prot.c? wouldn't you want to change just cr_cansignal() to allow *just* for 'case 0', when someone is just checking to see if a process is already running? I wouldn't want to be able to SIGKILL the process from a different jail, mind you ... maybe move the check for SIG0 to just before the prison_check, since, unless I'm missing something, other then determining that a process is, in fact, running, SIG0 is a benign signal? I think the suggestion was to make this EPERM rather than ESRCH to make postgres a bit happier, not remove the check entirely. Im not familiar with that part of the kernel at all, so I cant say what the consequences will be apart from the obvious information leak. I don't really see what the problem is. ESRCH seems perfectly reasonable for trying to kill (even sig 0) a process from a different jail. If you're in a jail, then you shouldn't have knowledge of processes from other jails. -- DE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [HACKERS] semaphore usage port based?
On Mon, 3 Apr 2006, Marc G. Fournier wrote: On Mon, 3 Apr 2006, Daniel Eischen wrote: I think the suggestion was to make this EPERM rather than ESRCH to make postgres a bit happier, not remove the check entirely. Im not familiar with that part of the kernel at all, so I cant say what the consequences will be apart from the obvious information leak. I don't really see what the problem is. ESRCH seems perfectly reasonable for trying to kill (even sig 0) a process from a different jail. If you're in a jail, then you shouldn't have knowledge of processes from other jails. The problem is that PostgreSQL uses kill(PID, 0) to determine whether or not another process is running when it tries to allocate a semaphore ... for instance, when it starts up, it tries to semget(54320001); ... if that fails, based on the PID that is attached to that semaphore, it tries to do a kill(PID,0) ... if that fails, it then *takes over* that semaphore ... under 4.x, kill(PID,0) *would* return that a process is running, even if it was in another jail, altho the jail issuing the kill can't see that process, so postgresql would go on to 54320002, and test that ... under FreeBSD 6.x, kill(PID, 0) reports not in use, so PostgreSQL stomps on that semaphore ... Robert brought up a good point, about recycled PIDs, but Tom Lane's response to that about the fact that we don't care if the process that is running is the one *actually* holding the semaphore, we'd rather err on the side of caution and just move on ... but we need to *know* that we need to move on ... We don't need any more information about that process ID then that it is currently in use ... nd I think that is where Andrew was coming from with issueing EPERM rather then ESRCH ... I still think ESRCH is correct. The problem isn't that kill isn't seeing other processes; it's that semaphores can be contaminated by different jails. -- DE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [HACKERS] semaphore usage port based?
On Tue, 4 Apr 2006, Peter Jeremy wrote: On Mon, 2006-Apr-03 08:19:00 -0400, Daniel Eischen wrote: I don't really see what the problem is. ESRCH seems perfectly reasonable for trying to kill (even sig 0) a process from a different jail. If you're in a jail, then you shouldn't have knowledge of processes from other jails. I agree in general. The problem here is that SysV IPC isn't jail-aware - there's a single SysV IPC address space across the physical system. This confuses (eg) postgres because it can see the SHM for a postgres instance in another jail but kill(2) claims that the process associated with that SHM doesn't exist. There appear to be two solutions: 1) Add a sysctl to change cr_cansignal() and/or prison_check() to make processes visible between jails. 2) Change SysV IPC to be jail-aware. The former is trivial - but has a number of security implications. The latter is much harder, there is apparently a RELENG_4 patch in kern/48471 but it's not clear how much work would be necessary to being it up to scratch. Or: 3) Run postgres in such a way that it doesn't look for remnant IPC information from other instances (use a per-jail-specific port #?). Postgres has no business cleaning up after different jailed instances of itself, which it wouldn't do if IPC's were per-jail. So since IPC's don't currently work that way, account for it by the way you run postgres. -- DE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [HACKERS] semaphore usage port based?
On Mon, 3 Apr 2006, Marc G. Fournier wrote: On Mon, 3 Apr 2006, Daniel Eischen wrote: Or: 3) Run postgres in such a way that it doesn't look for remnant IPC information from other instances (use a per-jail-specific port #?). Postgres has no business cleaning up after different jailed instances of itself, which it wouldn't do if IPC's were per-jail. So since IPC's don't currently work that way, account for it by the way you run postgres. This falls under well,we broke kill() so that it now reports a PID is not in use even though it is, so its has to be the application that fixes it No, kill is performing as it should. Se Robert's other response regarding sendmail. ... and you *still* haven't shown *why* kill() reporting a PID is in use, even if its not in the current jail, is such a security threat ... For reducing attacks I suppose. But conceptually, something running in a jail shouldn't be allowed to see out. -- DE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: CFLAGS in libc_r, libpthread and libthr, and MUTEX stuff in kern_mutex.c
On Fri, 10 Feb 2006, Conrad Sabatier wrote: Given that STABLE is supposed to be...well...*stable* :-) ... Could we possibly remove -D_PTHREADS_INVARIANTS, -D_LOCK_DEBUG and -g from the CFLAGS in the Makefiles for libc_r, libpthread and libthr? I've been under the impression that these options were only intended for testing/debugging under CURRENT. sigh Please go search the archives for the last time this was brought up. You are under the mistaken assumption that there is a performance impact. I think next time I'm in there, I'll just change the names of the macros or just remove them completely so they're always enabled :( -- DE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: sendmail_enable=NO
On Tue, 3 Jan 2006, Vivek Khera wrote: On Dec 31, 2005, at 6:56 PM, security wrote: And the rc.sendmail(8) under 5.4 stable says that NONE is deprecated and will be removed in a future release. According to the man page, It says that in 6.0 also, so it will probably be at least until 7.0 that it continues to work. Personally, I think having to set a bazillion variables to turn off sendmail in rc.conf and periodic.conf is just a pain (and probably a Strongly seconded. There should be one knob to disable the entire thing. SENDMAIL_ENABLE=NO should disable *everything* without touching any other knobs. wrong design as it totally violates POLA), but at least it is just a cut/paste everytime I set up a new server. -- DE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: sendmail_enable=NO
On Tue, 3 Jan 2006, Doug Barton wrote: First, rc.conf and periodic.conf are totally separate, so having just one knob for both isn't practical now, but might be an interesting project down the road. Second, IIRC the first implementation of sendmail_enable=no did actually disable all of sendmail, but since people could not send mail locally that turned out to be a POLA violation itself, so the current two-stage system was developed. It's impossible to make everyone happy here, so I think the current system is a reasonable compromise. No, you can still have *one* overriding knob to turn off everything. If folks want to enable/disable different parts of sendmail, they can do that with the other knobs. POLA says the one overriding sendmail knob should be sendmail_enable. -- DE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: mplayer-plugin/firefox/mozilla and pthread_testcancel (Was: Re: advice please)
On Wed, 21 Dec 2005, Melvyn Sopacua wrote: On Wednesday 21 December 2005 00:51, Daniel Eischen wrote: On Tue, 20 Dec 2005, Melvyn Sopacua wrote: [Switching to Thread 0x8bce400 (LWP 100139)] 0x28a80952 in pthread_testcancel () from /usr/lib/libpthread.so.2 (gdb) where #0 0x28a80952 in pthread_testcancel () from /usr/lib/libpthread.so.2 #1 0x2a17f52a in playNode () from /usr/X11R6/lib/browser_plugins/mplayerplug-in-qt.so #2 0x2a181a1c in playPlaylist () from /usr/X11R6/lib/browser_plugins/mplayerplug-in-qt.so #3 0x28a722f9 in pthread_create () from /usr/lib/libpthread.so.2 #4 0x28b1f367 in _ctx_start () from /lib/libc.so.6 You've probably got things linked to two different versions of libpthread. Please see /usr/ports/UPDATING, section 20050722. It's a clean install (well, 5.x to a new slice, then recompiled after boot). Please read the UPDATING section. You have to rebuild all your ports now that you are using 6.x. You can't just upgrade firefox and mplayer plugin. -- DE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: mplayer-plugin/firefox/mozilla and pthread_testcancel (Was: Re: advice please)
On Wed, 21 Dec 2005, Melvyn Sopacua wrote: On Wednesday 21 December 2005 14:57, Daniel Eischen wrote: Please read the UPDATING section. You have to rebuild all your ports now that you are using 6.x. You can't just upgrade firefox and mplayer plugin. I didn't. I built all ports from scratch or used 6-stable packages. I think My apologies. Your previous email sounded like you had built ports on 5.x and then upgraded some of them on 6.x You can use /etc/libmap.conf to be sure: libpthread.so libpthread.so.2 libpthread.so.1 libpthread.so.2 You might want to check /etc/libmap.conf just to make sure you don't have anything mapped to libpthread.so.1. it's an error in mplayer-plugin, unless you tell me it works for you, then the only thing that makes sense is the use of nvidia-driver. That has been a problem in the past, but I thought they released a newer driver that works correctly with libpthread and libthr. -- DE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: mplayer-plugin/firefox/mozilla and pthread_testcancel (Was: Re: advice please)
On Tue, 20 Dec 2005, Melvyn Sopacua wrote: [Switching to Thread 0x8bce400 (LWP 100139)] 0x28a80952 in pthread_testcancel () from /usr/lib/libpthread.so.2 (gdb) where #0 0x28a80952 in pthread_testcancel () from /usr/lib/libpthread.so.2 #1 0x2a17f52a in playNode () from /usr/X11R6/lib/browser_plugins/mplayerplug-in-qt.so #2 0x2a181a1c in playPlaylist () from /usr/X11R6/lib/browser_plugins/mplayerplug-in-qt.so #3 0x28a722f9 in pthread_create () from /usr/lib/libpthread.so.2 #4 0x28b1f367 in _ctx_start () from /lib/libc.so.6 You've probably got things linked to two different versions of libpthread. Please see /usr/ports/UPDATING, section 20050722. -- DE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Missing libpthread.so.*
On Fri, 9 Dec 2005, Scot Hetzel wrote: On 12/9/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: FBSD 5.0 I'm getting missing libpthread.so.* error, so I copied it from another FBSD box, and now getting: Undefined symbol __malloc_lock So I went into /usr/src/lib/libpthread and did make/install. I noticed that it installed libkse.so.* but not libpthread.so.*. What you need to do is create a link between libpthread.so.* and libkse.so.*: No, he's hosed his system. There is no libpthread in 5.0. Somehow you've brought in binaries from somewhere else that are linked to libpthread because they were linked on a more recent version of FreeBSD. Either that, or you have a /etc/libmap.conf that is trying to use libpthread. -- DE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Missing libpthread.so.*
On Fri, 9 Dec 2005 [EMAIL PROTECTED] wrote: Geez, it was that simple!!! I've searched everywhere for libpthread, but didn't bother to see doc on libkse. My bad... Stop using libkse. In 5.0 it's an experimental library. If you want libpthread, you need to upgrade to 5-stable. Like I've said before, you've either hosed your system or are using an improper (for 5.0) /etc/libmap.conf. There should be no references to libpthread.so in 5.0. -- DE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kpdf crashes with LIBPTHREAD_SYSTEM_SCOPE set (Was: Re: FreeBSD MySQL still WAY slower than Linux)
On Tue, 28 Jun 2005, Michael Nottebrock wrote: On Tuesday, 28. June 2005 06:43, Daniel Eischen wrote: I can't reproduce it in -current. -bash-2.05b$ uname -a FreeBSD orion 6.0-CURRENT FreeBSD 6.0-CURRENT #0: Thu May 5 13:29:41 EDT 2005 Yeah, you already said that before. So where do we go from here? Should I try to get a backtrace of the crash? With gdb? Ktrace? Should I compile libpthread of other parts of the system with special debug flags? Should I report this on freebsd-threads instead? Or should I just let the issue go? What CFLAGS did you use to build your ports/system? Run it under gdb and see what you get. -- DE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kpdf crashes with LIBPTHREAD_SYSTEM_SCOPE set (Was: Re: FreeBSD MySQL still WAY slower than Linux)
On Mon, 27 Jun 2005, Michael Nottebrock wrote: On Monday, 20. June 2005 19:17, Daniel Eischen wrote: Works here on a month or two old -current. ?I'm using /usr/local/ant/docs/appendix_e.pdf as a test (it's 60 pages or so). Crashes for me: [EMAIL PROTECTED]:127:~ env LIBPTHREAD_SYSTEM_SCOPE=1 kpdf 'http://drtc.isibang.ac.in/%7Eprachi/apache-ant-1.5.4/docs/appendix_e.pdf ' Bus error [EMAIL PROTECTED]:1:~ kpdf 'http://drtc.isibang.ac.in/%7Eprachi/apache-ant-1.5.4/docs/appendix_e.pdf ' [EMAIL PROTECTED]:0:~ I don't have a -CURRENT machine to test. Try -stable. I just retried with today's 5.4-STABLE - still crashes. I can't reproduce it in -current. -bash-2.05b$ uname -a FreeBSD orion 6.0-CURRENT FreeBSD 6.0-CURRENT #0: Thu May 5 13:29:41 EDT 2005 -- DE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: libc.so.4 libc_r.so.4 in ices0
On Fri, 24 Jun 2005, Kevin S. Brackett wrote: Well, the problem is when libc and libc_r are linked together, I recompiled without -lc and it's now fine, but not really what i'd consider a great fix... I suggest you go do some research -- look in our archives and man pages. libc is linked automatically; you don't want to specify it yourself. Link order is important; your application must be linked to libc_r (or libpthread/libthr) before libc. Using -lc_r -lc will work, -lc -lc_r will not. Just let the compiler link to libc for you. -- DE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: update libpthread
On Tue, 21 Jun 2005, Kipp Holger wrote: Khanh Cao Van wrote on Tue 21.06.2005 16:00 Peter Jeremy tell me that I have to update libpthread to be able to install JDK 1.4 on freeBSD 4.7 . But I could not find out what ports contain that lib . Help me if you know . Not port. Base system. Considering this, the best solution for you seems to be to upgrade the base system to 4.8-RELEASE or later. src/libpthread is not in 4.x and can not be made to work in 4.x. In 4.x, your only solution is to use src/libc_r, which is now marked for deprecation in -current (6.x). If you want reliable Java support, I suggest you use -stable (5.x) which has libpthread. Go ask the -java mailing list for more info. -- DE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kpdf crashes with LIBPTHREAD_SYSTEM_SCOPE set (Was: Re: FreeBSD MySQL still WAY slower than Linux)
On Mon, 20 Jun 2005, Michael Nottebrock wrote: On Saturday, 11. June 2005 17:05, Daniel Eischen wrote: You can set the environment variable LIBPTHREAD_SYSTEM_SCOPE to force libpthread to use system scope. I've played around with that variable (set it in .xsession) and found that kpdf (from graphics/kdegraphics3) will reproducably crash if it is set. Unsetting it in a shell running on top of a KDE started with mentioned .xsession and launching kpdf from there will remedy the problem. The backtrace I get is probably useless, let me know if (and how) I should recompile libpthread or other system libraries with debug symbols ... This is on 5.4-STABLE, two-three weeks old. Works here on a month or two old -current. I'm using /usr/local/ant/docs/appendix_e.pdf as a test (it's 60 pages or so). -- DE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kpdf crashes with LIBPTHREAD_SYSTEM_SCOPE set (Was: Re: FreeBSD MySQL still WAY slower than Linux)
On Mon, 20 Jun 2005, Michael Nottebrock wrote: On Monday, 20. June 2005 18:53, Daniel Eischen wrote: Works here on a month or two old -current. I'm using /usr/local/ant/docs/appendix_e.pdf as a test (it's 60 pages or so). Crashes for me: [EMAIL PROTECTED]:127:~ env LIBPTHREAD_SYSTEM_SCOPE=1 kpdf 'http://drtc.isibang.ac.in/%7Eprachi/apache-ant-1.5.4/docs/appendix_e.pdf' Bus error [EMAIL PROTECTED]:1:~ kpdf 'http://drtc.isibang.ac.in/%7Eprachi/apache-ant-1.5.4/docs/appendix_e.pdf' [EMAIL PROTECTED]:0:~ I don't have a -CURRENT machine to test. Try -stable. -- Dan Eischen ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD MySQL still WAY slower than Linux
On Mon, 13 Jun 2005, Pete French wrote: You can set the environment variable LIBPTHREAD_SYSTEM_SCOPE to force libpthread to use system scope. This is easier than rebuilding libpthread (with SYSTEM_SCOPE_ONLY defined) and allows you to use M:N for some applications and 1:1 for others. Is the sysctl kern.threads.thr_scope_sys supposed to achieve the same thing ? using the environment variable solves a different problem I have, but setting the sysctl doesn't. Is there any way to force pthreads to system scope by default ? kern.threads.thr_scope_sys is for libthr only. Reread the above for the answer to your last question. -- DE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD MySQL still WAY slower than Linux
On Mon, 13 Jun 2005, Pete French wrote: Reread the above for the answer to your last question. Sorry, rephrased - 'How can I set that environment variable for all processes?' login.conf perhaps? I'm kind of embarassed to have to ask, as this should surely be very simple, but I cant think of anywhere to set system-wide environment variables which all processes will have. I've only ever done this in shell profiles before and I cant think of anywhere global to set something like this. I tried 'man environ' and similar but it doesnt help The answer to your question was in parenthesis (rebuild libpthread with SYSTEM_SCOPE_ONLY defined). -- DE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD MySQL still WAY slower than Linux
Robert Watson wrote: On Fri, 10 Jun 2005, Steve Roome wrote: We're using mostly: 5.4-STABLE FreeBSD 5.4-STABLE #0: Mon Jun 6 12:22:18 BST 2005 In my experience, the following factors make a big performance difference: - Thread package. In 5.x, you get process scope threads by default, but it turns out MySQL is tuned for system scope threads, and this is particularly visible in the supersmack benchmark, which competes many client processes against a few server threads. I'm not sure what the condition is of libthr on 5.x, but you could give it a spin. In 6.x, libthr has been largely rewritten and is a great deal faster. I think there's a compile-time option to make libpthread use system scope threads but the details ellude me. The Linuxthreads library may well provide a substantial improvement -- not as good for MySQL as the 6.x libthr, but perhaps much more appropriate than libpthread. You can set the environment variable LIBPTHREAD_SYSTEM_SCOPE to force libpthread to use system scope. This is easier than rebuilding libpthread (with SYSTEM_SCOPE_ONLY defined) and allows you to use M:N for some applications and 1:1 for others. -- DE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD MySQL still WAY slower than Linux
On Fri, 10 Jun 2005, Kris Kennaway wrote: On Fri, Jun 10, 2005 at 10:04:23PM +0100, Tom Gidden wrote: Hi Guy, On 10 Jun 2005, at 21:37, Guy Helmer wrote: Have you tried a kernel with PREEMPTION enabled? I haven't quantified the effect, but it's improved performance in some situations. Have you tried increasing vfs.read_max? Thanks for your suggestions... I've given them a go, and it looks like there's no discernible difference in performance for either/ both, on KSE, libthr or LinuxThreads. =( Did you retry with HTT yet? Note that it's disabled by default in FreeBSD, so if you see no performance improvement when you only turn it on in the BIOS, that could be why. Or repeat the Linux tests without HTT enabled. -- DE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: libpthread problem (segfaults)
On Wed, 1 Jun 2005, Benjamin Lutz wrote: I've found the problem for my own program. I was compiling with -lc. Why I started doing that in the first place I can't remember, but removing that option fixed above fatal error, and seems to have no negative effects (of course, why would it). So, as a conclusion: gcc apparently produces broken code when -lc is specified. I don't know much about how gcc is supposed to work, but that might actually be a bug? No, gcc (the linker really) is doing exactly what you are telling it. The linker already brings in libc, you have to use -nostdlib to prevent it. You must link to objects in the correct order. libpthread, libthr, and libc_r all provide some functions that are overloaded from libc. When you link to libc first, you get the libc versions of those functions instead of the thread versions of them. And, something in the 5.3-5.4 upgrade process went wrong which left me with a broken libpthread. Can't say what exactly, maybe my system was slightly broken to begin with. libpthread ain't broke; your applications are probably linked incorrectly. -- DE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PTHREAD_INVARIANTS in 5.x
On Tue, 10 May 2005, Mikhail Teterin wrote: = As we were counting down to 5.3-RELEASE, I noticed, that all = threading libraries still compile with PTHREAD_INVARIANTS. My = suggestion to have this = fixed was shutdown as not enough time = was left for testing the 5.3. = Can we have these things turned off NOW, so that, at least, 5.5 = stands a chance? Thanks! = = What makes you think there is a measurable performance impact with = them on? Interesting... Are you implying, the debugging code makes no difference, or are genuinly asking? Both. There are additional steps in the code, that are only done when the define is on. Does not look like much in libthr, but c_r's uthread/uthread_mutex.c seems quite affected, for example. And you know it, of course... c_r is deprecated, so I've no interest in that. My only concern is with libthr and libpthread. = Regardless, it would first need to be in -current, not -stable. I thought, the debugging features (WITNESS INVARIANTS) are always on in -current, but are turned off in -stable for maximum performance. Is that no longer true? They've never been off in -current. You'd have to show turning them off causes no harm. -- DE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PTHREAD_INVARIANTS in 5.x
On Wed, 11 May 2005, Jonathan Noack wrote:
I checked out _PTHREADS_INVARIANTS for libthr and libpthread on CURRENT.
As far as I can tell, all but one of the defines under
_PTHREADS_INVARIANTS are ASSERTs; they check for a condition and if it
is false result in a fatal error. These should be very visible if they
are being tripped. Only MUTEX_INIT_LINK actually *does* something. It
is defined in src/lib/libpthread/thread/thr_mutex.c at lines 43-46 and
in src/lib/libthr/thread/thr_mutex.c at lines 44-47:
#define MUTEX_INIT_LINK(m) do {\
(m)-m_qe.tqe_prev = NULL; \
(m)-m_qe.tqe_next = NULL; \
} while (0)
I'm not sure what impact removing this explicit initialization would
have. If we're not seeing fatal errors, everything else is just slowing
us down. Assuming we feel our thread implementations are production
worthy, we should disable these checks for releases. That is, unless I
am missing something...
I wrote the darn things, and they are useful in that they can
provide useful information if there are bugs and also for
detecting if the application is linked to multiple thread
libraries. For the init links macro, it is only used when
the mutex is initialized and on unlock. It's two instructions.
The others are also just a couple of instructions and shouldn't
be called often.
This is way overblown and they're other areas for much
better optimizations than worrying about a couple of
instructions. Perhaps if it were called _PTHREAD_ROBUST
instead of _PTHREAD_INVARIANTS, noone would notice ;-)
That's the last I'll say. re@ can do whatever they want
with my blessing.
--
DE
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Performance issue
On Tue, 10 May 2005, Suleiman Souhlal wrote: Hi, On May 10, 2005, at 1:24 AM, Daniel Eischen wrote: No, libc_r wraps execve() and a lot of other syscalls that libpthread or libthr don't need to. Take a look at libc_r/uthread/ uthread_execve.c and you will see it sets the signal mask before exec()ing. Couldn't we do the same thing in libpthread, in the not-threaded case? I apologize if I'm asking stupid questions.. :) No ;-) We don't want to wrap functions unecessarily. Applications not linked to a thread library still have to use the actual syscall, so there's no point in wrapping extra functions just to make sigprocmask() faster when linked with libpthread. -- DE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PTHREAD_INVARIANTS in 5.x
On Tue, 10 May 2005, Mikhail Teterin wrote: Hello! As we were counting down to 5.3-RELEASE, I noticed, that all threading libraries still compile with PTHREAD_INVARIANTS. My suggestion to have this fixed was shutdown as not enough time was left for testing the 5.3. 6 months later the much anticipated 5.4 ships with these defines again and again FreeBSD is going to lose all thread-using benchmarks out there (such as MySQL's)... Can we have these things turned off NOW, so that, at least, 5.5 stands a chance? Thanks! What makes you think there is a measurable performance impact with them on? Regardless, it would first need to be in -current, not -stable. -- DE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Performance issue
On Mon, 9 May 2005, Suleiman Souhlal wrote:
Hello,
I ran ktrace(1) on it, and it appears that python keeps calling
sigprocmask() continually:
673 python 0.07 CALL sigprocmask(0x3,0,0x811d11c)
673 python 0.05 RET sigprocmask 0
673 python 0.09 CALL sigprocmask(0x1,0,0x8113d1c)
673 python 0.05 RET sigprocmask 0
etc..
This explains why it's using so much system time. Now the question is
why is python doing this?
I don't know what python's doing, but it might not be calling
sigprocmask directly. There are a few libc functions that use
sigprocmask:
db/btree/
db/hash/
pselect(),
setmode(),
{sig}setjmp(), {sig}longjmp(),
grantpt(),
system()
to name a few. Python may also be using other libraries which
use sigprocmask().
--
DE
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Performance issue
On Tue, 10 May 2005, Peter Jeremy wrote: On Mon, 2005-May-09 11:00:18 -0400, Ewan Todd wrote: I have what I think is a serious performance issue with fbsd 5.3 release. I've read about threading issues, and it seems to me that that is what I'm looking at, but I'm not confident enough to rule out that it might be a hardware issue, a kernel configuration issue, or something to do with the python port. There does appear to be a problem in FreeBSD. Python is built with threading enabled by default, the threading libraries play with the signal mask and there have been extensive changes there. My The threading libraries don't play with the signal mask. In fact, libpthread has userland versions of sigprocmask() et. al. and won't even make the syscall() unless the threads are system scope. There is a special thread in libpthread that handles signals which does use the system sigprocmask(), but unless the application is making heavy use of signals in general, it shouldn't matter. suggestions on things you could check are: 1) Rebuild python with threading disabled (add '-DWITHOUT_THREADS' to the 'make' command line and see if that makes any difference 2) Re-write the sample program in a non-threaded language - eg C or perl and see if the high system time goes away. Unfortunately, I can't think of a solution at present. You can also set LIBPTHREAD_SYSTEM_SCOPE in the environment to force libpthread to use system scope threads. It uses process scope threads by default. -- DE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Performance issue
On Mon, 9 May 2005, Suleiman Souhlal wrote: On May 9, 2005, at 3:54 PM, Daniel Eischen wrote: The threading libraries don't play with the signal mask. In fact, libpthread has userland versions of sigprocmask() et. al. and won't even make the syscall() unless the threads are system scope. There is a special thread in libpthread that handles signals which does use the system sigprocmask(), but unless the application is making heavy use of signals in general, it shouldn't matter. I think I've found the problem: Python uses setjmp/longjmp to protect against SIGFPU every time it does floating point operations. The python script does not actually use threads, and libpthread assumes non-threaded processes are system scope. So, it would end up using the sigprocmask syscall, even though it doesn't really need to. The diff at http://people.freebsd.org/~ssouhlal/testing/ thr_sigmask-20050509.diff fixes this, by making sure the process is threaded, before using the syscall. I don't think that patch is correct. You need the signal mask in the kernel to match in case of an exec() after a fork() for instance. If the application fork()'s, then changes the signal mask in the child (which is now single threaded), then the child exec()s, the mask is wrong. If the process wasn't linked to libpthread, then the longjmp() and setjmp() would still be calling the syscall, so it isn't the syscall itself that is making things slower. You'll notice that there are two calls to __sys_sigprocmask() in the section of code you have patched. You could eliminate the second call if you do some of what the remainder of the function does instead of returning early (the locks aren't needed and pending signals don't need to be run down). -- DE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Performance issue
On Mon, 9 May 2005, Daniel Eischen wrote: On Mon, 9 May 2005, Suleiman Souhlal wrote: I think I've found the problem: Python uses setjmp/longjmp to protect against SIGFPU every time it does floating point operations. The python script does not actually use threads, and libpthread assumes non-threaded processes are system scope. So, it would end up using the sigprocmask syscall, even though it doesn't really need to. The diff at http://people.freebsd.org/~ssouhlal/testing/ thr_sigmask-20050509.diff fixes this, by making sure the process is threaded, before using the syscall. [ ... ] If the process wasn't linked to libpthread, then the longjmp() and setjmp() would still be calling the syscall, so it isn't the syscall itself that is making things slower. You'll notice that there are two calls to __sys_sigprocmask() in the section of code you have patched. You could eliminate the second call if you do some of what the remainder of the function does instead of returning early (the locks aren't needed and pending signals don't need to be run down). As in something like this: http://people.freebsd.org/~deischen/kse/thr_sigmask.c.diffs It has not been tested. -- DE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Performance issue
On Mon, 9 May 2005, Jonathan Noack wrote: On 05/09/05 18:47, Daniel Eischen wrote: If the process wasn't linked to libpthread, then the longjmp() and setjmp() would still be calling the syscall, so it isn't the syscall itself that is making things slower. You'll notice that there are two calls to __sys_sigprocmask() in the section of code you have patched. You could eliminate the second call if you do some of what the remainder of the function does instead of returning early (the locks aren't needed and pending signals don't need to be run down). As in something like this: http://people.freebsd.org/~deischen/kse/thr_sigmask.c.diffs It has not been tested. When I tried to test this every threaded program died with sig 11. Does this require me to recompile the program before it will work? No, the patch just must have a bug in it. -- DE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Performance issue
On Tue, 10 May 2005, Suleiman Souhlal wrote: Hello, On May 9, 2005, at 7:21 PM, Daniel Eischen wrote: I don't think that patch is correct. You need the signal mask in the kernel to match in case of an exec() after a fork() for instance. If the application fork()'s, then changes the signal mask in the child (which is now single threaded), then the child exec()s, the mask is wrong. If the process wasn't linked to libpthread, then the longjmp() ^^ or any thread library. and setjmp() would still be calling the syscall, so it isn't the syscall itself that is making things slower. You'll notice that there are two calls to __sys_sigprocmask() in the section of code you have patched. You could eliminate the second call if you do some of what the remainder of the function does instead of returning early (the locks aren't needed and pending signals don't need to be run down). Processes linked with libc_r NEVER call the syscall, once they have started (after rtld-elf): [...] Is this a bug in libc_r? No, libc_r wraps execve() and a lot of other syscalls that libpthread or libthr don't need to. Take a look at libc_r/uthread/uthread_execve.c and you will see it sets the signal mask before exec()ing. -- DE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: pthreads and nagios issue
On Fri, 6 May 2005, Christophe Yayon wrote: Hi, But is it a Nagios or FreeBSD problem, if you read what's new section on nagios site, you can see : - FreeBSD and threads. On FreeBSD there's a native user-level implementation of threads called 'pthread' and there's also an optional ports collection 'linuxthreads' that uses kernel hooks. Some folks from Yahoo! have reported that using the pthread library causes Nagios to pause under heavy I/O load, causing some service check results to be lost. Switching to linuxthreads seems to help this problem, but not fix it. The lock happens in liblthread's __pthread_acquire() - it can't ever acquire the spinlock. It happens when the main thread forks to execute an active check. On the second fork to create the grandchild, the grandchild is created by fork, but never returns from liblthread's fork wrapper, because it's stuck in __pthread_acquire(). Maybe some FreeBSD users can help out with this problem. -- And it appears to be a FreeBSD pthread implementation problem (not a Nagios specific problem...) What do u think about that ? Re-read what is written above. __pthread_acquire() is in liblthread; that is linuxthreads and not a POSIX function. The reported FreeBSD pthread problem above is a pause under heavy I/O load I'm not sure what could cause that -- need more info. -- DE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ping: sendto: No buffer space available
On Thu, 10 Mar 2005, Mario Sergio Fujikawa Ferreira wrote: Hi, I have been experiencing this $ ping 10.1.1.1 PING 10.1.1.1 (10.1.1.1): 56 data bytes ping: sendto: No buffer space available ping: sendto: No buffer space available Does anyone have any ideas? Doing # ifconfig fxp0 down # ifconfig fxp0 up fixes it but it won't recover otherwise. Yeah, I've gotten it also and on 4.x as well. It occurred on both de and fxp devices as well. The box is a router with 4 or 5 interfaces which are nowhere near fully loaded. We only get this problem on the interface that is connected to a hub; all other interfaces are on switches. It is annoying because it happens once every week or two. -- DE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: I can not surf on Flash powered sites.
On Wed, 2 Mar 2005, Brian Behlendorf wrote: On Wed, 2 Mar 2005, Ruben van Staveren wrote: Are you using Xorg6.8.1 and have enabled the Composite extension ? (as in Section Extensions Option Composite Enable EndSection ) Then add this line to /usr/X11R6/bin/firefox, just beneath the #! /bin/sh export XLIB_SKIP_ARGB_VISUALS=1 Didn't make a difference with native builds of www/firefox v 1.0.1 and www/flashplugin-firefox 0.4.12. Why don't you run firefox with -g and get a dump and backtrace out of it? -- DE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: I can not surf on Flash powered sites.
On Wed, 2 Mar 2005, Brian Behlendorf wrote: On Wed, 2 Mar 2005, Daniel Eischen wrote: Why don't you run firefox with -g and get a dump and backtrace out of it? Because, as I said earlier this thread: I do try it every couple of weeks to see if it works, but the best it gets is two-three web sites and then the seg fault. I realize until I sit down with a stack trace I haven't earned the right to complain, so I haven't yet, figuring it'll be important enough someday to someone clueful enough. Or, Macromedia will some day lighten up and let Mozilla include it as part of the web browser by default. Or something. ...and that I've got nowhere near the chops to do anything useful with a stack trace that I'm sure others do. I thought I'd pipe up in response to Ruben's message to provide a data point. Am I the only one for whom Firefox and www/flashplugin-firefox doesn't work? Is it that hard to type 'firefox -g', alias firefox=firefox -g, or whatever, and use it that way for a few days to see if you can get a trace? I'm just wondering if it has the same problem as linuxpluginwrapper, or bad assumptions about mutexes being recursive or unlocking one you don't own. Most folks I know use the linuxpluginwrapper so we don't have any experience with the native flash player. I think I recall trying it and it not working, hence the use of linuxpluginwrapper. -- DE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
