Re: head && auditdistd
This is new (relatively) user which required in host machine when you make installworld. Months ago I proposed to add check for existence of this user at begin of any actions with sources (for example for interactive mode only, and optional for build-, but mandatory for install- ). But as it seems that just not happened, and more and more peoples are stumbling at same missed user-thing. Second thing, yes, would be good to have more information either in man or in handbook about this user and else. 2013/5/14 Matthias Apitz > > Hello, > > Today morning I wanted to make and install a fresh /head to an USB key > for further distribution the usual way: > > ... > # make installworld DESTDIR=/mnt > # make installkernel DESTDIR=/mnt KERNCONF=GENERIC INSTALL_NODEBUG=t > # make distrib-dirs DESTDIR=/mnt > # make distribution DESTDIR=/mnt > > 'installworld' instructed me about the missing user 'auditdistd'; I have > read what src/UPDATING says, but can't find any pointer to the man page > of auditdistd(8) or in our handbook; with Don Google I got to know that I > have to add this with something like > > # pw useradd -n auditdistd -g audit -c "Auditdistd unprivileged user" -d > /var/empty -s /usr/sbin/nologin > > Can someone bring a bit light into this? Thanks in advance > > matthias > > -- > Sent from my FreeBSD netbook > > Matthias Apitz | - No system with backdoors like > Apple/Android > E-mail: g...@unixarea.de | - Never being an iSlave > WWW: http://www.unixarea.de/ | - No proprietary attachments, no HTML/RTF > in E-mail > phone: +49-170-4527211 | - Respect for open standards > ___ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > -- Regards, Alexander Yerenkow ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: files disappearing from ls on NFS
On Mon, 13 May 2013, Rick Macklem wrote: RM>Hartmut Brandt wrote: RM>> On Sun, 12 May 2013, Rick Macklem wrote: RM>> RM>> RM>Hartmut Brandt wrote: RM>> RM>> Hi, RM>> RM>> RM>> RM>> I've updated one of my -current machines this week (previous RM>> update RM>> RM>> was in RM>> RM>> february). Now I see a strange effect (it seems only on NFS RM>> mounts): RM>> RM>> ls or RM>> RM>> even echo * will list only some files (strange enough the first RM>> files RM>> RM>> from RM>> RM>> the normal, alphabetically ordered list). If I change something RM>> in the RM>> RM>> directory (delete a file or create a new one) for some time the RM>> RM>> complete RM>> RM>> listing will appear but after sime time (seconds to a minute or RM>> so) RM>> RM>> again RM>> RM>> only part of the files is listed. RM>> RM>> RM>> RM>> A ktrace on ls /usr/src/lib/libc/gen shows that getdirentries is RM>> RM>> called RM>> RM>> only once (returning 4096). For a full listing getdirentries is RM>> called RM>> RM>> 5 RM>> RM>> times with the last returning 0. RM>> RM>> RM>> RM>> I can still open files that are not listed if I know their name, RM>> RM>> though. RM>> RM>> RM>> RM>> The NFS server is a Windows 2008 server with an OpenText NFS RM>> Server RM>> RM>> which RM>> RM>> works without problems to all the other FreeBSD machines. RM>> RM>> RM>> RM>> So what could that be? RM>> RM>> RM>> RM>I've attached a patch that might be worth trying. It is a "shot in RM>> the dark", RM>> RM>but brings the new NFS client's readdir closer to the old one RM>> (which you RM>> RM>mentioned still works ok). RM>> RM> RM>> RM>Please let me know how it goes, if you have a chance to test it, RM>> rick RM>> RM>> Hi Rick, RM>> RM>> the patch doesn't help. RM>> RM>> I wrote a small test program, which opens a directory, calls RM>> getdents(2) RM>> in a loop and dumps that. I figured out, that the return of the system RM>> call depends on the buffer size I pass to it. The directory has a RM>> block RM>> size of 4k according to fstat(2). If I use that, I get some 300 of the RM>> almost 500 directory entries. If I use 8k, I get just around 200 and RM>> if I RM>> use 16k I get a handfull. If I dump the buffer in this case I see RM>> 0x200 RM>> bytes filled with directory entries, then a lot of zeros and starting RM>> from RM>> 0x1000 again data. This is of course ignored because of the zeros RM>> before. RM>> RM>And for this case getdents(2) returned 16K? It is normal for getdents(2) RM>to return less than requested and when end of dir occurs, it should return 0. RM> RM>But if it returns 16K, there shouldn't be zeroed space in the middle of RM>it. RM> RM>And this always occurs or only after you wait a while? (You noted in the RM>above description that it would be ok for a little while after a directory RM>change and then would break, which suggests some kind of caching problem.) Today in the morning everything was fine. After waiting 5 minutes, again only partial directories. When I do a read with 8k buffer size, getdents(2) returns 8k, but starting from 0x200 until 0x1000 the buffer is filled with zeros. The entry just before the zeroes ends exactly at 0x200 (that would be the first byte of the next entry) and at 0x1000 a new entry starts. The rest of the buffer is fine. The next read returns only 4k and seems to be fine - altough it contains some junk non-zero bytes in the padding. Ten minutes later again everything is fine. I tries to spy at the NFS communication with tcpdump, but it seems unwilling to display something useful about the NFS. Is it able to decode the readdir stuff? harti ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: head && auditdistd
On Tue, 14 May 2013 10:05:36 +0300 Alexander Yerenkow wrote: > This is new (relatively) user which required in host machine when you make > installworld. > Months ago I proposed to add check for existence of this user at begin of > any actions with sources (for example for interactive mode only, and > optional for build-, but mandatory for install- ). > But as it seems that just not happened, and more and more peoples are > stumbling at same missed user-thing. > Second thing, yes, would be good to have more information either in man or > in handbook about this user and else. > > > 2013/5/14 Matthias Apitz > > > > > Hello, > > > > Today morning I wanted to make and install a fresh /head to an USB key > > for further distribution the usual way: > > > > ... > > # make installworld DESTDIR=/mnt > > # make installkernel DESTDIR=/mnt KERNCONF=GENERIC INSTALL_NODEBUG=t > > # make distrib-dirs DESTDIR=/mnt > > # make distribution DESTDIR=/mnt > > > > 'installworld' instructed me about the missing user 'auditdistd'; I have > > read what src/UPDATING says, but can't find any pointer to the man page > > of auditdistd(8) or in our handbook; with Don Google I got to know that I > > have to add this with something like > > > > # pw useradd -n auditdistd -g audit -c "Auditdistd unprivileged user" -d > > /var/empty -s /usr/sbin/nologin > > > > Can someone bring a bit light into this? Thanks in advance > > auditdistd:*:78:77:Auditdistd unprivileged user:/var/empty:/usr/sbin/nologin Just copy this line and paste it using vipw. -- Gary Jennejohn ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: head && auditdistd
El día Tuesday, May 14, 2013 a las 10:05:59AM +0200, Gary Jennejohn escribió: > > 2013/5/14 Matthias Apitz > > > > > > > > # pw useradd -n auditdistd -g audit -c "Auditdistd unprivileged user" -d > > > /var/empty -s /usr/sbin/nologin > > > > > > Can someone bring a bit light into this? Thanks in advance > > > > > auditdistd:*:78:77:Auditdistd unprivileged user:/var/empty:/usr/sbin/nologin > > Just copy this line and paste it using vipw. Gary, You have given already known information; can you guve some background, for example for what the user is used for? thx matthias -- Matthias Apitz t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e - w http://www.unixarea.de/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: head && auditdistd
On Tue, May 14, 2013 at 10:24:52AM +0200, Matthias Apitz wrote: > El día Tuesday, May 14, 2013 a las 10:05:59AM +0200, Gary Jennejohn escribió: > > > > 2013/5/14 Matthias Apitz > > > > > > > > > > > # pw useradd -n auditdistd -g audit -c "Auditdistd unprivileged user" -d > > > > /var/empty -s /usr/sbin/nologin > > > > > > > > Can someone bring a bit light into this? Thanks in advance > > > > > > > > auditdistd:*:78:77:Auditdistd unprivileged user:/var/empty:/usr/sbin/nologin > > > > Just copy this line and paste it using vipw. > > Gary, > You have given already known information; can you guve some background, > for example for what the user is used for? thx > https://wiki.freebsd.org/auditdistd pgplB87AweXCe.pgp Description: PGP signature
Re: 9.1 -> current migration problem
-- Eir Nym
On 12 May 2013 19:48, Paul Dokas wrote:
> Thanks Dan! I was hoping that this would be something simple like this.
> The entry in UPDATING that you are referring to is:
>
> 20130121:
> Due to the use of the new -l option to install(1) during build
> and install, you must take care not to directly set the INSTALL
> make variable in your /etc/make.conf, /etc/src.conf, or on the
> command line. If you with to use the -C flag for all installs
> you may be able to add INSTALL+=-C to /etc/make.conf or
> /etc/src.conf.
>
> And I was setting INSTALL in /etc/make.conf
>
> INSTALL= install -C
>
> I've commented this out and am rebuilding again.
>
> Thanks again!
>
>
>
> Paul
>
I have this problem and I have no clues how to do this without setting
INSTALL http://www.freebsd.org/cgi/query-pr.cgi?pr=178547
>
>
> On 05/12/13 09:35, Dan Mack wrote:
>>
>> It's sound familiar; in /usr/src/UPDATING there is mention of this '-l'
>> issue. Search for 'install' in UPDATING and I think there is a
>> work-around.
>>
>> Dan
>>
>> On Sun, 12 May 2013, Paul Dokas wrote:
>>
>>> I have a newly installed 9.1 amd64 VM that I would like to update to
>>> -current. I have pulled down head via svn:
>>>
>>> svn co svn://svn.freebsd.org/base/head /usr/src
>>>
>>> and am attempting to buildworld:
>>>
>>> cd /usr/src
>>> make buildworld
>>>
>>> This build is failing during bootstrap-tools when building makewhatis or
>>> mklocale. It seems that something is trying to use the '-l' option to
>>> install, which is only present in FreeBSD 10.
>>>
>>> Any ideas how to get around this issue?
>>>
>>> Thanks,
>>>
>>> Paul
>>>
>>>
>>>
>>>
>>> # cd /usr/src
>>> # make buildworld
>>> .
>>> .
>>> .
>>> ===> bin/cat (obj,depend,all,install)
>>> /usr/obj/usr/src/tmp/usr/src/bin/cat created for /usr/src/bin/cat
>>> rm -f .depend
>>> mkdep -f .depend -a-I/usr/obj/usr/src/tmp/legacy/usr/include
>>> -std=gnu99 /usr/src/bin/cat/cat.c
>>> echo cat: /usr/lib/libc.a /usr/obj/usr/src/tmp/legacy/usr/lib/libegacy.a
> .depend
>>> cc -O2 -fno-strict-aliasing -pipe -std=gnu99
>>> -I/usr/obj/usr/src/tmp/legacy/usr/include -c /usr/src/bin/cat/cat.c
>>> ${CTFCONVERT_CMD} expands to empty string
>>> cc -O2 -fno-strict-aliasing -pipe -std=gnu99
>>> -I/usr/obj/usr/src/tmp/legacy/usr/include -static
>>> -L/usr/obj/usr/src/tmp/legacy/usr/lib -o cat cat.o -legacy
>>> install -C -s -o root -g wheel -m 555 cat
>>> /usr/obj/usr/src/tmp/legacy/bin/cat
>>> ===> usr.bin/lorder (obj,depend,all,install)
>>> /usr/obj/usr/src/tmp/usr/src/usr.bin/lorder created for
>>> /usr/src/usr.bin/lorder
>>> install -C -o root -g wheel -m 555 /usr/src/usr.bin/lorder/lorder.sh
>>> /usr/obj/usr/src/tmp/legacy/usr/bin/lorder
>>> ===> usr.bin/makewhatis (obj,depend,all,install)
>>> /usr/obj/usr/src/tmp/usr/src/usr.bin/makewhatis created for
>>> /usr/src/usr.bin/makewhatis
>>> rm -f .depend
>>> mkdep -f .depend -a-I/usr/obj/usr/src/tmp/legacy/usr/include
>>> -std=gnu99 /usr/src/usr.bin/makewhatis/makewhatis.c
>>> echo makewhatis: /usr/lib/libc.a /usr/lib/libz.a
>>> /usr/obj/usr/src/tmp/legacy/usr/lib/libegacy.a >> .depend
>>> cc -O2 -fno-strict-aliasing -pipe -std=gnu99
>>> -I/usr/obj/usr/src/tmp/legacy/usr/include -c
>>> /usr/src/usr.bin/makewhatis/makewhatis.c
>>> ${CTFCONVERT_CMD} expands to empty string
>>> cc -O2 -fno-strict-aliasing -pipe -std=gnu99
>>> -I/usr/obj/usr/src/tmp/legacy/usr/include -static
>>> -L/usr/obj/usr/src/tmp/legacy/usr/lib -o makewhatis makewhatis.o -lz
>>> -legacy
>>> install -C -s -o root -g wheel -m 555 makewhatis
>>> /usr/obj/usr/src/tmp/legacy/usr/bin/makewhatis
>>> install -C -o root -g wheel -m 555
>>> /usr/src/usr.bin/makewhatis/makewhatis.local.sh
>>> /usr/obj/usr/src/tmp/legacy/usr/libexec/makewhatis.local
>>> /usr/obj/usr/src/tmp/legacy/usr/libexec/catman.local ->
>>> /usr/obj/usr/src/tmp/legacy/usr/libexec/makewhatis.local
>>> install: illegal option -- l
>>> usage: install [-bCcMpSsv] [-B suffix] [-f flags] [-g group] [-m mode]
>>> [-o owner] file1 file2
>>> install [-bCcMpSsv] [-B suffix] [-f flags] [-g group] [-m mode]
>>> [-o owner] file1 ... fileN directory
>>> install -d [-v] [-g group] [-m mode] [-o owner] directory ...
>>> *** [_installlinks] Error code 64
>>>
>>> Stop in /usr/src/usr.bin/makewhatis.
>>> *** [bootstrap-tools] Error code 1
>>>
>>> Stop in /usr/src.
>>> *** [_bootstrap-tools] Error code 1
>>>
>>> Stop in /usr/src.
>>> *** [buildworld] Error code 1
>>>
>>> Stop in /usr/src.
>>>
>>>
>>> --
>>> Paul Dokas dokas at dokas.name
>>> ==
>>> Don Juan Matus: "an enigma wrapped in mystery wrapped in a tortilla."
>>> ___
>>> freebsd-current@freebsd.org mailing list
>>> http://lists.freebsd.org/mailman/listinfo/freebsd-current
>>> To unsubscribe, send any mail to
Re: files disappearing from ls on NFS
Hartmut Brandt wrote: > On Mon, 13 May 2013, Rick Macklem wrote: > > RM>Hartmut Brandt wrote: > RM>> On Sun, 12 May 2013, Rick Macklem wrote: > RM>> > RM>> RM>Hartmut Brandt wrote: > RM>> RM>> Hi, > RM>> RM>> > RM>> RM>> I've updated one of my -current machines this week (previous > RM>> update > RM>> RM>> was in > RM>> RM>> february). Now I see a strange effect (it seems only on NFS > RM>> mounts): > RM>> RM>> ls or > RM>> RM>> even echo * will list only some files (strange enough the > first > RM>> files > RM>> RM>> from > RM>> RM>> the normal, alphabetically ordered list). If I change > something > RM>> in the > RM>> RM>> directory (delete a file or create a new one) for some time > the > RM>> RM>> complete > RM>> RM>> listing will appear but after sime time (seconds to a minute > or > RM>> so) > RM>> RM>> again > RM>> RM>> only part of the files is listed. > RM>> RM>> > RM>> RM>> A ktrace on ls /usr/src/lib/libc/gen shows that > getdirentries is > RM>> RM>> called > RM>> RM>> only once (returning 4096). For a full listing getdirentries > is > RM>> called > RM>> RM>> 5 > RM>> RM>> times with the last returning 0. > RM>> RM>> > RM>> RM>> I can still open files that are not listed if I know their > name, > RM>> RM>> though. > RM>> RM>> > RM>> RM>> The NFS server is a Windows 2008 server with an OpenText NFS > RM>> Server > RM>> RM>> which > RM>> RM>> works without problems to all the other FreeBSD machines. > RM>> RM>> > RM>> RM>> So what could that be? > RM>> RM>> > RM>> RM>I've attached a patch that might be worth trying. It is a > "shot in > RM>> the dark", > RM>> RM>but brings the new NFS client's readdir closer to the old one > RM>> (which you > RM>> RM>mentioned still works ok). > RM>> RM> > RM>> RM>Please let me know how it goes, if you have a chance to test > it, > RM>> rick > RM>> > RM>> Hi Rick, > RM>> > RM>> the patch doesn't help. > RM>> > RM>> I wrote a small test program, which opens a directory, calls > RM>> getdents(2) > RM>> in a loop and dumps that. I figured out, that the return of the > system > RM>> call depends on the buffer size I pass to it. The directory has a > RM>> block > RM>> size of 4k according to fstat(2). If I use that, I get some 300 > of the > RM>> almost 500 directory entries. If I use 8k, I get just around 200 > and > RM>> if I > RM>> use 16k I get a handfull. If I dump the buffer in this case I see > RM>> 0x200 > RM>> bytes filled with directory entries, then a lot of zeros and > starting > RM>> from > RM>> 0x1000 again data. This is of course ignored because of the zeros > RM>> before. > RM>> > RM>And for this case getdents(2) returned 16K? It is normal for > getdents(2) > RM>to return less than requested and when end of dir occurs, it should > return 0. > RM> > RM>But if it returns 16K, there shouldn't be zeroed space in the > middle of > RM>it. > RM> > RM>And this always occurs or only after you wait a while? (You noted > in the > RM>above description that it would be ok for a little while after a > directory > RM>change and then would break, which suggests some kind of caching > problem.) > > Today in the morning everything was fine. After waiting 5 minutes, > again > only partial directories. When I do a read with 8k buffer size, > getdents(2) returns 8k, but starting from 0x200 until 0x1000 the > buffer is > filled with zeros. The entry just before the zeroes ends exactly at > 0x200 > (that would be the first byte of the next entry) and at 0x1000 a new > entry > starts. The rest of the buffer is fine. The next read returns only 4k > and > seems to be fine - altough it contains some junk non-zero bytes in the > padding. > Directory entries should never cross DIRBLKSIZ boundaries (512 or 0x200), so it makes sense that one ends at 0x200 and one starts at 0x1000. What doesn't make sense are the 0 bytes in between. One difference between the old and new NFS clients, which the patch I sent you changed to the way the old one does it, is filling in the last block. The old NFS client just leaves the block short and depends on n_direofoffset to recognize it is the last block with b_resid indicating where it ends. For the new client (unless you've applied the patch I emailed you), it fills the rest of the last block in with "empty directories". This was in the OpenBSD code when I did the original NFSv4 stuff and port. I left it in, because I thought it might avoid problems if n_direofoffset was ever bogus. That is why there might be "different junk" at the end of the directory, but it shouldn't matter. It almost sounds like something else is bzero()ing out part of the buffer cache block. Unless the directory has changed, the getdents() after 5 minutes would just return the same buffer cache block that was read in 5 minutes earlier (unless the buffer fell out of the cache and had to be re-read from the server, which would only happen if there was a lot of other file I/O going on during that 5minutes). A couple of comments: - You can run "nfsstat -m" as root to see wha
RE: files disappearing from ls on NFS
Hi Rick, sorry for top-posting - this is Outlook :-( Attached is the system configuration. I use this more or less unchanged since years. The machine is an 8-core AMD64 with 144GByte memory. The nfsstats -m output for the two file systems I'm testing with is: knopfs01:/OP_UserUnix on /home nfsv3,tcp,resvport,hard,cto,lockd,sec=sys,acdirmin=3,acdirmax=60,acregmin=5,acregmax=60,nametimeo=60,negnametimeo=60,rsize=65536,wsize=65536,readdirsize=65536,readahead=1,wcommitsize=6126856,timeout=120,retrans=2 knopfs01:/op_software on /software nfsv3,tcp,resvport,hard,cto,lockd,sec=sys,acdirmin=3,acdirmax=60,acregmin=5,acregmax=60,nametimeo=60,negnametimeo=60,rsize=65536,wsize=65536,readdirsize=65536,readahead=1,wcommitsize=6126856,timeout=120,retrans=2 I did the tcpdump/wireshark thing and I'm puzzled that I see no readdir requests. I see a lookup, followed by getattr, access and fsstat for the directory and that's it. Looks that even after hours the stuff returned by getdirents(2) comes from the cache. I assume that the NFS client uses getattr to check whether the directory has changed? If I knew what happens when calling getdirents() I could add some debugging printfs() here and there to figure out... harti -Original Message- From: Rick Macklem [mailto:rmack...@uoguelph.ca] Sent: Tuesday, May 14, 2013 2:50 PM To: Brandt, Hartmut Cc: curr...@freebsd.org Subject: Re: files disappearing from ls on NFS Hartmut Brandt wrote: > On Mon, 13 May 2013, Rick Macklem wrote: > > RM>Hartmut Brandt wrote: > RM>> On Sun, 12 May 2013, Rick Macklem wrote: > RM>> > RM>> RM>Hartmut Brandt wrote: > RM>> RM>> Hi, > RM>> RM>> > RM>> RM>> I've updated one of my -current machines this week (previous > RM>> update > RM>> RM>> was in > RM>> RM>> february). Now I see a strange effect (it seems only on NFS > RM>> mounts): > RM>> RM>> ls or > RM>> RM>> even echo * will list only some files (strange enough the > first > RM>> files > RM>> RM>> from > RM>> RM>> the normal, alphabetically ordered list). If I change > something > RM>> in the > RM>> RM>> directory (delete a file or create a new one) for some time > the > RM>> RM>> complete > RM>> RM>> listing will appear but after sime time (seconds to a minute > or > RM>> so) > RM>> RM>> again > RM>> RM>> only part of the files is listed. > RM>> RM>> > RM>> RM>> A ktrace on ls /usr/src/lib/libc/gen shows that > getdirentries is > RM>> RM>> called > RM>> RM>> only once (returning 4096). For a full listing getdirentries > is > RM>> called > RM>> RM>> 5 > RM>> RM>> times with the last returning 0. > RM>> RM>> > RM>> RM>> I can still open files that are not listed if I know their > name, > RM>> RM>> though. > RM>> RM>> > RM>> RM>> The NFS server is a Windows 2008 server with an OpenText NFS > RM>> Server > RM>> RM>> which > RM>> RM>> works without problems to all the other FreeBSD machines. > RM>> RM>> > RM>> RM>> So what could that be? > RM>> RM>> > RM>> RM>I've attached a patch that might be worth trying. It is a > "shot in > RM>> the dark", > RM>> RM>but brings the new NFS client's readdir closer to the old one > RM>> (which you > RM>> RM>mentioned still works ok). > RM>> RM> > RM>> RM>Please let me know how it goes, if you have a chance to test > it, > RM>> rick > RM>> > RM>> Hi Rick, > RM>> > RM>> the patch doesn't help. > RM>> > RM>> I wrote a small test program, which opens a directory, calls > RM>> getdents(2) > RM>> in a loop and dumps that. I figured out, that the return of the > system > RM>> call depends on the buffer size I pass to it. The directory has a > RM>> block size of 4k according to fstat(2). If I use that, I get some > RM>> 300 > of the > RM>> almost 500 directory entries. If I use 8k, I get just around 200 > and > RM>> if I > RM>> use 16k I get a handfull. If I dump the buffer in this case I see > RM>> 0x200 > RM>> bytes filled with directory entries, then a lot of zeros and > starting > RM>> from > RM>> 0x1000 again data. This is of course ignored because of the zeros > RM>> before. > RM>> > RM>And for this case getdents(2) returned 16K? It is normal for > getdents(2) > RM>to return less than requested and when end of dir occurs, it should > return 0. > RM> > RM>But if it returns 16K, there shouldn't be zeroed space in the > middle of > RM>it. > RM> > RM>And this always occurs or only after you wait a while? (You noted > in the > RM>above description that it would be ok for a little while after a > directory > RM>change and then would break, which suggests some kind of caching > problem.) > > Today in the morning everything was fine. After waiting 5 minutes, > again only partial directories. When I do a read with 8k buffer size, > getdents(2) returns 8k, but starting from 0x200 until 0x1000 the > buffer is filled with zeros. The entry just before the zeroes ends > exactly at > 0x200 > (that would be the first byte of the next entry) and at 0x1000 a new > entry starts. The rest of the buffer is fine. The next read returns > only 4k and seems to be
[head tinderbox] failure on arm/arm
TB --- 2013-05-14 12:50:18 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-05-14 12:50:18 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-05-14 12:50:18 - starting HEAD tinderbox run for arm/arm TB --- 2013-05-14 12:50:18 - cleaning the object tree TB --- 2013-05-14 12:50:18 - /usr/local/bin/svn stat /src TB --- 2013-05-14 12:50:23 - At svn revision 250635 TB --- 2013-05-14 12:50:24 - building world TB --- 2013-05-14 12:50:24 - CROSS_BUILD_TESTING=YES TB --- 2013-05-14 12:50:24 - MAKEOBJDIRPREFIX=/obj TB --- 2013-05-14 12:50:24 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-05-14 12:50:24 - SRCCONF=/dev/null TB --- 2013-05-14 12:50:24 - TARGET=arm TB --- 2013-05-14 12:50:24 - TARGET_ARCH=arm TB --- 2013-05-14 12:50:24 - TZ=UTC TB --- 2013-05-14 12:50:24 - __MAKE_CONF=/dev/null TB --- 2013-05-14 12:50:24 - cd /src TB --- 2013-05-14 12:50:24 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Tue May 14 12:50:28 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools [...] c++ -O2 -pipe -I/src/lib/clang/libllvmscalaropts/../../../contrib/llvm/include -I/src/lib/clang/libllvmscalaropts/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libllvmscalaropts/../../../contrib/llvm/lib/Transforms/Scalar -I. -I/src/lib/clang/libllvmscalaropts/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\"arm-unknown-freebsd10.0\" -DLLVM_HOSTTRIPLE=\"x86_64-unknown-freebsd10.0\" -DDEFAULT_SYSROOT=\"/obj/arm.arm/src/tmp\" -I/obj/arm.arm/src/tmp/legacy/usr/include -fno-exceptions -fno-rtti -c /src/lib/clang/libllvmscalaropts/../../../contrib/llvm/lib/Transforms/Scalar/Reassociate.cpp -o Reassociate.o c++ -O2 -pipe -I/src/lib/clang/libllvmscalaropts/../../../contrib/llvm/include -I/src/lib/clang/libllvmscalaropts/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libllvmscalaropts/../../../contrib/llvm/lib/Transforms/Scalar -I. -I/src/lib/clang/libllvmscalaropts/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\"arm-unknown-freebsd10.0\" -DLLVM_HOSTTRIPLE=\"x86_64-unknown-freebsd10.0\" -DDEFAULT_SYSROOT=\"/obj/arm.arm/src/tmp\" -I/obj/arm.arm/src/tmp/legacy/usr/include -fno-exceptions -fno-rtti -c /src/lib/clang/libllvmscalaropts/../../../contrib/llvm/lib/Transforms/Scalar/Reg2Mem.cpp -o Reg2Mem.o c++ -O2 -pipe -I/src/lib/clang/libllvmscalaropts/../../../contrib/llvm/include -I/src/lib/clang/libllvmscalaropts/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libllvmscalaropts/../../../contrib/llvm/lib/Transforms/Scalar -I. -I/src/lib/clang/libllvmscalaropts/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\"arm-unknown-freebsd10.0\" -DLLVM_HOSTTRIPLE=\"x86_64-unknown-freebsd10.0\" -DDEFAULT_SYSROOT=\"/obj/arm.arm/src/tmp\" -I/obj/arm.arm/src/tmp/legacy/usr/include -fno-exceptions -fno-rtti -c /src/lib/clang/libllvmscalaropts/../../../contrib/llvm/lib/Transforms/Scalar/SCCP.cpp -o SCCP.o /src/lib/clang/libllvmscalaropts/../../../contrib/llvm/lib/Transforms/Scalar/SCCP.cpp: In destructor '::SCCPSolver::~SCCPSolver()': /src/lib/clang/libllvmscalaropts/../../../contrib/llvm/lib/Transforms/Scalar/SCCP.cpp:155: internal compiler error: in var_ann, at tree-flow-inline.h:128 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. *** [SCCP.o] Error code 1 Stop in /src/lib/clang/libllvmscalaropts. *** [all] Error code 1 Stop in /src/lib/clang. *** [cross-tools] Error code 1 Stop in /src. *** [_cross-tools] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-05-14 13:43:41 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-05-14 13:43:41 - ERROR: failed to build world TB --- 2013-05-14 13:43:41 - 2872.23 user 261.99 system 3202.62 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-arm-arm.full ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: head && auditdistd
You should run 'mergemaster -p' before installworld, as that would add any necessary new users to the file. - Justin On May 13, 2013 11:48 PM, "Matthias Apitz" wrote: > > Hello, > > Today morning I wanted to make and install a fresh /head to an USB key > for further distribution the usual way: > > ... > # make installworld DESTDIR=/mnt > # make installkernel DESTDIR=/mnt KERNCONF=GENERIC INSTALL_NODEBUG=t > # make distrib-dirs DESTDIR=/mnt > # make distribution DESTDIR=/mnt > > 'installworld' instructed me about the missing user 'auditdistd'; I have > read what src/UPDATING says, but can't find any pointer to the man page > of auditdistd(8) or in our handbook; with Don Google I got to know that I > have to add this with something like > > # pw useradd -n auditdistd -g audit -c "Auditdistd unprivileged user" -d > /var/empty -s /usr/sbin/nologin > > Can someone bring a bit light into this? Thanks in advance > > matthias > > -- > Sent from my FreeBSD netbook > > Matthias Apitz | - No system with backdoors like > Apple/Android > E-mail: g...@unixarea.de | - Never being an iSlave > WWW: http://www.unixarea.de/ | - No proprietary attachments, no HTML/RTF > in E-mail > phone: +49-170-4527211 | - Respect for open standards > ___ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: head && auditdistd
That's a pretty anti-user design, when such information is pretty obscure and spread in Updating and wiki. You can have buildbox, which just builds worlds and install it not to self-host system, but instead to some image / or to other disk. And in one day all just stops working, and ask you to run mergemaster or manually add new user (Exactly was my case when this fresh user appeared) . Hm, even actually not asking, but simply failing with some message. If this is pretty obvious, why not insert adding this user into Makefile, with prompting if user actually wants to add it. That was my point, not the way of adding user itself. 2013/5/14 Justin Hibbits > You should run 'mergemaster -p' before installworld, as that would add any > necessary new users to the file. > > - Justin > On May 13, 2013 11:48 PM, "Matthias Apitz" wrote: > > > > > Hello, > > > > Today morning I wanted to make and install a fresh /head to an USB key > > for further distribution the usual way: > > > > ... > > # make installworld DESTDIR=/mnt > > # make installkernel DESTDIR=/mnt KERNCONF=GENERIC INSTALL_NODEBUG=t > > # make distrib-dirs DESTDIR=/mnt > > # make distribution DESTDIR=/mnt > > > > 'installworld' instructed me about the missing user 'auditdistd'; I have > > read what src/UPDATING says, but can't find any pointer to the man page > > of auditdistd(8) or in our handbook; with Don Google I got to know that I > > have to add this with something like > > > > # pw useradd -n auditdistd -g audit -c "Auditdistd unprivileged user" -d > > /var/empty -s /usr/sbin/nologin > > > > Can someone bring a bit light into this? Thanks in advance > > > > matthias > > > > -- > > Sent from my FreeBSD netbook > > > > Matthias Apitz | - No system with backdoors like > > Apple/Android > > E-mail: g...@unixarea.de | - Never being an iSlave > > WWW: http://www.unixarea.de/ | - No proprietary attachments, no > HTML/RTF > > in E-mail > > phone: +49-170-4527211 | - Respect for open standards > > ___ > > freebsd-current@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to " > freebsd-current-unsubscr...@freebsd.org" > > > ___ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > -- Regards, Alexander Yerenkow ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: head && auditdistd
It is recommended to run mergemaster -p prior to all installworld. - Justin On May 14, 2013 7:35 AM, "Alexander Yerenkow" wrote: > That's a pretty anti-user design, when such information is pretty obscure > and spread in Updating and wiki. > You can have buildbox, which just builds worlds and install it not to > self-host system, but instead to some image / or to other disk. > And in one day all just stops working, and ask you to run mergemaster or > manually add new user (Exactly was my case when this fresh user appeared) . > Hm, even actually not asking, but simply failing with some message. > If this is pretty obvious, why not insert adding this user into Makefile, > with prompting if user actually wants to add it. > That was my point, not the way of adding user itself. > > > > 2013/5/14 Justin Hibbits > >> You should run 'mergemaster -p' before installworld, as that would add any >> necessary new users to the file. >> >> - Justin >> On May 13, 2013 11:48 PM, "Matthias Apitz" wrote: >> >> > >> > Hello, >> > >> > Today morning I wanted to make and install a fresh /head to an USB key >> > for further distribution the usual way: >> > >> > ... >> > # make installworld DESTDIR=/mnt >> > # make installkernel DESTDIR=/mnt KERNCONF=GENERIC INSTALL_NODEBUG=t >> > # make distrib-dirs DESTDIR=/mnt >> > # make distribution DESTDIR=/mnt >> > >> > 'installworld' instructed me about the missing user 'auditdistd'; I have >> > read what src/UPDATING says, but can't find any pointer to the man page >> > of auditdistd(8) or in our handbook; with Don Google I got to know that >> I >> > have to add this with something like >> > >> > # pw useradd -n auditdistd -g audit -c "Auditdistd unprivileged user" -d >> > /var/empty -s /usr/sbin/nologin >> > >> > Can someone bring a bit light into this? Thanks in advance >> > >> > matthias >> > >> > -- >> > Sent from my FreeBSD netbook >> > >> > Matthias Apitz | - No system with backdoors like >> > Apple/Android >> > E-mail: g...@unixarea.de | - Never being an iSlave >> > WWW: http://www.unixarea.de/ | - No proprietary attachments, no >> HTML/RTF >> > in E-mail >> > phone: +49-170-4527211 | - Respect for open standards >> > ___ >> > freebsd-current@freebsd.org mailing list >> > http://lists.freebsd.org/mailman/listinfo/freebsd-current >> > To unsubscribe, send any mail to " >> freebsd-current-unsubscr...@freebsd.org" >> > >> ___ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org >> " >> > > > > -- > Regards, > Alexander Yerenkow > ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: head && auditdistd
On May 14, 2013, at 8:47 AM, Matthias Apitz wrote: > > Hello, > > Today morning I wanted to make and install a fresh /head to an USB key > for further distribution the usual way: > > ... > # make installworld DESTDIR=/mnt > # make installkernel DESTDIR=/mnt KERNCONF=GENERIC INSTALL_NODEBUG=t > # make distrib-dirs DESTDIR=/mnt > # make distribution DESTDIR=/mnt > > 'installworld' instructed me about the missing user 'auditdistd'; I have > read what src/UPDATING says, but can't find any pointer to the man page > of auditdistd(8) or in our handbook; with Don Google I got to know that I > have to add this with something like > > # pw useradd -n auditdistd -g audit -c "Auditdistd unprivileged user" -d > /var/empty -s /usr/sbin/nologin > > Can someone bring a bit light into this? Thanks in advance > > matthias > > -- > Sent from my FreeBSD netbook A "mergemaster -p" run fixes the problem ;) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
RE: files disappearing from ls on NFS
Now I've also changed NFS_DIRBLKSIZ to 4k - no change. harti -Original Message- From: Rick Macklem [mailto:rmack...@uoguelph.ca] Sent: Tuesday, May 14, 2013 2:50 PM To: Brandt, Hartmut Cc: curr...@freebsd.org Subject: Re: files disappearing from ls on NFS Hartmut Brandt wrote: > On Mon, 13 May 2013, Rick Macklem wrote: > > RM>Hartmut Brandt wrote: > RM>> On Sun, 12 May 2013, Rick Macklem wrote: > RM>> > RM>> RM>Hartmut Brandt wrote: > RM>> RM>> Hi, > RM>> RM>> > RM>> RM>> I've updated one of my -current machines this week (previous > RM>> update > RM>> RM>> was in > RM>> RM>> february). Now I see a strange effect (it seems only on NFS > RM>> mounts): > RM>> RM>> ls or > RM>> RM>> even echo * will list only some files (strange enough the > first > RM>> files > RM>> RM>> from > RM>> RM>> the normal, alphabetically ordered list). If I change > something > RM>> in the > RM>> RM>> directory (delete a file or create a new one) for some time > the > RM>> RM>> complete > RM>> RM>> listing will appear but after sime time (seconds to a minute > or > RM>> so) > RM>> RM>> again > RM>> RM>> only part of the files is listed. > RM>> RM>> > RM>> RM>> A ktrace on ls /usr/src/lib/libc/gen shows that > getdirentries is > RM>> RM>> called > RM>> RM>> only once (returning 4096). For a full listing getdirentries > is > RM>> called > RM>> RM>> 5 > RM>> RM>> times with the last returning 0. > RM>> RM>> > RM>> RM>> I can still open files that are not listed if I know their > name, > RM>> RM>> though. > RM>> RM>> > RM>> RM>> The NFS server is a Windows 2008 server with an OpenText NFS > RM>> Server > RM>> RM>> which > RM>> RM>> works without problems to all the other FreeBSD machines. > RM>> RM>> > RM>> RM>> So what could that be? > RM>> RM>> > RM>> RM>I've attached a patch that might be worth trying. It is a > "shot in > RM>> the dark", > RM>> RM>but brings the new NFS client's readdir closer to the old one > RM>> (which you > RM>> RM>mentioned still works ok). > RM>> RM> > RM>> RM>Please let me know how it goes, if you have a chance to test > it, > RM>> rick > RM>> > RM>> Hi Rick, > RM>> > RM>> the patch doesn't help. > RM>> > RM>> I wrote a small test program, which opens a directory, calls > RM>> getdents(2) > RM>> in a loop and dumps that. I figured out, that the return of the > system > RM>> call depends on the buffer size I pass to it. The directory has a > RM>> block size of 4k according to fstat(2). If I use that, I get some > RM>> 300 > of the > RM>> almost 500 directory entries. If I use 8k, I get just around 200 > and > RM>> if I > RM>> use 16k I get a handfull. If I dump the buffer in this case I see > RM>> 0x200 > RM>> bytes filled with directory entries, then a lot of zeros and > starting > RM>> from > RM>> 0x1000 again data. This is of course ignored because of the zeros > RM>> before. > RM>> > RM>And for this case getdents(2) returned 16K? It is normal for > getdents(2) > RM>to return less than requested and when end of dir occurs, it should > return 0. > RM> > RM>But if it returns 16K, there shouldn't be zeroed space in the > middle of > RM>it. > RM> > RM>And this always occurs or only after you wait a while? (You noted > in the > RM>above description that it would be ok for a little while after a > directory > RM>change and then would break, which suggests some kind of caching > problem.) > > Today in the morning everything was fine. After waiting 5 minutes, > again only partial directories. When I do a read with 8k buffer size, > getdents(2) returns 8k, but starting from 0x200 until 0x1000 the > buffer is filled with zeros. The entry just before the zeroes ends > exactly at > 0x200 > (that would be the first byte of the next entry) and at 0x1000 a new > entry starts. The rest of the buffer is fine. The next read returns > only 4k and seems to be fine - altough it contains some junk non-zero > bytes in the padding. > Directory entries should never cross DIRBLKSIZ boundaries (512 or 0x200), so it makes sense that one ends at 0x200 and one starts at 0x1000. What doesn't make sense are the 0 bytes in between. One difference between the old and new NFS clients, which the patch I sent you changed to the way the old one does it, is filling in the last block. The old NFS client just leaves the block short and depends on n_direofoffset to recognize it is the last block with b_resid indicating where it ends. For the new client (unless you've applied the patch I emailed you), it fills the rest of the last block in with "empty directories". This was in the OpenBSD code when I did the original NFSv4 stuff and port. I left it in, because I thought it might avoid problems if n_direofoffset was ever bogus. That is why there might be "different junk" at the end of the directory, but it shouldn't matter. It almost sounds like something else is bzero()ing out part of the buffer cache block. Unless the directory has changed, the getdents() after 5 minutes would just return the same buffer cache
Re: FreeBSD-HEAD gets stuck on vnode operations
On 13/05/13 17:00, Konstantin Belousov wrote: > On Mon, May 13, 2013 at 04:33:04PM +0200, Roger Pau Monn? wrote: >> On 13/05/13 13:18, Roger Pau Monn? wrote: Thanks for taking a look, >> I would like to explain this a little bit more, the syncer process >> doesn't get blocked on the _mtx_trylock_flags_ call, it just continues >> looping forever in what seems to be an endless loop around >> mnt_vnode_next_active/ffs_sync. Also while in this state there is no >> noticeable disk activity, so I'm unsure of what is happening. > How many CPUs does your VM have ? 7 vCPUs, but I've also seen this issue with 4 and 16 vCPUs. > > The loop you describing means that other thread owns the vnode > interlock. Can you track what this thread does ? E.g. look at the > vp->v_interlock.mtx_lock, which is basically a pointer to the struct > thread owning the mutex, clear low bits as needed. Then you can > inspect the thread and get a backtrace. There are no other threads running, only syncer is running on CPU 1 (see ps in previous email). All other CPUs are idle, and as seen from the ps quite a lot of threads are blocked in vnode related operations, either "*Name Cac", "*vnode_fr" or "*vnode in". I've also attached the output of alllocks in the previous email. > > Does the loop you described stuck on the same vnode during the whole > lock-step time, or is the progress made, possibly slowly ? I'm not sure how to measure "progress", but indeed the syncer process is not locked, it is iterating over mnt_vnode_next_active. > > I suppose that your HEAD is recent. Last commit in my local repository is: Date: Tue, 7 May 2013 12:39:14 + Subject: [PATCH] By request, add an arrow from NetBSD-0.8 to FreeBSD-1.0. While here, add a few more NetBSD versions to the tree itself. Submitted by: Alan Barrett Submitted by: Thomas Klausner ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FreeBSD-HEAD gets stuck on vnode operations
On Tue, May 14, 2013 at 06:08:45PM +0200, Roger Pau Monn? wrote: > On 13/05/13 17:00, Konstantin Belousov wrote: > > On Mon, May 13, 2013 at 04:33:04PM +0200, Roger Pau Monn? wrote: > >> On 13/05/13 13:18, Roger Pau Monn? wrote: > > Thanks for taking a look, > > >> I would like to explain this a little bit more, the syncer process > >> doesn't get blocked on the _mtx_trylock_flags_ call, it just continues > >> looping forever in what seems to be an endless loop around > >> mnt_vnode_next_active/ffs_sync. Also while in this state there is no > >> noticeable disk activity, so I'm unsure of what is happening. > > How many CPUs does your VM have ? > > 7 vCPUs, but I've also seen this issue with 4 and 16 vCPUs. > > > > > The loop you describing means that other thread owns the vnode > > interlock. Can you track what this thread does ? E.g. look at the > > vp->v_interlock.mtx_lock, which is basically a pointer to the struct > > thread owning the mutex, clear low bits as needed. Then you can > > inspect the thread and get a backtrace. > > There are no other threads running, only syncer is running on CPU 1 (see > ps in previous email). All other CPUs are idle, and as seen from the ps > quite a lot of threads are blocked in vnode related operations, either > "*Name Cac", "*vnode_fr" or "*vnode in". I've also attached the output > of alllocks in the previous email. This is not useful. You need to look at the mutex which fails the trylock operation in the mnt_vnode_next_active(), see who owns it, and then 'unwind' the locking dependencies from there. I described the procedure above. > > > > > Does the loop you described stuck on the same vnode during the whole > > lock-step time, or is the progress made, possibly slowly ? > > I'm not sure how to measure "progress", but indeed the syncer process is > not locked, it is iterating over mnt_vnode_next_active. Progress means that iteration moves from vnode to vnode, instead of looping over the same vnode continuously. I did read what you said about system being un-stuck in some time, but I am asking about change of the iterator during the stuck time. > > > > > I suppose that your HEAD is recent. > > Last commit in my local repository is: > > Date: Tue, 7 May 2013 12:39:14 + > Subject: [PATCH] By request, add an arrow from NetBSD-0.8 to FreeBSD-1.0. > > While here, add a few more NetBSD versions to the tree itself. > > Submitted by: Alan Barrett > Submitted by: Thomas Klausner pgpCVICedCnSv.pgp Description: PGP signature
Re: head && auditdistd
El día Tuesday, May 14, 2013 a las 07:20:02AM -0700, Justin Hibbits escribió: > You should run 'mergemaster -p' before installworld, as that would add any > necessary new users to the file. I see no need to run 'mergemaster' if one installs world and kernel into an empty mount point (device). There is nothing to merge. matthias -- Matthias Apitz t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e - w http://www.unixarea.de/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: openjdk6 broken on current
Hi, On 05/13/13 14:20, Jung-uk Kim wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2013-05-11 05:25:41 -0400, O. Hartmann wrote: On Thu, 2013-05-09 at 17:16 -0500, Larry Rosenman wrote: On 2013-05-09 06:16, Damjan Jovanovic wrote: On Wed, May 8, 2013 at 8:52 PM, Larry Rosenman wrote: On 2013-05-08 13:37, Larry Rosenman wrote: On 2013-05-08 12:46, Larry Rosenman wrote: On 2013-05-08 12:00, Daniel Eischen wrote: On Wed, 8 May 2013, Daniel Eischen wrote: On Wed, 8 May 2013, Larry Rosenman wrote: Daniel Eischen wrote: On Wed, 8 May 2013, Larry Rosenman wrote: Can SOMEONE please look at this? I have a real need to get java back on my -CURRENT server soon. Did/can you try just backing out r249606? -- DE How can I generate a patch to do that? Go here: http://svnweb.freebsd.org/base/head/lib/libthr/thread/thr_sig.c?sortby=date&view=log then click on "Diff to previous 249606", then click on "Patch" at the top. You can try backing out each/all of the recent changes to thr_sig.c to see what the culprit is. You'll have to use "-R" to reverse the patch I believe. Or, if you have a checked out svn repo, you can always use svn to generate the patch: $ cd /path/to/svn/src $ svn diff -r249606:249605 # no need to use -R on this patch I've done this, and dealt with a chunk reject, and am recompiling the world. Will let you know if this fixes it.. Still fails. /bin/mkdir -p /usr/ports/java/openjdk6/work/build/bsd-amd64/classes/javax/management/remote/rmi rm -f /usr/ports/java/openjdk6/work/build/bsd-amd64/classes/javax/management/remote/rmi/RMIConnectionImpl_Stub.class /usr/ports/java/openjdk6/work/build/bsd-amd64/bin/java -Xmx896m -Xms128m -cp /usr/ports/java/openjdk6/work/build/bsd-amd64/classes sun.rmi.rmic.Main -classpath "/usr/ports/java/openjdk6/work/build/bsd-amd64/classes"\ -d /usr/ports/java/openjdk6/work/build/bsd-amd64/classes \ -v1.2 \ -keepgenerated \ javax.management.remote.rmi.RMIConnectionImpl /bin/mkdir -p /usr/ports/java/openjdk6/work/build/bsd-amd64/gensrc/javax/management/remote/rmi /bin/cp /usr/ports/java/openjdk6/work/build/bsd-amd64/classes/javax/management/remote/rmi/RMIConnectionImpl_Stub.java \ /usr/ports/java/openjdk6/work/build/bsd-amd64/gensrc/javax/management/remote/rmi /usr/ports/java/openjdk6/work/build/bsd-amd64/bin/java -Xmx896m -Xms128m -cp /usr/ports/java/openjdk6/work/build/bsd-amd64/classes sun.rmi.rmic.Main -classpath "/usr/ports/java/openjdk6/work/build/bsd-amd64/classes"\ -d /usr/ports/java/openjdk6/work/build/bsd-amd64/classes \ -iiop -v1.2 \ javax.management.remote.rmi.RMIConnectionImpl gmake[5]: *** [/usr/ports/java/openjdk6/work/build/bsd-amd64/classes/javax/management/remote/rmi/RMIConnectionImpl_Stub.class] Segmentation fault (core dumped) gmake[5]: *** Deleting file `/usr/ports/java/openjdk6/work/build/bsd-amd64/classes/javax/management/remote/rmi/RMIConnectionImpl_Stub.class' gmake[5]: Leaving directory `/usr/ports/java/openjdk6/work/jdk/make/com/sun/jmx' gmake[4]: *** [all] Error 1 gmake[4]: Leaving directory `/usr/ports/java/openjdk6/work/jdk/make/com/sun' gmake[3]: *** [all] Error 1 gmake[3]: Leaving directory `/usr/ports/java/openjdk6/work/jdk/make/com' gmake[2]: *** [all] Error 1 gmake[2]: Leaving directory `/usr/ports/java/openjdk6/work/jdk/make' gmake[1]: *** [jdk-build] Error 2 gmake[1]: Leaving directory `/usr/ports/java/openjdk6/work' gmake: *** [build_product_image] Error 2 *** [do-build] Error code 1 Stop in /usr/ports/java/openjdk6. *** [build] Error code 1 Stop in /usr/ports/java/openjdk6. ===>>> make failed for java/openjdk6 ===>>> Aborting update ===>>> Killing background jobs Terminated ===>>> You can restart from the point of failure with this command line: portmaster java/openjdk6 ===>>> Exiting # # I **CAN** give SSH/SUDO access to whoever. (gdb) bt #0 0x000801e2da93 in JVM_handle_bsd_signal () from /usr/ports/java/openjdk6/work/build/bsd-amd64/lib/amd64/server/libjvm.so #1 0x000800a49136 in swapcontext () from /lib/libthr.so.3 #2 0x000800a48d39 in sigaction () from /lib/libthr.so.3 #3 0x71d3 in ?? () #4 0x000800a48c20 in sigaction () from /lib/libthr.so.3 #5 0x000801ba9540 in Deoptimization::unpack_frames () from /usr/ports/java/openjdk6/work/build/bsd-amd64/lib/amd64/server/libjvm.so #6 0x000803869f7e in ?? () #7 0x7fbfa450 in ?? () #8 0x00080383b828 in ?? () #9 0x00080685e6e0 in ?? () #10 0x00080684f000 in ?? () #11 0x7fbfa4a0 in ?? () #12 0x7fbfa518 in ?? () #13 0x00080308f000 in ?? () #14 0x000806bac750 in ?? () #15 0x000803869eb9 in ?? () #16 0x in ?? () (gdb) That backtrace would probably be clearer if you got it from a debug build of OpenJDK. Also you could find the exact commit that broke it by doing a bisection-search in SVN like "git bisect" would do. Regards Damjan Jovanovic
Re: FreeBSD-HEAD gets stuck on vnode operations
On 14/05/13 18:31, Konstantin Belousov wrote: > On Tue, May 14, 2013 at 06:08:45PM +0200, Roger Pau Monn? wrote: >> On 13/05/13 17:00, Konstantin Belousov wrote: >>> On Mon, May 13, 2013 at 04:33:04PM +0200, Roger Pau Monn? wrote: On 13/05/13 13:18, Roger Pau Monn? wrote: >> >> Thanks for taking a look, >> I would like to explain this a little bit more, the syncer process doesn't get blocked on the _mtx_trylock_flags_ call, it just continues looping forever in what seems to be an endless loop around mnt_vnode_next_active/ffs_sync. Also while in this state there is no noticeable disk activity, so I'm unsure of what is happening. >>> How many CPUs does your VM have ? >> >> 7 vCPUs, but I've also seen this issue with 4 and 16 vCPUs. >> >>> >>> The loop you describing means that other thread owns the vnode >>> interlock. Can you track what this thread does ? E.g. look at the >>> vp->v_interlock.mtx_lock, which is basically a pointer to the struct >>> thread owning the mutex, clear low bits as needed. Then you can >>> inspect the thread and get a backtrace. >> >> There are no other threads running, only syncer is running on CPU 1 (see >> ps in previous email). All other CPUs are idle, and as seen from the ps >> quite a lot of threads are blocked in vnode related operations, either >> "*Name Cac", "*vnode_fr" or "*vnode in". I've also attached the output >> of alllocks in the previous email. > This is not useful. You need to look at the mutex which fails the > trylock operation in the mnt_vnode_next_active(), see who owns it, > and then 'unwind' the locking dependencies from there. Sorry, now I get it, let's see if I can find the locked vnodes and the thread that owns them... ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: head && auditdistd
There was talk, and I think work, to use a separate passwd file for installworld, I don't know how far that got, thought. - Justin On May 14, 2013 10:09 AM, "Matthias Apitz" wrote: > El día Tuesday, May 14, 2013 a las 07:20:02AM -0700, Justin Hibbits > escribió: > > > You should run 'mergemaster -p' before installworld, as that would add > any > > necessary new users to the file. > > I see no need to run 'mergemaster' if one installs world and kernel into > an empty mount point (device). There is nothing to merge. > > matthias > > -- > Matthias Apitz > t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 > e - w http://www.unixarea.de/ > ___ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
VAIO intel i7 Ivy Bridge ultrabook installation fail: Disks not found
Hello, as I am newly writing to these mailing lists, forgive my formal and content-relative mistakes. As it stands now, I would absolutely love installing some 10-CURRENT on my newly acquired SONY VAIO ultrabook. AFAIK powered by Ivy Bridge ULV, 1.9 - 2.3 GHz. It has an additional SATA 32 GB Samsung SSD and a regular 500 GB HDD. It comes with Win 8, cannot stand the Metro. (although Elan Touchscreen is nice). I installed world from my old-beater AMD box on a USB pen drive (i386). Now it loads the kernel, but won't let me mount any root file systems. Looks like the platter isn't detected at all. Is that a common problem with Ivy Bridge systems? Is it a deliberate chipset flaw by Intel as in *this low-end lappy is not allowed to run anything else than WIN* or can I do something about it? Forgive me for being at least a power user, but certainly no device driver developer. :(, all has its limits. Thank you so much. I'd jump for joy seeing this thing run BSD, preferably even from USB, as the turbo boost and the lowish power consumption are really cool. Don't rip my head off for untainted e-mail origin and somesuch. I'm a lazy bugger, my life circumstances aren't that great and most Importantly I Dont Have A 5 Million $$ Server Farm. Cheers. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: VAIO intel i7 Ivy Bridge ultrabook installation fail: Disks not found
On Tue, May 14, 2013 at 7:41 PM, Nicolas Alexander Scheibling wrote: > Hello, > > as I am newly writing to these mailing lists, forgive my formal and > content-relative mistakes. > > As it stands now, I would absolutely love installing some 10-CURRENT on > my newly acquired SONY VAIO ultrabook. AFAIK powered by Ivy Bridge ULV, > 1.9 - 2.3 GHz. It has an additional SATA 32 GB Samsung SSD and a > regular 500 GB HDD. It comes with Win 8, cannot stand the Metro. > (although Elan Touchscreen is nice). > > I installed world from my old-beater AMD box on a USB pen drive (i386). > Now it loads the kernel, but won't let me mount any root file systems. > Looks like the platter isn't detected at all. Is that a common problem > with Ivy Bridge systems? Is it a deliberate chipset flaw by Intel as in > *this low-end lappy is not allowed to run anything else than WIN* or > can I do something about it? Forgive me for being at least a power > user, but certainly no device driver developer. :(, all has its limits. > > Thank you so much. I'd jump for joy seeing this thing run BSD, > preferably even from USB, as the turbo boost and the lowish power > consumption are really cool. > > Don't rip my head off for untainted e-mail origin and somesuch. I'm a > lazy bugger, my life circumstances aren't that great and most > Importantly I Dont Have A 5 Million $$ Server Farm. Cheers. Just out of curiosity - have you tried playing with the BIOS settings for USB legacy mode - and for the SATA chipset mode? (If any, ofc.) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: VAIO intel i7 Ivy Bridge ultrabook installation fail: Disks not found
Nicolas Alexander Scheibling writes: > As it stands now, I would absolutely love installing some 10-CURRENT on > my newly acquired SONY VAIO ultrabook. AFAIK powered by Ivy Bridge ULV, > 1.9 - 2.3 GHz. It has an additional SATA 32 GB Samsung SSD and a > regular 500 GB HDD. It comes with Win 8, cannot stand the Metro. > (although Elan Touchscreen is nice). > > I installed world from my old-beater AMD box on a USB pen drive (i386). > Now it loads the kernel, but won't let me mount any root file systems. > Looks like the platter isn't detected at all. Is that a common problem > with Ivy Bridge systems? I have a Vaio Ultrabook with similar specs and am currently running 10-CURRENT on it. Please provide more details, such as what messages are you getting etc. Have you also tried a fresh install from a CD or USB stick? > Is it a deliberate chipset flaw by Intel as in *this low-end lappy is > not allowed to run anything else than WIN* or can I do something about > it? I wouldn't call an i7 low-end... ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: sysvshm: replace Giant with a local sx lock
On Tue, Apr 23, 2013 at 11:36:21PM +0200, Mateusz Guzik wrote: > On Tue, Apr 23, 2013 at 11:55:32PM +0300, Konstantin Belousov wrote: > > On Tue, Apr 23, 2013 at 10:38:23PM +0200, Mateusz Guzik wrote: > > > I would like to replace Giant with a local sx lock in sysvshm code. > > > Looked really straightforward so maybe I missed something. > > > > At very least, the shmget_existing() is no longer functional. > > The sx is owned around tsleep(), and thus a progress cannot be made > > by other thread, which needs the same sx lock. > > > > Use of the SHMSEG_REMOVED in the shmget_allocate_segment() does > > not make any sense in your patch, since sleeping malloc allocation > > owns sx and prevent other threads from finding the segment. > > > > I did not looked further. > > Thank you for review, I definitely skimmed too fast. > > Looks like this code has some bugs as it is already, e.g. kern_shmat > does not re-check for NULL p->p_vmspace->vm_shm after malloc. > So I produced 2 patches. First one is straightforward: remove shmrealloc as it is a no-op anyway: http://people.freebsd.org/~mjg/patches/sysvshm-remove-shmrealloc.patch Second one replaces Giant with sx lock and removes current support for allocations that dropped Giant. Unfortunately I didn't have any good ideas how to split this patch: http://people.freebsd.org/~mjg/patches/sysvshm-giant-sx2.patch Bugs in current support: - p->p_vmspace->vm_shm allocation race (2 threads) in shmat - vm_map_find can drop Giant, not taken into account in shmat - lack of clean up if vm_pager_allocate fails While it is possible to fix all these problems, I think sx lock that is not dropped is ok to use here and it simplifies the implementation. Is this acceptable? -- Mateusz Guzik ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Enhanced BIO_DELETE support & ZFS TRIM enabled by default in current
Hi guys I just wanted to let everyone know that as of r249921 TRIM on ZFS is enabled by default unless you explicitly disable it using vfs.zfs.trim.enabled in loader.conf. Delete support for CAM SCSI now includes supporting ATA TRIM on SCSI controllers as long as the controller supports ata_pass16 (one notable controller set which doesn't is areca). This means controllers such as mpt, which don't natively support SCSI UNMAP to ATA TRIM translation in FW, now gain BIO_DELETE support via ATA TRIM if your using SATA disks. The way the default delete_method is chosen has also changed from a try and fail methodology to query the device details via VPD and ATA IDENTIFY. Delete method choice in CAM SCSI has also changed to prefer ATA TRIM if available as testing has show that even those controllers that support UNMAP to TRIM translation it is up to 20% slower than using ATA TRIM via pass16. This can still be overridden using the kern.cam.da.X.delete_method. I'd really appreciate any feedback people have, even if that's just confirming your running with ZFS TRIM and haven't had any issues, as I'm looking to MFC to stable soon. FYI: We've been running it for over 9 months now on hundreds of machines without any real issues. Regards Steve This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmas...@multiplay.co.uk. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: files disappearing from ls on NFS
Hartmut Brandt wrote:
> Hi Rick,
>
> sorry for top-posting - this is Outlook :-(
>
> Attached is the system configuration. I use this more or less
> unchanged since years. The machine is an 8-core AMD64 with 144GByte
> memory.
>
> The nfsstats -m output for the two file systems I'm testing with is:
>
> knopfs01:/OP_UserUnix on /home
> nfsv3,tcp,resvport,hard,cto,lockd,sec=sys,acdirmin=3,acdirmax=60,acregmin=5,acregmax=60,nametimeo=60,negnametimeo=60,rsize=65536,wsize=65536,readdirsize=65536,readahead=1,wcommitsize=6126856,timeout=120,retrans=2
> knopfs01:/op_software on /software
> nfsv3,tcp,resvport,hard,cto,lockd,sec=sys,acdirmin=3,acdirmax=60,acregmin=5,acregmax=60,nametimeo=60,negnametimeo=60,rsize=65536,wsize=65536,readdirsize=65536,readahead=1,wcommitsize=6126856,timeout=120,retrans=2
>
> I did the tcpdump/wireshark thing and I'm puzzled that I see no
> readdir requests. I see a lookup, followed by getattr, access and
> fsstat for the directory and that's it. Looks that even after hours
> the stuff returned by getdirents(2) comes from the cache. I assume
> that the NFS client uses getattr to check whether
> the directory has changed? If I knew what happens when calling
> getdirents() I could add some debugging printfs() here and there to
> figure out...
>
Yes. The NFS client will check the mtime on the directory to see if it has
changed and just use whatever is in the buffer cache otherwise.
Well, getdents() basically just calls kern_getdirentries() and it calls
VOP_READDIR() { which is called nfs_readdir() in the NFS clients }.
nfs_readdir() calls ncl_bioread() to do the real work of finding the
buffer cache blocks and copying the data out of them.
One thing you might check via printf()s is whether the buffer cache
has the zero'd data in it before it copies it to userland.
Since you get valid data sometimes and partially zero'd out data others,
I haven't a clue what is going on. One other person reported a problem
when they used a small readdirsize, but it is hard to say they saw the
same thing and no one else seems to be seeing this, so I have no idea
what it might be.
I remember you started seeing this after an upgrade of current. Do you
happen to have dates (or rNN) for the old working verion vs the one that
broke this?
(All I can think to do is scan the commits that seem to somehow relate
to the buffer cache or copying to userland or ???)
rick
> harti
>
> -Original Message-
> From: Rick Macklem [mailto:rmack...@uoguelph.ca]
> Sent: Tuesday, May 14, 2013 2:50 PM
> To: Brandt, Hartmut
> Cc: curr...@freebsd.org
> Subject: Re: files disappearing from ls on NFS
>
> Hartmut Brandt wrote:
> > On Mon, 13 May 2013, Rick Macklem wrote:
> >
> > RM>Hartmut Brandt wrote:
> > RM>> On Sun, 12 May 2013, Rick Macklem wrote:
> > RM>>
> > RM>> RM>Hartmut Brandt wrote:
> > RM>> RM>> Hi,
> > RM>> RM>>
> > RM>> RM>> I've updated one of my -current machines this week
> > (previous
> > RM>> update
> > RM>> RM>> was in
> > RM>> RM>> february). Now I see a strange effect (it seems only on
> > NFS
> > RM>> mounts):
> > RM>> RM>> ls or
> > RM>> RM>> even echo * will list only some files (strange enough the
> > first
> > RM>> files
> > RM>> RM>> from
> > RM>> RM>> the normal, alphabetically ordered list). If I change
> > something
> > RM>> in the
> > RM>> RM>> directory (delete a file or create a new one) for some
> > time
> > the
> > RM>> RM>> complete
> > RM>> RM>> listing will appear but after sime time (seconds to a
> > minute
> > or
> > RM>> so)
> > RM>> RM>> again
> > RM>> RM>> only part of the files is listed.
> > RM>> RM>>
> > RM>> RM>> A ktrace on ls /usr/src/lib/libc/gen shows that
> > getdirentries is
> > RM>> RM>> called
> > RM>> RM>> only once (returning 4096). For a full listing
> > getdirentries
> > is
> > RM>> called
> > RM>> RM>> 5
> > RM>> RM>> times with the last returning 0.
> > RM>> RM>>
> > RM>> RM>> I can still open files that are not listed if I know their
> > name,
> > RM>> RM>> though.
> > RM>> RM>>
> > RM>> RM>> The NFS server is a Windows 2008 server with an OpenText
> > NFS
> > RM>> Server
> > RM>> RM>> which
> > RM>> RM>> works without problems to all the other FreeBSD machines.
> > RM>> RM>>
> > RM>> RM>> So what could that be?
> > RM>> RM>>
> > RM>> RM>I've attached a patch that might be worth trying. It is a
> > "shot in
> > RM>> the dark",
> > RM>> RM>but brings the new NFS client's readdir closer to the old
> > one
> > RM>> (which you
> > RM>> RM>mentioned still works ok).
> > RM>> RM>
> > RM>> RM>Please let me know how it goes, if you have a chance to test
> > it,
> > RM>> rick
> > RM>>
> > RM>> Hi Rick,
> > RM>>
> > RM>> the patch doesn't help.
> > RM>>
> > RM>> I wrote a small test program, which opens a directory, calls
> > RM>> getdents(2)
> > RM>> in a loop and dumps that. I figured out, that the return of the
> > system
> > RM>> call depends on the buffer size I pass to it. The directory has
> > a
> > RM>> block size of 4k according to fstat(2). If I use
Re: head && auditdistd
Matthias Apitz writes: > El día Tuesday, May 14, 2013 a las 07:20:02AM -0700, Justin Hibbits escribió: > >> You should run 'mergemaster -p' before installworld, as that would add any >> necessary new users to the file. > > I see no need to run 'mergemaster' if one installs world and kernel into > an empty mount point (device). There is nothing to merge. Fine, if that provides a sufficiently complete system for your needs. That must be a pretty unusual set of needs, though. I'm interested: what do you do with a system that is complete except for not including /etc? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
