Re: freeBSD8.2: getgrgid() works only for wheel group.
On 04/08/2011 Eygene wrote Rekhesh, good day. Wed, Aug 03, 2011 at 06:26:13PM +0530, Rekhesh Mohan wrote: I'm trying to install mailman on a freeBSD 8.2 box. Mailman allows only the apache-www group to run its CGI scripts and only the mail group can execute some of the mailing list related functionalities. Mailman is using getgrgid() to check the group name. This is failing on me. It appears that only the wheel group members are allowed to use getgrgid() on my machine. getgrgid() returns (null) for others. I was wondering if anyone else has faced this situation. What's the output from 'ls -l /etc/group; ls -ld /etc'? Eygene! You are the man :) /etc had 750 permissions. Thanks a lot. I was probably too busy looking inside /etc and never thought of looking up above the directory. Everything is working now. Thanks again.. --R ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Capsicum project: Ideas needed
I just stumbled upon this rather outdated thread... On Fri, 8 Jul 2011 15:09:52 +0400, Ilya Bakulin wrote: [...] wget curl links/lynx This is Ports software, we may try to modify it and even send patches to upstream, or maintain our local patches. I wanted to focus on base system components during GSoC, but it doesn't hurt to try to capsicumize these tools either. fetch(1) is similar to wget and curl and is part of the base system, so would this be a candidate? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
files that need sys/cdefs.h as a prerequisite
Can't they just #include sys/cdefs.h? Or am I missing something? I'll be happy to send a patch if that's an acceptable solution. sys/sys/linker_set.h:#error this file needs sys/cdefs.h as a prerequisite sys/sys/syslimits.h:#error this file needs sys/cdefs.h as a prerequisite sys/amd64/include/_types.h:#error this file needs sys/cdefs.h as a prerequisite sys/amd64/include/atomic.h:#error this file needs sys/cdefs.h as a prerequisite sys/amd64/include/in_cksum.h:#error this file needs sys/cdefs.h as a prerequisite sys/amd64/include/profile.h:#error this file needs sys/cdefs.h as a prerequisite sys/amd64/include/ieeefp.h:#error this file needs sys/cdefs.h as a prerequisite sys/amd64/include/varargs.h:#error this file needs sys/cdefs.h as a prerequisite sys/amd64/include/cpufunc.h:#error this file needs sys/cdefs.h as a prerequisite sys/arm/include/_types.h:#error this file needs sys/cdefs.h as a prerequisite sys/i386/include/_types.h:#error this file needs sys/cdefs.h as a prerequisite sys/i386/include/atomic.h:#error this file needs sys/cdefs.h as a prerequisite sys/i386/include/in_cksum.h:#error this file needs sys/cdefs.h as a prerequisite sys/i386/include/ieeefp.h:#error this file needs sys/cdefs.h as a prerequisite sys/i386/include/profile.h:#error this file needs sys/cdefs.h as a prerequisite sys/i386/include/varargs.h:#error this file needs sys/cdefs.h as a prerequisite sys/i386/include/cpufunc.h:#error this file needs sys/cdefs.h as a prerequisite sys/ia64/include/cpufunc.h:#error this file needs sys/cdefs.h as a prerequisite sys/ia64/include/_types.h:#error this file needs sys/cdefs.h as a prerequisite sys/mips/include/_types.h:#error this file needs sys/cdefs.h as a prerequisite sys/mips/include/atomic.h:#error this file needs sys/cdefs.h as a prerequisite sys/powerpc/include/_types.h:#error this file needs sys/cdefs.h as a prerequisite sys/powerpc/include/atomic.h:#error this file needs sys/cdefs.h as a prerequisite sys/powerpc/include/varargs.h:#error this file needs sys/cdefs.h as a prerequisite sys/sparc64/include/varargs.h:#error this file needs sys/cdefs.h as a prerequisite sys/sparc64/include/profile.h:#error this file needs sys/cdefs.h as a prerequisite sys/sparc64/include/_types.h:#error this file needs sys/cdefs.h as a prerequisite -- Robert Millan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
module_register_init fails, but driver is still loaded?
Hi hackers,
I noticed that if anything fails while initializing a driver, the
driver stays attached to the kernel as a module instead of being
kicked when all references to the driver go to 0. Is this desired
behavior (it doesn't seem like it, but I can see potential pros and
cons of kicking the driver out of the kernel immediately when a
failure state occurs)? I've seen this on 7.2 ~ 9-CURRENT. Example
sourcecode and invocation attached below.
Thanks!
-Garrett
/* bad_module.c */
#include sys/param.h
#include sys/kernel.h
#include sys/module.h
#define MODULE_NAME bad_module
static int
load(module_t m, int what, void *arg)
{
return (EINVAL);
}
static moduledata_t bad_module_mod = {
MODULE_NAME,
load,
NULL,
};
DECLARE_MODULE(bad_module, bad_module_mod, SI_SUB_KLD, SI_ORDER_ANY);
MODULE_VERSION(bad_module, 1);
/* Makefile */
KMOD= bad_module
SRCS= bad_module.c
.include bsd.kmod.mk
$ sudo kldload ./bad_driver.ko
$ dmesg | tail -n 1
module_register_init: MOD_LOAD (bad_module, 0x80a53000, 0) error 22
$ kldstat -v | grep bad_driver
51 0x80a53000 de bad_driver.ko
$ sudo kldunload ./bad_driver.ko
$ kldstat -v | grep bad_driver
$
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: DTrace script asserts and kills the other process
2011/8/4 ambrosehuang ambrose ambrose...@gmail.com
2011/8/3 Andriy Gapon a...@freebsd.org
on 28/07/2011 07:10 ambrosehuang ambrose said the following:
Yuri y...@rawbw.com wrote:
I am trying to run this dtrace script:
#!/usr/sbin/dtrace -s
pid123:libc::entry
{
self-timestmp[probefunc] = timestmp;
}
pid123:libc::return
/self-timestmp[probefunc] != 0/
{
@function_duration[probefunc] = sum(timestmp -
self-timestmp[probefunc]); timestmp[probefunc] = 0;
}
which I got from here:
http://www.princeton.edu/~unix/Solaris/troubleshoot/dtrace.html
replacing 123 with the pid of some running process.
Result: dtrace utility asserts:
Assertion failed: (dpr != NULL), file
/usr/src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/lib/libdtrace/common/dt_proc.c,
line 751.
Abort trap: 6
Also the target process is killed too:
Killed: 9
8.2-STABLE amd64
This is a known issue. You may be able to work around it by
letting dtrace start the traced process.
There's already a PR about it:
http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/158431
but the limitation isn't mentioned in the wiki:
http://wiki.freebsd.org/DTrace/userland
FYI and benefit: I've committed what should be a fix for this issue,
r224632.
It's not clear to me if this has worked in the past or if it
works for other architectures (the reporter and I are both using
amd64, too).
Fabian
I came across the same problem in 8.2-stable , it seemed the problem had
been there since 8.2-release with userland dtrace integrated. I followed
the
PR185431 and found when dtrace started, it indeed attached to the
traced
process( dpr != NULL), but the traced process died soon, and
according to the PR, this is error in error since the dtrace came
accross
error in dfatal
#3 0x000808d8af2d in dt_proc_lookup (dtp=0x80b841000, P=0x80d7ffb40,
remove=0)
at
/usr/src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/lib/libdtrace/common/dt_proc.c:751
#4 0x000808d8af92 in dt_proc_destroy (dtp=0x80b841000,
P=0x80d7ffb40)
at
/usr/src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/lib/libdtrace/common/dt_proc.c:763
#5 0x000808d8bc6e in dt_proc_hash_destroy (dtp=0x80b841000)
at
/usr/src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/lib/libdtrace/common/dt_proc.c:1162
#6 0x000808daa4b5 in dtrace_close (dtp=0x80b841000)
at
/usr/src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/lib/libdtrace/common/dt_open.c:1554
#7 0x00402775 in dfatal (fmt=0x408572 no probes %s\n)
at
/usr/src/cddl/usr.sbin/dtrace/../../../cddl/contrib/opensolaris/cmd/dtrace/dtrace.c:236
#8 0x00406b2c in main (argc=3, argv=0x7ffed9c0)
at
/usr/src/cddl/usr.sbin/dtrace/../../../cddl/contrib/opensolaris/cmd/dtrace/dtrace.c:1825
.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to
freebsd-hackers-unsubscr...@freebsd.org
I just saw your commit, I will verify it on 8-stable soon, thank you!
--
Andriy Gapon
I test your commit on 8-stable, here is my commit:
commit 84f49c7ffa130ec4bcd7fb0a619b36ab615dfeb4
Author: mm m...@freebsd.org
Date: Thu Aug 4 10:37:12 2011 +
this is the my result:
[root@lateaxfreebsd dtrace]# dtrace -n 'pid$target:libc::entry' -p 39699
libc.so.7: invalid probe specifier pid$target:libc::entry: probe description
pid39699:libc::entry
User defined signal 1: 30
[1]+ Hangup: 1 ../test
I also test the example from userland/dtrace in wiki, it failed with same
result,
it seems the pid provider has something wrong with libc when probing;
[root@lateaxfreebsd dtrace]# dtrace -n 'pid$target:::entry' -p 40346
test: description 'pid$target:::entry' matched 2 probes
^C
success
[root@lateaxfreebsd dtrace]# dtrace -ln 'pid$target:::entry' -p 40346
ID PROVIDERMODULE FUNCTION NAME
33913 pid40346 test_start entry
33914 pid40346 test main entry
User defined signal 1: 30
[1]+ Hangup: 1 ../test
Anyway, there is no core dump.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
[RFC] stdbuf: Force stdio's streams initial buffering mode (patch)
On Sat, Feb 19, 2011 at 07:50:43PM +0100, Jeremie Le Hen wrote:
I've been annoyed multiple time when running a command such like
iostat -x 1 | grep -v ad10 | cat -n
The problem stems from two factors:
- grep's stdio sees that its stdout is not a terminal, so stdout is
full buffered and not line-buffered;
- iostat produces output too slowly so the aforementioned buffer takes
numerous seconds to be filled and flushed to the last command.
This problems is not specific to FreeBSD, it is actually a consequence
of POSIX specification. I've checked this on Solaris and Linux.
I've attached a small patch for stdio, so if the environment variable
STDIO_IOLBF is set, the output streams will be line-oriented by default.
iostat -x 1 | env STDIO_IOLBF=1 grep -v ad10 | cat -n
I improved the whole picture. Now there is a shared library
libstdbuf.so which can be loaded with LD_PRELOAD and configured through
a environment variables. It is able to initial control buffering for
stdin, stdout and stderr (no buffering, line buffering, block
buffering). There is also an utility named stdbuf(1) which can be used
to run a command with the appropriate environment variables. Those are
named after a similar tool in recent versions of GNU coreutils; of
course, I also borrowed the interface for POLA.
Here is how to use it (example taken from the manpage):
vmstat 1 | stdbuf -o L awk '$2 1 || $3 1' | cat -n
I think that using a preloaded shared library is better performance-wise
because libc doesn't bother looking up configuration variables in the
environment upon each execve(2), especially for something which is to be
rarely used.
Manpages for both stdbuf(1) and libstdbuf(3) are provided. There is
surely room for improvement, so feel free to propose corrections to
them.
The patch can be applied as-is I think, although I've developped it
against an old -CURRENT source tree (about 6 months ago).
I'm looking for some feedback and review and hopefully this feature will
be committed for FreeBSD 9.0-RELEASE.
Regards,
--
Jeremie Le Hen
Humans are born free and equal. But some are more equal than others.
Coluche
diff -urNp src.HEAD_20111506/lib/libc/stdio/setbuf.3 src/lib/libc/stdio/setbuf.3
--- src.HEAD_20111506/lib/libc/stdio/setbuf.3 2007-01-09 01:28:07.0 +0100
+++ src/lib/libc/stdio/setbuf.3 2011-08-04 19:00:49.0 +0200
@@ -30,7 +30,7 @@
.\ SUCH DAMAGE.
.\
.\ @(#)setbuf.3 8.1 (Berkeley) 6/4/93
-.\ $FreeBSD: src/lib/libc/stdio/setbuf.3,v 1.17 2007/01/09 00:28:07 imp Exp $
+.\ $FreeBSD: src/lib/libc/stdio/setbuf.3,v 1.17.10.1 2009/08/03 08:13:06 kensmith Exp $
.\
.Dd June 4, 1993
.Dt SETBUF 3
@@ -83,6 +83,9 @@ normally does) it is line buffered.
The standard error stream
.Dv stderr
is always unbuffered.
+Note that these defaults maybe be altered using the
+.Xr stdbuf 1
+utility.
.Pp
The
.Fn setvbuf
@@ -177,6 +180,7 @@ function returns what the equivalent
.Fn setvbuf
would have returned.
.Sh SEE ALSO
+.Xr stdbuf 1 ,
.Xr fclose 3 ,
.Xr fopen 3 ,
.Xr fread 3 ,
diff -urNp src.HEAD_20111506/lib/libstdbuf/Makefile src/lib/libstdbuf/Makefile
--- src.HEAD_20111506/lib/libstdbuf/Makefile 1970-01-01 01:00:00.0 +0100
+++ src/lib/libstdbuf/Makefile 2011-08-04 18:49:59.0 +0200
@@ -0,0 +1,15 @@
+# $FreeBSD: src/lib/libftpio/Makefile,v 1.17.2.1 2009/08/03 08:13:06 kensmith Exp $
+
+.include bsd.own.mk
+
+LIB= stdbuf
+SRCS= stdbuf.c
+SHLIB_MAJOR= 1
+MAN= libstdbuf.3
+
+CFLAGS+= -I${.CURDIR}
+LDADD= -lutil
+
+WARNS?= 6
+
+.include bsd.lib.mk
diff -urNp src.HEAD_20111506/lib/libstdbuf/libstdbuf.3 src/lib/libstdbuf/libstdbuf.3
--- src.HEAD_20111506/lib/libstdbuf/libstdbuf.3 1970-01-01 01:00:00.0 +0100
+++ src/lib/libstdbuf/libstdbuf.3 2011-08-04 18:47:04.0 +0200
@@ -0,0 +1,111 @@
+.\ Copyright (c) 2011 Jeremie Le Hen
+.\ All rights reserved.
+.\
+.\ Redistribution and use in source and binary forms, with or without
+.\ modification, are permitted provided that the following conditions
+.\ are met:
+.\ 1. Redistributions of source code must retain the above copyright
+.\notice, this list of conditions and the following disclaimer.
+.\ 2. Redistributions in binary form must reproduce the above copyright
+.\notice, this list of conditions and the following disclaimer in the
+.\documentation and/or other materials provided with the distribution.
+.\
+.\ THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
+.\ ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+.\ IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+.\ ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
+.\ FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+.\ DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+.\ OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+.\
cam / ata timeout limited to 2147 due to overflow bug?
I'm working on adding security methods to camcontrol and have
come up against a strange issue. It seems that the timeout
value for cam, at least on ata (ahci), is limited to less than
2148 seconds.
This can be seen by running:-
camcontrol identify ada0 -t 2148 -v
(pass0:ahcich0:0:0:0): ATA_IDENTIFY. ACB: ec 00 00 00 00 40 00 00 00 00 00 00
(pass0:ahcich0:0:0:0): CAM status: Command timeout
Also seen in /var/log/messages at this time is:-
Aug 4 23:29:51 cfdev kernel: ahcich0: Timeout on slot 24
Aug 4 23:29:51 cfdev kernel: ahcich0: is cs 0100 ss rs
0100 tfd d0 serr
Dropping the timeout down to 2147 and the command runs fine.
I've done some digging and it seems like this is implemented via:-
sys/dev/ahci/ahci.c
ahci_execute_transaction(struct ahci_slot *slot)
{
...
/* Start command execution timeout */
callout_reset(slot-timeout, (int)ccb-ccb_h.timeout * hz / 2000,
(timeout_t*)ahci_timeout, slot);
Now its documented that:-
Non-positive values of ticks are silently converted to the value 1
So I suspect that this is what's happening resulting in an extremely
small timeout instead of a large one. Now I know that passed in value
to the timeout is seconds * 1000 so we should be seeing 2148000
for ccb-ccb_h.timeout now multiply that by 1000 (hz) and your over
the int wrap point 2147483647.
So instead of the wrap point being 2147483 seconds (24 days), I suspect
because of the way this is structured its actually 2147 seconds (26mins).
If this is the case the fix is likely to be something like:-
callout_reset(slot-timeout, (int)(ccb-ccb_h.timeout * (hz / 2000)),
Does this sound reasonable? What I don't understand is why the /2000?
For reference the reason for wanting a large timeout is that a
secure erase of large media could take many hours so I'm using
the erase time reported by the drive for this, in my case here is
400 minutes.
Currently this instantly fails with a Command timeout which is
clearly not right.
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-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
