|
|
|
|
|
|
| Author |
Message |
Andrew Reilly
*nix forums Guru Wannabe
Joined: 26 Apr 2002
Posts: 148
|
 Posted: Sun Jun 25, 2006 1:17 am Post subject:
What's up with our stdout?
|
|
|
Hi all,
My main "workstation" systems are both FreeBSD-STABLE, one an
i386 box (pentium3) and the other an amd64 (Athlon64-X2). My
diskless/experimental boxes mostly run NetBSD, and I'm currently
working my way up to trying different things, so I've been
trying to cross-compile NetBSD from my FreeBSD boxes, but
running into some problems that prevent it all from working.
(They're typically too puny to do native builds comfortably, but
that's how I've been running so-far.)
One interesting problem that I found yesterday was that NetBSD
have added a "-l" option to cat, which is supposed to apply an
exclusive advisory lock with fcntl to the the output file, and
wait until that succeeds:
http://netbsd.gw.com/cgi-bin/man-cgi?cat++NetBSD-current
That seems like a pretty useful idea,
because it means that you can have parallel make jobs all
contributing to a log file or the like (with cat -l >> foo.log),
without getting in eachothers' way.
However it doesn't work on FreeBSD. The nbcat that the NetBSD
cross build process makes stops with "nbcat: stdout: Operation
not supported".
OK, that's easy to work around, just remove the -l option from
the $(TOOL_CAT) calls in the NetBSD makefiles, and only run one
job...
The question is: what's wrong with our shell or stdout that a
program (nbcat in this case) can't fcntl-lock the file opened
for output? Is this related to the /dev/stdout@ -> fd/1 files
that we have? Seems like a shortcoming to me...
Cheers,
--
Andrew
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" |
|
| Back to top |
|
 |
Steve Kargl
*nix forums beginner
Joined: 03 May 2002
Posts: 41
|
| Posted: Sun Jun 25, 2006 1:31 am Post subject:
Re: What's up with our stdout?
|
|
|
On Sun, Jun 25, 2006 at 11:17:46AM +1000, Andrew Reilly wrote:
| Quote: |
The question is: what's wrong with our shell or stdout that a
program (nbcat in this case) can't fcntl-lock the file opened
for output? Is this related to the /dev/stdout@ -> fd/1 files
that we have? Seems like a shortcoming to me...
|
Have you reviewed the nbcat source code to determine
what wrong assumptions it is making about stdout and/or
fcntl?
--
Steve
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" |
|
| Back to top |
|
|
Andrew Reilly
*nix forums Guru Wannabe
Joined: 26 Apr 2002
Posts: 148
|
| Posted: Sun Jun 25, 2006 2:01 am Post subject:
Re: What's up with our stdout?
|
|
|
On Sat, Jun 24, 2006 at 06:31:10PM -0700, Steve Kargl wrote:
| Quote: | On Sun, Jun 25, 2006 at 11:17:46AM +1000, Andrew Reilly wrote:
The question is: what's wrong with our shell or stdout that a
program (nbcat in this case) can't fcntl-lock the file opened
for output? Is this related to the /dev/stdout@ -> fd/1 files
that we have? Seems like a shortcoming to me...
Have you reviewed the nbcat source code to determine
what wrong assumptions it is making about stdout and/or
fcntl?
|
What's to assume? The shell should make file descriptor 1 be
the output file, opened for writing or append, depending on
whether you used > or >> on the command line, no?
NetBSD's cat.c just says:
if (lflag) {
stdout_lock.l_len = 0;
stdout_lock.l_start = 0;
stdout_lock.l_type = F_WRLCK;
stdout_lock.l_whence = SEEK_SET;
if (fcntl(STDOUT_FILENO, F_SETLKW, &stdout_lock) == -1)
err(EXIT_FAILURE, "stdout");
}
Looks OK to me.
The file opened for stdout is definitely a normal file. F_SETLKW
should succeed or wait in this case, IMO.
Our stdout(4) doesn't say anything that looks ominous, but I
admit to being far from a guru on the issue. I don't even
understand how those /dev/fd devices interact with the system,
or why they're there (other than as a way to fake a "-" file
argument to programs that don't normally have one). I don't see
how they're relevant in this case though.
Cheers,
--
Andrew
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" |
|
| Back to top |
|
|
Bruce Evans
*nix forums Guru Wannabe
Joined: 22 Mar 2002
Posts: 190
|
| Posted: Sun Jun 25, 2006 3:10 pm Post subject:
Re: What's up with our stdout?
|
|
|
On Sun, 25 Jun 2006, Andrew Reilly wrote:
| Quote: | On Sat, Jun 24, 2006 at 06:31:10PM -0700, Steve Kargl wrote:
On Sun, Jun 25, 2006 at 11:17:46AM +1000, Andrew Reilly wrote:
The question is: what's wrong with our shell or stdout that a
program (nbcat in this case) can't fcntl-lock the file opened
for output? Is this related to the /dev/stdout@ -> fd/1 files
that we have? Seems like a shortcoming to me...
Have you reviewed the nbcat source code to determine
what wrong assumptions it is making about stdout and/or
fcntl?
What's to assume? The shell should make file descriptor 1 be
the output file, opened for writing or append, depending on
whether you used > or >> on the command line, no?
NetBSD's cat.c just says:
if (lflag) {
stdout_lock.l_len = 0;
stdout_lock.l_start = 0;
stdout_lock.l_type = F_WRLCK;
stdout_lock.l_whence = SEEK_SET;
if (fcntl(STDOUT_FILENO, F_SETLKW, &stdout_lock) == -1)
err(EXIT_FAILURE, "stdout");
}
Looks OK to me.
The file opened for stdout is definitely a normal file. F_SETLKW
should succeed or wait in this case, IMO.
Our stdout(4) doesn't say anything that looks ominous, but I
admit to being far from a guru on the issue. I don't even
understand how those /dev/fd devices interact with the system,
or why they're there (other than as a way to fake a "-" file
argument to programs that don't normally have one). I don't see
how they're relevant in this case though.
|
This doesn't seem to have anything to do with stdout. F_SETLKW just
seems to be broken on all regular files (and thus is unsupported for
all file types). The above works under the modified version of
FreeBSD-5.2 that I use, but it fails with the documented errno EOPNOTSUPP
under at least FreeBSD-6.0-STABLE. Replacing STDOUT_FILENO by fd =
open("foo", O_RDWR) gives the same failure. Replacing FSETLKW by
FSETLK or F_GETLK gives the same failure.
The errno for irregular files seems to be broken in different ways for
all cases, but the differences only depend on the file type, not on
the version of FreeBSD. At least for F_GETLK:
5.2+, 6.0 on tty input: fails with bogus undocumented error EINVAL
5.2+, 6.0 on pipe input: fails with bogus undocumented error EBADF
The Minix 1.6.25+ regression tests for F_*LK* detect the regression
but don't check for the bogus errnos. They start with simple checks
like the above and quit before getting to more complicated tests when
locking never works. I ran them only under FreeBSD_6.1=PRERELEASE.
Bruce
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" |
|
| Back to top |
|
|
Andrew Reilly
*nix forums Guru Wannabe
Joined: 26 Apr 2002
Posts: 148
|
| Posted: Sun Jun 25, 2006 9:36 pm Post subject:
Re: What's up with our stdout?
|
|
|
On Mon, Jun 26, 2006 at 01:10:38AM +1000, Bruce Evans wrote:
| Quote: | This doesn't seem to have anything to do with stdout. F_SETLKW just
seems to be broken on all regular files (and thus is unsupported for
all file types). The above works under the modified version of
FreeBSD-5.2 that I use, but it fails with the documented errno EOPNOTSUPP
under at least FreeBSD-6.0-STABLE. Replacing STDOUT_FILENO by fd =
open("foo", O_RDWR) gives the same failure. Replacing FSETLKW by
FSETLK or F_GETLK gives the same failure.
|
Thanks for the clarification.
Don't all of the databases rely on fcntl locks? How can this be
broken?
Cheers,
--
Andrew
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" |
|
| Back to top |
|
|
John-Mark Gurney
*nix forums addict
Joined: 16 Jun 2003
Posts: 89
|
| Posted: Sun Jun 25, 2006 9:40 pm Post subject:
Re: What's up with our stdout?
|
|
|
Andrew Reilly wrote this message on Sun, Jun 25, 2006 at 11:17 +1000:
| Quote: | One interesting problem that I found yesterday was that NetBSD
have added a "-l" option to cat, which is supposed to apply an
exclusive advisory lock with fcntl to the the output file, and
wait until that succeeds:
http://netbsd.gw.com/cgi-bin/man-cgi?cat++NetBSD-current
That seems like a pretty useful idea,
because it means that you can have parallel make jobs all
contributing to a log file or the like (with cat -l >> foo.log),
without getting in eachothers' way.
|
Why not use:
lockf -k foo.log cat >> foo.log
Should do the same thing...
--
John-Mark Gurney Voice: +1 415 225 5579
"All that I will do, has been done, All that I have, has not."
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" |
|
| Back to top |
|
|
Andrew Reilly
*nix forums Guru Wannabe
Joined: 26 Apr 2002
Posts: 148
|
| Posted: Mon Jun 26, 2006 4:07 am Post subject:
Re: What's up with our stdout?
|
|
|
On Sun, Jun 25, 2006 at 02:40:21PM -0700, John-Mark Gurney wrote:
| Quote: | Andrew Reilly wrote this message on Sun, Jun 25, 2006 at 11:17 +1000:
One interesting problem that I found yesterday was that NetBSD
have added a "-l" option to cat, which is supposed to apply an
exclusive advisory lock with fcntl to the the output file, and
wait until that succeeds:
http://netbsd.gw.com/cgi-bin/man-cgi?cat++NetBSD-current
That seems like a pretty useful idea,
because it means that you can have parallel make jobs all
contributing to a log file or the like (with cat -l >> foo.log),
without getting in eachothers' way.
Why not use:
lockf -k foo.log cat >> foo.log
Should do the same thing...
|
Not only should it, I've just checked and discovered that it
does. So I'll make up the appropriate tweak to NetBSD's
Makefiles, and suggest on the mailing lists that they think
about incorporating it, as it's ostensibly a more general and
useful way to do it.
This does make me wonder, though, why this _does_ work, given
Bruce's explanation of why the nbcat code doesn't...
Hmm. lockf.c uses open(...,|O_EXLOCK), rather than fcntl().
Any particular reason why that should behave differently?
Cheers,
--
Andrew
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" |
|
| Back to top |
|
|
Bruce Evans
*nix forums Guru Wannabe
Joined: 22 Mar 2002
Posts: 190
|
| Posted: Mon Jun 26, 2006 9:31 am Post subject:
Re: What's up with our stdout?
|
|
|
On Mon, 26 Jun 2006, Andrew Reilly wrote:
| Quote: | On Mon, Jun 26, 2006 at 01:10:38AM +1000, Bruce Evans wrote:
This doesn't seem to have anything to do with stdout. F_SETLKW just
seems to be broken on all regular files (and thus is unsupported for
all file types). The above works under the modified version of
FreeBSD-5.2 that I use, but it fails with the documented errno EOPNOTSUPP
under at least FreeBSD-6.0-STABLE. Replacing STDOUT_FILENO by fd =
open("foo", O_RDWR) gives the same failure. Replacing FSETLKW by
FSETLK or F_GETLK gives the same failure.
Thanks for the clarification.
Don't all of the databases rely on fcntl locks? How can this be
broken?
|
The problem seems to be that the file system really doesn't support
locking. On freefall, both fcntl(2) locking and flock(2) fail in my
home directory but work in /tmp. My home directory on freefall is
nfs-mounted without nolockd, and also without rpc.lockd or rpc.statd.
nfs without the rpc daemons really doesn't support remote locking, so
it is correct for it to fail, but rpc.lockd is buggy so it is often
not used. On my own machines I normally avoid nfs-locking using nolockd
(this gives locking that doesn't work (remotely) but claims to work).
On the FreeBSD cluster nfs-locking is apparently normally avoided by
nfs-mounting without nolockd and not starting the rpc daemons (this
gives locking that doesn't work and doesn't claim to work).
Configuring of locking for nfs is confusing and poorly documented.
Neither rpc.lockd nor rpc.statd gets started automatically when a file
system is nfs-mounted without nolockd. This wouldn't be easy to
automate, since the daemons must be started on both the clients and
servers. mount_nfs( doesn't say clearly which daemons must be started
where. rc.conf(5) says wrongly that rpc_lock_lockd and rpc_statd_enable
only apply to servers. Starting them both on clients and servers seems
to be needed. With a filesystem nfs-remounted without nolockd: there
seem to be ordering or timing requirements for starting them -- starting
them manually sometimes gave a useful error message for flock() attempts
when not all were started, but sometimes starting them all didn't stop
flock() from failing and other times gave a hung flock(). Killing and
restarting rpc.lockd on the client (while leaving the other daemons
running) usually worked to unhang flock() and make it work on the next
try.
A modified version of the NetBSD code to test both flock() and fcntl()
locking:
%%%
#include <fcntl.h>
#include <stdlib.h>
#include <unistd.h>
struct flock stdout_lock;
main()
{
if (flock(STDOUT_FILENO, LOCK_EX) == -1)
err(EXIT_FAILURE, "flock(...LOCK_EX): stdout");
warnx("flock(...LOCK_EX): succeeded");
if (flock(STDOUT_FILENO, LOCK_UN) == -1)
err(EXIT_FAILURE, "flock(...LOCK_UN): stdout");
warnx("flock(...LOCK_EX): succeeded");
stdout_lock.l_len = 0;
stdout_lock.l_start = 0;
stdout_lock.l_type = F_WRLCK;
stdout_lock.l_whence = SEEK_SET;
if (fcntl(STDOUT_FILENO, F_SETLKW, &stdout_lock) == -1)
err(EXIT_FAILURE, "fcntl(...F_SETLKW): stdout");
warnx("fcntl(...F_SETLKW): succeeded");
return (0);
}
%%%
The Minix regression tests showed too many other regressions. One was
that after mkdir()/open()/rmdir() of a directory, fstat() on the open
unlinked directory gave a wrong link count of 2. Another was that
after creation of a directory with LINK_MAX links, it was possible to
mkdir() another subdir in the directory, giving 1 more link than the
maxiumum possible:
drwxrwxrwx 32768 bde bde 1048576 Jun 25 16:42 DIR_28/foo/
This is a more serious bug, since ffs uses the test (i_nlink <= 0) in
a couple of places, and since i_nlink_t is int16_t, 32768 for a link
count is unrepresentable (it overflows to -32768). This seems to be
caused by either a race in soft updates or using i_nlink where
i_effnlink should be used. These bugs show up on an nfs-mounted
directory machines in the FreeBSD cluster. I think nfs doesn't affect
this, and the underlying file system is ffs2 with soft updates. Normally
I don't want to see bugs like this, and I use ffs1 without soft updates
on my own machines to avoid seeing new ones.
Bruce
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" |
|
| Back to top |
|
|
Bruce Evans
*nix forums Guru Wannabe
Joined: 22 Mar 2002
Posts: 190
|
| Posted: Mon Jun 26, 2006 9:46 am Post subject:
Re: What's up with our stdout?
|
|
|
On Mon, 26 Jun 2006, I wrote:
| Quote: | Configuring of locking for nfs is confusing and poorly documented.
Neither rpc.lockd nor rpc.statd gets started automatically when a file
system is nfs-mounted without nolockd. This wouldn't be easy to
automate, since the daemons must be started on both the clients and
servers. mount_nfs( doesn't say clearly which daemons must be started
where. rc.conf(5) says wrongly that rpc_lock_lockd and rpc_statd_enable
only apply to servers. Starting them both on clients and servers seems
to be needed. With a filesystem nfs-remounted without nolockd: there
seem to be ordering or timing requirements for starting them -- starting
them manually sometimes gave a useful error message for flock() attempts
when not all were started, but sometimes starting them all didn't stop
flock() from failing and other times gave a hung flock(). Killing and
restarting rpc.lockd on the client (while leaving the other daemons
running) usually worked to unhang flock() and make it work on the next
try.
|
I didn't actually find a usable configuration of nfs locking, since the
above left rpc.lockd taking 100% CPU on both the client and server.
This was with FreeBSD-~5.2. Some of the many bugs in rpc.lockd have been
fixed since 5.2.
Bruce
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" |
|
| Back to top |
|
|
John Baldwin
*nix forums Guru Wannabe
Joined: 27 Mar 2002
Posts: 278
|
| Posted: Mon Jun 26, 2006 12:44 pm Post subject:
Re: What's up with our stdout?
|
|
|
On Monday 26 June 2006 00:07, Andrew Reilly wrote:
| Quote: | On Sun, Jun 25, 2006 at 02:40:21PM -0700, John-Mark Gurney wrote:
Andrew Reilly wrote this message on Sun, Jun 25, 2006 at 11:17 +1000:
One interesting problem that I found yesterday was that NetBSD
have added a "-l" option to cat, which is supposed to apply an
exclusive advisory lock with fcntl to the the output file, and
wait until that succeeds:
http://netbsd.gw.com/cgi-bin/man-cgi?cat++NetBSD-current
That seems like a pretty useful idea,
because it means that you can have parallel make jobs all
contributing to a log file or the like (with cat -l >> foo.log),
without getting in eachothers' way.
Why not use:
lockf -k foo.log cat >> foo.log
Should do the same thing...
Not only should it, I've just checked and discovered that it
does. So I'll make up the appropriate tweak to NetBSD's
Makefiles, and suggest on the mailing lists that they think
about incorporating it, as it's ostensibly a more general and
useful way to do it.
This does make me wonder, though, why this _does_ work, given
Bruce's explanation of why the nbcat code doesn't...
Hmm. lockf.c uses open(...,|O_EXLOCK), rather than fcntl().
Any particular reason why that should behave differently?
|
I believe that's an 'flock()' rather than an 'fnctl()' range lock.
Are you doing your build over NFS btw?
--
John Baldwin
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" |
|
| Back to top |
|
|
Andrew Reilly
*nix forums Guru Wannabe
Joined: 26 Apr 2002
Posts: 148
|
| Posted: Mon Jun 26, 2006 11:09 pm Post subject:
Re: What's up with our stdout?
|
|
|
On Mon, Jun 26, 2006 at 08:44:07AM -0400, John Baldwin wrote:
| Quote: | Are you doing your build over NFS btw?
|
Aah, yes. Sorry for the noise, in that case. I should have
remembered that nfs locking was a bit iffy. I've been trying to
build both locally and remotely but running into problems for
various reasons, both ways. The "nbcat -l >> ${METALOG}" thing
actually works fine on local file systems, it seems. Got myself
confused, there.
Thanks for the insight, all.
Cheers,
--
Andrew
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" |
|
| Back to top |
|
|
Google
|
|
| Back to top |
|
|
|
|
The time now is Tue Dec 02, 2008 2:00 pm | All times are GMT
|
|
Mortgage Calculator | Credit Cards | Proxy | Cell Phones | Mortgage
|
|
Copyright © 2004-2005 DeniX Solutions SRL
|
|
|
|
Other DeniX Solutions sites:
Unix/Linux blog |
electronics forum |
medicine forum |
science forum |
|
|
Privacy Policy
|
Powered by phpBB © 2001, 2005 phpBB Group
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
Forum index
»
*nix
»
BSD
»
FreeBSD
»
mail-lists
»
Architecture
