can't build sysutils/apcupsd on 9.1-RC3

2012-11-13 Thread Thomas Eberhardt
Just tested out FreeBSD 9.1-RC3 and i can't build sysutils/apcupsd because of http://www.freebsd.org/cgi/query-pr.cgi?pr=169901. Error messages are: …... LDsrc/apcupsd /usr/ports/sysutils/apcupsd/work/apcupsd-3.14.10/src/lib/libapc.a(astring.o): In function `astring::assign(char const*, i

Re: nomenclature for conf files

2012-11-13 Thread ill...@gmail.com
On 12 November 2012 00:12, Zoran Kolic wrote: > It might sound stupid, but I'd like to know if there's > any difference. Are those 3 line the same? > > WITH_KMS=YES > WITH_KMS="YES" > WITH_KMS=yes > > Best regards In /etc/make.conf it shouldn't matter: they should all be treated as synonyms for:

Re: nomenclature for conf files

2012-11-13 Thread Jakub Lach
> Also, the FreeBSD makefiles and sources test all WITH_* variables with > .ifdef or #ifdef so the value doesn't matter and can even be empty. This is exactly the point. But I still use 'yes' just for mnemotechnical reason. -- View this message in context: http://freebsd.1045724.n5.nabble.co

Re: nomenclature for conf files

2012-11-13 Thread Kurt Buff
OK - I figured it out. I have always followed the examples in the handbook. I have also been bitten more than once when I've typoed, and left out one of the quote marks. That tends to leave a lasting impression, as it can be painful to fix, sometimes requiring to drop into single user mode to cle

thread taskq / unp_gc() using 100% cpu and stalling unix socket IPC

2012-11-13 Thread Markus Gebert
Hi there We have a pair of servers running FreeBSD 9.1-RC3 that act as transparent layer 7 loadbalancer (relayd) and pop/imap proxy (dovecot). Only one of them is active at a given time, it's a failover setup. From time to time the active one gets in a state in which the 'thread taskq' thread u

Problems with ZFS's user quota.

2012-11-13 Thread Derek Kulinski
Hi everyone, I'm having problem using user quotas in ZFS, I think something is broken, but it very possible that I'm just doing something wrong. I have two problems actually: 1. When trying to define quota for a filesystem that has sub filesystem the zfs userspace behaves weird: [chinatsu]:/t

Re: thread taskq / unp_gc() using 100% cpu and stalling unix socket IPC

2012-11-13 Thread Markus Gebert
On 13.11.2012, at 19:30, Markus Gebert wrote: > To me it looks like the unix socket GC is triggered way too often and/or > running too long, which uses cpu and worse, causes a lot of contention around > the unp_list_lock which in turn causes delays for all processes relaying on > unix sockets

Re: thread taskq / unp_gc() using 100% cpu and stalling unix socket IPC

2012-11-13 Thread Adrian Chadd
Oh lordie, just hack the kernel to make IP_BINDANY usable by any uid, not just root. I was hoping that capabilitiies would actually be useful these days, but apparently not. :( Then you can stop this FD exchange nonsense and this problem should go away. :) Adrian On 13 November 2012 16:41, Ma

Compilation error while compiling FreeBSD9-STABLE with Clang

2012-11-13 Thread Alie Tan
Hi. I got compilation error while compiling FreeBSD9-STABLE with Clang: -m32 -c /usr/src/sys/boot/i386/boot2/sio.S clang: warning: the clang compiler does not support '-fno-unit-at-a-time' ld -static -N --gc-sections -nostdlib -m elf_i386_fbsd -Ttext 0x2000 -o boot2.out /usr/obj/usr/src/sys/bo

Re: thread taskq / unp_gc() using 100% cpu and stalling unix socket IPC

2012-11-13 Thread Alfred Perlstein
On 11/13/12 4:41 PM, Markus Gebert wrote: On 13.11.2012, at 19:30, Markus Gebert wrote: To me it looks like the unix socket GC is triggered way too often and/or running too long, which uses cpu and worse, causes a lot of contention around the unp_list_lock which in turn causes delays for all

Re: thread taskq / unp_gc() using 100% cpu and stalling unix socket IPC

2012-11-13 Thread Konstantin Belousov
On Wed, Nov 14, 2012 at 01:41:04AM +0100, Markus Gebert wrote: > > On 13.11.2012, at 19:30, Markus Gebert wrote: > > > To me it looks like the unix socket GC is triggered way too often and/or > > running too long, which uses cpu and worse, causes a lot of contention > > around the unp_list_loc