Re: truss -f timeout 2 sleep 10 causes breakage

2024-03-27 Thread Konstantin Belousov
On Wed, Mar 27, 2024 at 01:00:07PM +0100, Mateusz Guzik wrote:
> Top of main, but I reproduced it on stable/14-e64d827d3 as well.
> 
> Mere "timeout 2 sleep 10" correctly times out.
> 
> Running "truss -f timeout 2 sleep 10" prevents timeout from killing
> sleep and the entire thing refuses to exit, truss has to be killed off
> with SIGKILL.
The issue is because debugger can stop the debuggee, which makes the
single threading never succeed.  Supposed fix is in
https://reviews.freebsd.org/D44523
the cost is that in principle, the debuggee now can try to break out of
the reaper kill hammer, with the help of debugger.  But this setup is
arguably too convoluted: you either control the process with reaper, or
with debugger.

> 
> Here is the best part: after doing the above, going back to mere
> "timeout 2 sleep 10" (without truss!) no longer works -- timeout gets
> stuck in the kernel: mi_switch sleepq_catch_signals sleepq_wait_sig
> _sx_xlock_hard stop_all_proc_block kern_procctl sys_procctl
> amd64_syscall fast_syscall_common
This is because the threaded workqueue thread is stuck waiting for
single-threading of the victim.

> 
> It does react to -9 though.
Not the workqueue, which is the problem.



Re: truss -f timeout 2 sleep 10 causes breakage

2024-03-27 Thread Dag-Erling Smørgrav
Mateusz Guzik  writes:
> Top of main, but I reproduced it on stable/14-e64d827d3 as well.

Confirmed on 14.0-RELEASE-p5.

> Mere "timeout 2 sleep 10" correctly times out.
>
> Running "truss -f timeout 2 sleep 10" prevents timeout from killing
> sleep

This is sort of expected as truss(1) uses ptrace(2) which breaks the
parent-child relationship, so you should never use `truss -f` with a
command that expects to control its children.

> and the entire thing refuses to exit, truss has to be killed off
> with SIGKILL.

This, however, is not expected.

> Here is the best part: after doing the above, going back to mere
> "timeout 2 sleep 10" (without truss!) no longer works

Neither is this.

DES
-- 
Dag-Erling Smørgrav - d...@freebsd.org



Re: truss

2011-09-21 Thread Anton Yuzhaninov
On Tue, 20 Sep 2011 00:27:22 +0300, Kostik Belousov wrote:
KB Could you, please, test the change below ? For me, I still can truss(1)
KB or debug with gdb after the change applied. Does truss work for you
KB with only this change, without resetting SIGTRAP handler in truss process ?
KB 
KB commit 2ae586c039a55399edc3b34cd40410e0d690a16c
KB Author: Konstantin Belousov kos...@pooma.home
KB Date:   Tue Sep 20 00:25:07 2011 +0300
KB 
KB Do not deliver SIGTRAP on exec as the normal signal, use ptracestop()
KB on syscall exit path. Otherwise, if SIGTRAP is ignored, that 
tdsendsignal()
KB do not want to deliver, and debugger never get a notification of exec.

I can confirm - with this patch unmodified truss works when SIGTRAP is ignored.

-- 
 Anton Yuzhaninov

___
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: truss

2011-09-20 Thread Anton Yuzhaninov
On Tue, 20 Sep 2011 00:27:22 +0300, Kostik Belousov wrote:
 With this patch truss works for me:
 
 --- usr.bin/truss/main.c(revision 225504)
 +++ usr.bin/truss/main.c(working copy)
 @@ -255,6 +255,11 @@ main(int ac, char **av)
 
 if (trussinfo-pid == 0) {  /* Start a command ourselves */
 command = av;
 +   /*
 +* SIGTRUP used to stop traced process after execve
 +* un-ignore this signal (it can be ignored by parents)
 +*/
 +   signal(SIGTRAP, SIG_DFL);
 trussinfo-pid = setup_and_wait(command);
 signal(SIGINT, SIG_IGN);
 signal(SIGTERM, SIG_IGN);
KB This is quite a hack. The proper fix should go in kernel, otherwise
KB we cannot debug programs that decided to ignore SIGTRAP. The reason

It seems to be, that in gdb used similar hack:

citrin:~ procstat -i 2433 | fgrep TRAP
 2433 dd   TRAP -I-

:~ gdb /bin/dd 2433
...
(gdb) next
Single stepping until exit from function write,
which has no line number information.
dd_out (force=1) at dd.c:458
458 if (nw = 0) {
(gdb)
...

:~ procstat -i 2433 | fgrep TRAP
 2433 dd   TRAP ---

KB Could you, please, test the change below ? For me, I still can truss(1)
KB or debug with gdb after the change applied. Does truss work for you
KB with only this change, without resetting SIGTRAP handler in truss process ?

I'll test this patch.

-- 
 Anton Yuzhaninov

___
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: truss

2011-09-19 Thread Anton Yuzhaninov
On Sun, 18 Sep 2011 16:46:01 +0300, Mikolaj Golub wrote:
MG Could you please run ktrace with -i option? The behavior is like if
MG ptrace(PT_TRACE_ME) failed in the child by some reason. Unfortunately, truss
MG does not check this.

ktrace -i for truss sleep 5
http://dl.dropbox.com/u/8798217/tmp/truss_ktrace2.txt

-- 
 Anton Yuzhaninov

___
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: truss

2011-09-19 Thread Mikolaj Golub

On Mon, 19 Sep 2011 12:13:56 + (UTC) Anton Yuzhaninov wrote to Mikolaj 
Golub:

 AY On Sun, 18 Sep 2011 16:46:01 +0300, Mikolaj Golub wrote:
 MG Could you please run ktrace with -i option? The behavior is like if
 MG ptrace(PT_TRACE_ME) failed in the child by some reason. Unfortunately, 
truss
 MG does not check this.

 AY ktrace -i for truss sleep 5
 AY http://dl.dropbox.com/u/8798217/tmp/truss_ktrace2.txt

Although ptrace(PT_TRACE_ME,0,0,0) returned 0 the process did not stop after
execve() and wait4() in parent (which was actually waiting for this stop)
returned only after the child exit. No I idea why so far :-).

-- 
Mikolaj Golub
___
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: truss

2011-09-19 Thread Anton Yuzhaninov
On Mon, 19 Sep 2011 15:58:02 +0300, Mikolaj Golub wrote:
 AY ktrace -i for truss sleep 5
 AY http://dl.dropbox.com/u/8798217/tmp/truss_ktrace2.txt
MG 
MG Although ptrace(PT_TRACE_ME,0,0,0) returned 0 the process did not stop after
MG execve() and wait4() in parent (which was actually waiting for this stop)
MG returned only after the child exit. No I idea why so far :-).
MG 

As I understand SIGTRAP used to stop child process after execve(), but
this signal ignored:

citrin:~ sleep 300 
citrin:~ procstat -i 1991 | fgrep TRAP
 1991 sleepTRAP -I-

Under FreeBSD 8, where ptrace works for me, this signal is not ignored:
x:~ sleep 300 
x:~ procstat -i 78716 | fgrep TRAP
78716 sleepTRAP ---

-- 
 Anton Yuzhaninov

___
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: truss

2011-09-19 Thread Anton Yuzhaninov
On Mon, 19 Sep 2011 15:00:31 + (UTC), Anton Yuzhaninov wrote:
AY On Mon, 19 Sep 2011 15:58:02 +0300, Mikolaj Golub wrote:
 AY ktrace -i for truss sleep 5
 AY http://dl.dropbox.com/u/8798217/tmp/truss_ktrace2.txt
MG 
MG Although ptrace(PT_TRACE_ME,0,0,0) returned 0 the process did not stop 
after
MG execve() and wait4() in parent (which was actually waiting for this stop)
MG returned only after the child exit. No I idea why so far :-).
MG 
AY 
AY As I understand SIGTRAP used to stop child process after execve(), but
AY this signal ignored:
AY 
AY citrin:~ sleep 300 
AY citrin:~ procstat -i 1991 | fgrep TRAP
AY  1991 sleepTRAP -I-
AY 
AY Under FreeBSD 8, where ptrace works for me, this signal is not ignored:
AY x:~ sleep 300 
AY x:~ procstat -i 78716 | fgrep TRAP
AY 78716 sleepTRAP ---

SIGTRAP is ignored by X window manager used by me, and this is inherited across
forks/execs up to the truss.

IMHO truss should restore default signal handler for SIGTRAP.

With this patch truss works for me:

--- usr.bin/truss/main.c(revision 225504)
+++ usr.bin/truss/main.c(working copy)
@@ -255,6 +255,11 @@ main(int ac, char **av)

if (trussinfo-pid == 0) {  /* Start a command ourselves */
command = av;
+   /*
+* SIGTRUP used to stop traced process after execve
+* un-ignore this signal (it can be ignored by parents)
+*/
+   signal(SIGTRAP, SIG_DFL);
trussinfo-pid = setup_and_wait(command);
signal(SIGINT, SIG_IGN);
signal(SIGTERM, SIG_IGN);

-- 
 Anton Yuzhaninov

___
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: truss

2011-09-19 Thread Kostik Belousov
On Mon, Sep 19, 2011 at 04:03:42PM +, Anton Yuzhaninov wrote:
 On Mon, 19 Sep 2011 15:00:31 + (UTC), Anton Yuzhaninov wrote:
 AY On Mon, 19 Sep 2011 15:58:02 +0300, Mikolaj Golub wrote:
  AY ktrace -i for truss sleep 5
  AY http://dl.dropbox.com/u/8798217/tmp/truss_ktrace2.txt
 MG 
 MG Although ptrace(PT_TRACE_ME,0,0,0) returned 0 the process did not stop 
 after
 MG execve() and wait4() in parent (which was actually waiting for this stop)
 MG returned only after the child exit. No I idea why so far :-).
 MG 
 AY 
 AY As I understand SIGTRAP used to stop child process after execve(), but
 AY this signal ignored:
 AY 
 AY citrin:~ sleep 300 
 AY citrin:~ procstat -i 1991 | fgrep TRAP
 AY  1991 sleepTRAP -I-
 AY 
 AY Under FreeBSD 8, where ptrace works for me, this signal is not ignored:
 AY x:~ sleep 300 
 AY x:~ procstat -i 78716 | fgrep TRAP
 AY 78716 sleepTRAP ---
 
 SIGTRAP is ignored by X window manager used by me, and this is inherited 
 across
 forks/execs up to the truss.
 
 IMHO truss should restore default signal handler for SIGTRAP.
 
 With this patch truss works for me:
 
 --- usr.bin/truss/main.c(revision 225504)
 +++ usr.bin/truss/main.c(working copy)
 @@ -255,6 +255,11 @@ main(int ac, char **av)
 
 if (trussinfo-pid == 0) {  /* Start a command ourselves */
 command = av;
 +   /*
 +* SIGTRUP used to stop traced process after execve
 +* un-ignore this signal (it can be ignored by parents)
 +*/
 +   signal(SIGTRAP, SIG_DFL);
 trussinfo-pid = setup_and_wait(command);
 signal(SIGINT, SIG_IGN);
 signal(SIGTERM, SIG_IGN);
This is quite a hack. The proper fix should go in kernel, otherwise
we cannot debug programs that decided to ignore SIGTRAP. The reason
there is that tdsendsignal() does nothing for attempt to deliver ignored
signal, and kern_execve() simply tries to send a signal to self.

BTW, it seems we might also have similar issues for threads that masks
SIGTRAP, now because issignal() does nothing in that case too. But lets
handle it by small steps.

Could you, please, test the change below ? For me, I still can truss(1)
or debug with gdb after the change applied. Does truss work for you
with only this change, without resetting SIGTRAP handler in truss process ?

commit 2ae586c039a55399edc3b34cd40410e0d690a16c
Author: Konstantin Belousov kos...@pooma.home
Date:   Tue Sep 20 00:25:07 2011 +0300

Do not deliver SIGTRAP on exec as the normal signal, use ptracestop()
on syscall exit path. Otherwise, if SIGTRAP is ignored, that tdsendsignal()
do not want to deliver, and debugger never get a notification of exec.

Found by:   Anton Yuzhaninov cit...@citrin.ru

diff --git a/sys/kern/kern_exec.c b/sys/kern/kern_exec.c
index fe01142..4545848 100644
--- a/sys/kern/kern_exec.c
+++ b/sys/kern/kern_exec.c
@@ -777,16 +777,6 @@ interpret:
KNOTE_LOCKED(p-p_klist, NOTE_EXEC);
p-p_flag = ~P_INEXEC;
 
-   /*
-* If tracing the process, trap to the debugger so that
-* breakpoints can be set before the program executes.  We
-* have to use tdsignal() to deliver the signal to the current
-* thread since any other threads in this process will exit if
-* execve() succeeds.
-*/
-   if (p-p_flag  P_TRACED)
-   tdsignal(td, SIGTRAP);
-
/* clear fork but no exec flag, as we _are_ execing */
p-p_acflag = ~AFORK;
 
diff --git a/sys/kern/subr_syscall.c b/sys/kern/subr_syscall.c
index cb0d929..bba4479 100644
--- a/sys/kern/subr_syscall.c
+++ b/sys/kern/subr_syscall.c
@@ -204,9 +204,17 @@ syscallret(struct thread *td, int error, struct 
syscall_args *sa __unused)
 * is not the case, this code will need to be revisited.
 */
STOPEVENT(p, S_SCX, sa-code);
-   PTRACESTOP_SC(p, td, S_PT_SCX);
if (traced || (td-td_dbgflags  (TDB_EXEC | TDB_FORK)) != 0) {
PROC_LOCK(p);
+   /*
+* If tracing the execed process, trap to the debugger
+* so that breakpoints can be set before the program
+* executes.  If debugger requested tracing of syscall
+* returns, do it now too.
+*/
+   if (traced  ((td-td_dbgflags  TDB_EXEC) != 0 ||
+   (p-p_stops  S_PT_SCX) != 0))
+   ptracestop(td, SIGTRAP);
td-td_dbgflags = ~(TDB_SCX | TDB_EXEC | TDB_FORK);
PROC_UNLOCK(p);
}


pgpF2yup3qKFJ.pgp
Description: PGP signature


Re: truss

2011-09-18 Thread Mikolaj Golub

On Wed, 14 Sep 2011 06:17:45 + (UTC) Anton Yuzhaninov wrote to Xin LI:

 AY On Fri, 09 Sep 2011 15:56:41 -0700, Xin LI wrote:
 XL -BEGIN PGP SIGNED MESSAGE-
 XL Hash: SHA256
 XL 
 XL On 08/31/11 07:35, Anton Yuzhaninov wrote:
  It seems to be truss(1) is broken on current
  
  :~ truss /bin/echo x x truss: can not get etype: No such process
  
  FreeBSD 9.0-BETA1 #0 r224884M i386
  
  from ktrace of turss
  
  3162 trussCALL
  __sysctl(0xbfbfea00,0x4,0xbfbfe9e0,0xbfbfea10,0,0) 3162 truss
  SCTL  kern.proc.sv_name.3163 3162 trussRET   __sysctl -1
  errno 3 No such process
 XL 
 XL Can't seem to be reproducable here, did I missed anything?  (note that
 XL you may need a full world/kernel build).
 XL 

 AY Problem still here after svn up and rebuild world/kernel

 AY :~ ktrace -t+ truss /usr/bin/true
 AY truss: can not get etype: No such process

Could you please run ktrace with -i option? The behavior is like if
ptrace(PT_TRACE_ME) failed in the child by some reason. Unfortunately, truss
does not check this.

 AY Full ktrace:
 AY http://dl.dropbox.com/u/8798217/tmp/truss_ktrace.txt

 AY FreeBSD 9.0-BETA2 #1 r225504M
 AY i386

 AY Kernel config is not GENERIC - main difference - DTrace added:
 AY http://dl.dropbox.com/u/8798217/tmp/kernconf.txt

 AY -- 
 AY  Anton Yuzhaninov

 AY ___
 AY freebsd-current@freebsd.org mailing list
 AY http://lists.freebsd.org/mailman/listinfo/freebsd-current
 AY To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

-- 
Mikolaj Golub
___
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: truss

2011-09-14 Thread Anton Yuzhaninov
On Fri, 09 Sep 2011 15:56:41 -0700, Xin LI wrote:
XL -BEGIN PGP SIGNED MESSAGE-
XL Hash: SHA256
XL 
XL On 08/31/11 07:35, Anton Yuzhaninov wrote:
 It seems to be truss(1) is broken on current
 
 :~ truss /bin/echo x x truss: can not get etype: No such process
 
 FreeBSD 9.0-BETA1 #0 r224884M i386
 
 from ktrace of turss
 
 3162 trussCALL
 __sysctl(0xbfbfea00,0x4,0xbfbfe9e0,0xbfbfea10,0,0) 3162 truss
 SCTL  kern.proc.sv_name.3163 3162 trussRET   __sysctl -1
 errno 3 No such process
XL 
XL Can't seem to be reproducable here, did I missed anything?  (note that
XL you may need a full world/kernel build).
XL 

Problem still here after svn up and rebuild world/kernel

:~ ktrace -t+ truss /usr/bin/true
truss: can not get etype: No such process

Full ktrace:
http://dl.dropbox.com/u/8798217/tmp/truss_ktrace.txt

FreeBSD 9.0-BETA2 #1 r225504M
i386

Kernel config is not GENERIC - main difference - DTrace added:
http://dl.dropbox.com/u/8798217/tmp/kernconf.txt

-- 
 Anton Yuzhaninov

___
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: truss

2011-09-09 Thread Xin LI
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 08/31/11 07:35, Anton Yuzhaninov wrote:
 It seems to be truss(1) is broken on current
 
 :~ truss /bin/echo x x truss: can not get etype: No such process
 
 FreeBSD 9.0-BETA1 #0 r224884M i386
 
 from ktrace of turss
 
 3162 trussCALL
 __sysctl(0xbfbfea00,0x4,0xbfbfe9e0,0xbfbfea10,0,0) 3162 truss
 SCTL  kern.proc.sv_name.3163 3162 trussRET   __sysctl -1
 errno 3 No such process

Can't seem to be reproducable here, did I missed anything?  (note that
you may need a full world/kernel build).

 truss /bin/echo x
mmap(0x0,32768,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) =
34366255104 (0x800637000)
issetugid(0x800638015,0x80062cd9e,0x800848810,0x8008487e0,0xb277,0x0)
= 0 (0x0)
open(/etc/libmap.conf,O_RDONLY,0666)   = 3 (0x3)
fstat(3,{ mode=-rw-r--r-- ,inode=1668471,size=712,blksize=4096 }) = 0
(0x0)
read(3,libpthread.so.2\tlibthr.so.2\nli...,4096) = 712 (0x2c8)
read(3,0x80063b000,4096) = 0 (0x0)
close(3) = 0 (0x0)
open(/var/run/ld-elf.so.hints,O_RDONLY,0160)   = 3 (0x3)
read(3,Ehnt\^A\0\0\0\M^@\0\0\0\M-\\^A\0...,128) = 128 (0x80)
lseek(3,0x80,SEEK_SET)   = 128 (0x80)
read(3,/lib:/usr/lib:/usr/lib/compat:/u...,476) = 476 (0x1dc)
close(3) = 0 (0x0)
mmap(0x0,36864,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) =
34366287872 (0x80063f000)
access(/lib/libc.so.7,0)   = 0 (0x0)
open(/lib/libc.so.7,O_RDONLY,040737600)= 3 (0x3)
fstat(3,{ mode=-r--r--r-- ,inode=2664100,size=1310888,blksize=131072
}) = 0 (0x0)
pread(0x3,0x80083af60,0x1000,0x0,0x101010101010101,0x8080808080808080)
= 4096 (0x1000)
mmap(0x0,3432448,PROT_NONE,MAP_PRIVATE|MAP_ANON|MAP_NOCORE,-1,0x0) =
34368425984 (0x800849000)
mmap(0x800849000,1179648,PROT_READ|PROT_EXEC,MAP_PRIVATE|MAP_FIXED|MAP_NOCORE,3,0x0)
= 34368425984 (0x800849000)
mmap(0x800b69000,45056,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_FIXED,3,0x12)
= 34371702784 (0x800b69000)
mprotect(0x800b74000,110592,PROT_READ|PROT_WRITE) = 0 (0x0)
close(3) = 0 (0x0)
sysarch(0x81,0x7fffcfc0,0x80063d6c8,0x0,0xffad0580,0x800865370)
= 0 (0x0)
munmap(0x800642000,24576)= 0 (0x0)
mmap(0x0,102400,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) =
34366300160 (0x800642000)
sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0)
= 0 (0x0)
sigprocmask(SIG_SETMASK,0x0,0x0) = 0 (0x0)
sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0)
= 0 (0x0)
sigprocmask(SIG_SETMASK,0x0,0x0) = 0 (0x0)
readlink(/etc/malloc.conf,aj,1024)   = 2 (0x2)
issetugid(0x800945ba1,0x7fffd220,0x6a,0x0,0x2,0x2) = 0 (0x0)
break(0x80)  = 0 (0x0)
mmap(0x0,4194304,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) =
34371858432 (0x800b8f000)
mmap(0x800f8f000,462848,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0)
= 34376052736 (0x800f8f000)
munmap(0x800b8f000,462848)   = 0 (0x0)
x
writev(0x1,0x800c07040,0x2,0x7fffdad0,0x600d10,0x7fffcd60) = 2
(0x2)
sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0)
= 0 (0x0)
sigprocmask(SIG_SETMASK,0x0,0x0) = 0 (0x0)
sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0)
= 0 (0x0)
sigprocmask(SIG_SETMASK,0x0,0x0) = 0 (0x0)
process exit, rval = 0

Cheers,
- -- 
Xin LI delp...@delphij.nethttps://www.delphij.net/
FreeBSD - The Power to Serve!   Live free or die
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.18 (FreeBSD)

iQEcBAEBCAAGBQJOapmpAAoJEATO+BI/yjfBgY8IANXc7pbkZHEa0I6N6eZPM2Mk
IuiK8Ei6p9jGI72DYS9VV+OPGerarkBw0CvYyKr9lNKV5rnB4fg04MiUflNGpSqN
2zQmnGewzr1+a/bC6txaLZr5ittUnpzXp85CB1sEZ5tXn34pMsW9MYmSSmL4SwMG
L8e4+U+QjdOMvH2BHEil3WdkqPDQKnz/mk+2wJX7gw3/ssf7QozyQ4vpE4Ed2jC8
dnpCmE++BtPRK+PzdbhcoT3/KpSCuWIpaAAcxh8RE994K3nwc27crPOKLA/7lQ2x
u4VIIcX27Jb1pKwugmcriTCIhCb0D7ge44fDTHAhY97W7p36JD3DbSUm5zs8I8o=
=v+hw
-END PGP SIGNATURE-
___
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: truss

2011-09-09 Thread Garrett Cooper
On Sep 9, 2011, at 3:56 PM, Xin LI delp...@delphij.net wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256
 
 On 08/31/11 07:35, Anton Yuzhaninov wrote:
 It seems to be truss(1) is broken on current
 
 :~ truss /bin/echo x x truss: can not get etype: No such process
 
 FreeBSD 9.0-BETA1 #0 r224884M i386
 
 from ktrace of turss
 
 3162 trussCALL
 __sysctl(0xbfbfea00,0x4,0xbfbfe9e0,0xbfbfea10,0,0) 3162 truss
 SCTL  kern.proc.sv_name.3163 3162 trussRET   __sysctl -1
 errno 3 No such process
 
 Can't seem to be reproducable here, did I missed anything?  (note that
 you may need a full world/kernel build).
 
 truss /bin/echo x
 mmap(0x0,32768,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) =
 34366255104 (0x800637000)
 issetugid(0x800638015,0x80062cd9e,0x800848810,0x8008487e0,0xb277,0x0)
 = 0 (0x0)
 open(/etc/libmap.conf,O_RDONLY,0666) = 3 (0x3)
 fstat(3,{ mode=-rw-r--r-- ,inode=1668471,size=712,blksize=4096 }) = 0
 (0x0)
 read(3,libpthread.so.2\tlibthr.so.2\nli...,4096) = 712 (0x2c8)
 read(3,0x80063b000,4096) = 0 (0x0)
 close(3) = 0 (0x0)
 open(/var/run/ld-elf.so.hints,O_RDONLY,0160) = 3 (0x3)
 read(3,Ehnt\^A\0\0\0\M^@\0\0\0\M-\\^A\0...,128) = 128 (0x80)
 lseek(3,0x80,SEEK_SET) = 128 (0x80)
 read(3,/lib:/usr/lib:/usr/lib/compat:/u...,476) = 476 (0x1dc)
 close(3) = 0 (0x0)
 mmap(0x0,36864,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) =
 34366287872 (0x80063f000)
 access(/lib/libc.so.7,0) = 0 (0x0)
 open(/lib/libc.so.7,O_RDONLY,040737600) = 3 (0x3)
 fstat(3,{ mode=-r--r--r-- ,inode=2664100,size=1310888,blksize=131072
 }) = 0 (0x0)
 pread(0x3,0x80083af60,0x1000,0x0,0x101010101010101,0x8080808080808080)
 = 4096 (0x1000)
 mmap(0x0,3432448,PROT_NONE,MAP_PRIVATE|MAP_ANON|MAP_NOCORE,-1,0x0) =
 34368425984 (0x800849000)
 mmap(0x800849000,1179648,PROT_READ|PROT_EXEC,MAP_PRIVATE|MAP_FIXED|MAP_NOCORE,3,0x0)
 = 34368425984 (0x800849000)
 mmap(0x800b69000,45056,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_FIXED,3,0x12)
 = 34371702784 (0x800b69000)
 mprotect(0x800b74000,110592,PROT_READ|PROT_WRITE) = 0 (0x0)
 close(3) = 0 (0x0)
 sysarch(0x81,0x7fffcfc0,0x80063d6c8,0x0,0xffad0580,0x800865370)
 = 0 (0x0)
 munmap(0x800642000,24576) = 0 (0x0)
 mmap(0x0,102400,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) =
 34366300160 (0x800642000)
 sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0)
 = 0 (0x0)
 sigprocmask(SIG_SETMASK,0x0,0x0) = 0 (0x0)
 sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0)
 = 0 (0x0)
 sigprocmask(SIG_SETMASK,0x0,0x0) = 0 (0x0)
 readlink(/etc/malloc.conf,aj,1024) = 2 (0x2)
 issetugid(0x800945ba1,0x7fffd220,0x6a,0x0,0x2,0x2) = 0 (0x0)
 break(0x80) = 0 (0x0)
 mmap(0x0,4194304,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) =
 34371858432 (0x800b8f000)
 mmap(0x800f8f000,462848,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0)
 = 34376052736 (0x800f8f000)
 munmap(0x800b8f000,462848) = 0 (0x0)
 x
 writev(0x1,0x800c07040,0x2,0x7fffdad0,0x600d10,0x7fffcd60) = 2
 (0x2)
 sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0)
 = 0 (0x0)
 sigprocmask(SIG_SETMASK,0x0,0x0) = 0 (0x0)
 sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0)
 = 0 (0x0)
 sigprocmask(SIG_SETMASK,0x0,0x0) = 0 (0x0)
 process exit, rval = 0

Truss isn't broken for me this way either. It just doesn't detach from 
processes properly if I do ctrl c, which seems like a ptrace bug to me.

It would help to know how truss was compiled (file would be helpful), and what 
environment it's being executed in (32bit on 64bit, a chroot/jail, etc).
Thanks,
-Garrett___
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: truss

2011-08-31 Thread Christer Solskogen
On Wed, Aug 31, 2011 at 4:35 PM, Anton Yuzhaninov cit...@citrin.ru wrote:
 It seems to be truss(1) is broken on current


I just tried with a newly build CURRENT, and no problem here.

[solskogen@friend ~]$ truss /bin/echo x
mmap(0x0,32768,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) =
34366255104 (0x800637000)
issetugid(0x800638015,0x80062cb5e,0x800848250,0x800848220,0xb4b7,0x0) = 0 (0x0)
open(/etc/libmap.conf,O_RDONLY,0666)   ERR#2 'No such file or 
directory'
open(/var/run/ld-elf.so.hints,O_RDONLY,057)= 3 (0x3)
read(3,Ehnt\^A\0\0\0\M^@\0\0\0-\0\0\0\0...,128) = 128 (0x80)
lseek(3,0x80,SEEK_SET)   = 128 (0x80)
read(3,/lib:/usr/lib:/usr/lib/compat:/u...,45) = 45 (0x2d)
close(3) = 0 (0x0)
access(/lib/libc.so.7,0)   = 0 (0x0)
open(/lib/libc.so.7,O_RDONLY,040734700)= 3 (0x3)
fstat(3,{ mode=-r--r--r-- ,inode=4830,size=1268472,blksize=131072 }) = 0 (0x0)
pread(0x3,0x80083a9a0,0x1000,0x0,0x101010101010101,0x8080808080808080)
= 4096 (0x1000)
mmap(0x0,3387392,PROT_NONE,MAP_PRIVATE|MAP_ANON|MAP_NOCORE,-1,0x0) =
34368425984 (0x800849000)
mmap(0x800849000,1138688,PROT_READ|PROT_EXEC,MAP_PRIVATE|MAP_FIXED|MAP_NOCORE,3,0x0)
= 34368425984 (0x800849000)
mmap(0x800b5f000,40960,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_FIXED,3,0x116000)
= 34371661824 (0x800b5f000)
mprotect(0x800b69000,110592,PROT_READ|PROT_WRITE) = 0 (0x0)
close(3) = 0 (0x0)
sysarch(0x81,0x7fffd2f0,0x80063b0c8,0x0,0xffada580,0x800864b38)
= 0 (0x0)
munmap(0x80063e000,4096) = 0 (0x0)
mmap(0x0,102400,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) =
34366283776 (0x80063e000)
sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0)
= 0 (0x0)
sigprocmask(SIG_SETMASK,0x0,0x0) = 0 (0x0)
sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0)
= 0 (0x0)
sigprocmask(SIG_SETMASK,0x0,0x0) = 0 (0x0)
readlink(/etc/malloc.conf,aj,1024)   = 2 (0x2)
issetugid(0x80093e153,0x7fffd550,0x6a,0x0,0x2,0x2) = 0 (0x0)
break(0x80)  = 0 (0x0)
mmap(0x0,4194304,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) =
34371813376 (0x800b84000)
mmap(0x800f84000,507904,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0)
= 34376007680 (0x800f84000)
munmap(0x800b84000,507904)   = 0 (0x0)
x
writev(0x1,0x800c07040,0x2,0x7fffdd40,0x0,0x600d10) = 2 (0x2)
sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0)
= 0 (0x0)
sigprocmask(SIG_SETMASK,0x0,0x0) = 0 (0x0)
sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0)
= 0 (0x0)
sigprocmask(SIG_SETMASK,0x0,0x0) = 0 (0x0)
process exit, rval = 0

-- 
chs,
___
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: truss crashing process

2011-07-27 Thread Dan Nelson
In the last episode (Jul 27), Alexander Best said:
 hi there,
 
 i was trying to attach truss to chromium via
 
 'truss -p 18445' and got:
 
 [...]
 kevent(26,{},0,{0x1b,EVFILT_READ,0x0,0,0x1,0x44cb600 0x0,0x0,0x0,0,0x0,0x0 
 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 
 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 
 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 
 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 
 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 
 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 
 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 
 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 
 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 
 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 
 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 
 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 
 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 
 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x!
 0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 
0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 
0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 
0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 
0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 
0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 
0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 
0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 
0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 
0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 
0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 
0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 
0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 
0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 
0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,!
 0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,!
 0x0,0x0,
 -- UNKNOWN SYSCALL -14720592 --
 write(-14720976,0x8080808080808000,0)  = 41 (0x29)
 select(94,0x6acd,{0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 
 23 24 25 26 27 28 29 30 31 40 41 42 43 44 45 46 70 71 72 73 76 77 78 79 80 81 
 82 84 87 88 91},0x1,{0.85048848 }) = 73 (0x49)
 -- UNKNOWN SYSCALL 303120384 --
 #94(0x0,0x0,0x5e,0xb6cd600,0x83ed780,0x3dae410)= 189 (0xbd)
 truss: Cannot malloc -14740096 bytes for fd_set array: Cannot allocate memory

Invalid syscalls numbers like that usually mean that truss has attached to a
process in the middle of a syscall.  The ptrace API fires the same event for
syscall enter and exit, so if truss is expecting an enter and gets an exit,
you get a mangled syscall number and eventually truss will coredump trying
to decode incorrect data.

Try applying the patch at https://www.evoy.net/FreeBSD/truss.diff , which
amongst other things, fixes this problem.  If you just want the syscall fix,
search the diff for 50-50 chance and manually patch that if(){} block in
your source.

-- 
Dan Nelson
dnel...@allantgroup.com

___
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: truss crashing process

2011-07-27 Thread Kostik Belousov
On Wed, Jul 27, 2011 at 11:35:49AM -0500, Dan Nelson wrote:
 In the last episode (Jul 27), Alexander Best said:
  hi there,
  
  i was trying to attach truss to chromium via
  
  'truss -p 18445' and got:
  
  [...]
  kevent(26,{},0,{0x1b,EVFILT_READ,0x0,0,0x1,0x44cb600 0x0,0x0,0x0,0,0x0,0x0 
  0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 
  0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 
  0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 
  0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 
  0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 
  0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 
  0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 
  0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 
  0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 
  0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 
  0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 
  0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 
  0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 
  0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x!
  0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 
 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 
 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 
 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 
 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 
 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 
 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 
 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 
 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 
 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 
 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 
 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 
 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 
 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 
 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,!
  0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,!
  0x0,0x0,
  -- UNKNOWN SYSCALL -14720592 --
  write(-14720976,0x8080808080808000,0)= 41 (0x29)
  select(94,0x6acd,{0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 
  22 23 24 25 26 27 28 29 30 31 40 41 42 43 44 45 46 70 71 72 73 76 77 78 79 
  80 81 82 84 87 88 91},0x1,{0.85048848 }) = 73 (0x49)
  -- UNKNOWN SYSCALL 303120384 --
  #94(0x0,0x0,0x5e,0xb6cd600,0x83ed780,0x3dae410)  = 189 (0xbd)
  truss: Cannot malloc -14740096 bytes for fd_set array: Cannot allocate 
  memory
 
 Invalid syscalls numbers like that usually mean that truss has attached to a
 process in the middle of a syscall.  The ptrace API fires the same event for
 syscall enter and exit, so if truss is expecting an enter and gets an exit,
 you get a mangled syscall number and eventually truss will coredump trying
 to decode incorrect data.
 
 Try applying the patch at https://www.evoy.net/FreeBSD/truss.diff , which
 amongst other things, fixes this problem.  If you just want the syscall fix,
 search the diff for 50-50 chance and manually patch that if(){} block in
 your source.

We have PL_FLAG_SCE/PL_FLAG_SCX for some time. I planned to update truss
to use the flags, as well as to take advantage of PL_FLAG_FORKED to close
the race where truss can miss the forked child.

Unfortunately, the project stalled.


pgpl5z6RehkLM.pgp
Description: PGP signature


Re: truss calls setpgid()

2010-10-11 Thread John Baldwin
On Monday, October 11, 2010 9:17:19 am Ed Schouten wrote:
 Hi all,
 
 I've been seeing this bug for a very long time, but I was too lazy to
 figure out the root cause earlier. It is TTY related, but in this case
 the TTY layer is not to blame. It does things correctly.
 
 When you run a command in truss which calls ioctls on TTYs, it just
 locks up. This is because truss runs jobs in a separate process group.
 This also means you cannot send signals to it:
 
   truss sleep 1
 
 Pressing ^C here won't work.
 
 I've fixed it locally like this:
 
 Index: usr.bin/truss/setup.c
 ===
 --- usr.bin/truss/setup.c   (revision 213113)
 +++ usr.bin/truss/setup.c   (working copy)
 @@ -78,7 +78,6 @@
 }
 if (pid == 0) { /* Child */
 ptrace(PT_TRACE_ME, 0, 0, 0);
 -   setpgid (0, 0); 
 execvp(command[0], command);
 err(1, execvp %s, command[0]);
 
 Question: was this intentional? I'd rather not break stuff.

It was added in the switch from procfs to ptrace(), but it's not clear why the 
child has a new process group.  It doesn't look like truss ever tries to kill 
the entire group for example.

-- 
John Baldwin
___
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: truss and KSE

2002-11-14 Thread David Xu
What is your revision of kern_thread.c? revision 1.58 should fix this problem.

- Original Message - 
From: Tim Robbins [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, November 14, 2002 9:06 PM
Subject: truss and KSE


 While experimenting with the new libpthread, I found that if you run
 `truss' on a KSE process, both truss and its victim get into a weird
 state and don't respond to TERM, INT or QUIT signals. The truss proc
 dies if you send it the KILL signal, but the victim process cannot be
 killed. Stranger still, it's in the run state but not actually
 performing any work.
 
 I understand that KSE is still an experimental feature but I thought
 this was worth pointing out because it could be used as a local DoS
 and we are nearing 5.0-RELEASE.
 
 
 Tim
 
 To Unsubscribe: send mail to [EMAIL PROTECTED]
 with unsubscribe freebsd-current in the body of the message

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: truss and KSE

2002-11-14 Thread Tim Robbins
On Thu, Nov 14, 2002 at 05:39:12AM -0800, David Xu wrote:

 What is your revision of kern_thread.c? revision 1.58 should fix this problem.

I believe it was 1.57. I'll try with 1.58 and let you know if the problem
is still there.


Tim

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: truss

2002-04-28 Thread Harti Brandt

On Sun, 28 Apr 2002, Richard Arends wrote:

RAHello,
RA
RAOn a fresh current i get this
RA
RA# truss /bin/echo hello
RAtruss: cannot open /proc/13245/mem: No such file or directory
RAtruss: cannot open /proc/curproc/mem: No such file or directory

You need to mount procfs.

harti

RA
RAGreetings,
RA
RARichard.
RA
RA
RAAn OS is like swiss cheese, the bigger it is, the more holes you get!
RA
RA
RATo Unsubscribe: send mail to [EMAIL PROTECTED]
RAwith unsubscribe freebsd-current in the body of the message
RA

-- 
harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private
  [EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: truss

2002-04-28 Thread Riccardo Torrini

On 28-Apr-2002 (17:56:47/GMT) Harti Brandt wrote:

 RAOn a fresh current i get this
 RA# truss /bin/echo hello
 RAtruss: cannot open /proc/13245/mem: No such file or directory
 RAtruss: cannot open /proc/curproc/mem: No such file or directory

 You need to mount procfs.

Mee too message.  I tryed same command, 1st time I got same error.
I checked with df if /proc was mounted and than trussed again and
it show me calls not failing any more.  Some timeout of procfs ?

# uname -v
FreeBSD 5.0-CURRENT #32: Tue Apr 23 08:21:16 CEST 2002 [...]


Riccardo.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: truss

2002-04-28 Thread Richard Arends

On Sun, 28 Apr 2002, Harti Brandt wrote:

 You need to mount procfs.

Oops youre right... Why isn't it listed in /etc/fstab???

Greetings,

Richard.


An OS is like swiss cheese, the bigger it is, the more holes you get!


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: truss

2002-04-28 Thread Kris Kennaway

On Sun, Apr 28, 2002 at 07:46:27PM +0200, Richard Arends wrote:
 Hello,
 
 On a fresh current i get this
 
 # truss /bin/echo hello
 truss: cannot open /proc/13245/mem: No such file or directory
 truss: cannot open /proc/curproc/mem: No such file or directory

procfs is not mounted by default.

Kris



msg37816/pgp0.pgp
Description: PGP signature


Re: truss

2002-04-28 Thread Kris Kennaway

On Sun, Apr 28, 2002 at 08:11:58PM +0200, Riccardo Torrini wrote:
 On 28-Apr-2002 (17:56:47/GMT) Harti Brandt wrote:
 
  RAOn a fresh current i get this
  RA# truss /bin/echo hello
  RAtruss: cannot open /proc/13245/mem: No such file or directory
  RAtruss: cannot open /proc/curproc/mem: No such file or directory
 
  You need to mount procfs.
 
 Mee too message.  I tryed same command, 1st time I got same error.
 I checked with df if /proc was mounted and than trussed again and
 it show me calls not failing any more.  Some timeout of procfs ?

Probably some auto-loading of procfs.ko

Kris



msg37817/pgp0.pgp
Description: PGP signature


Re: truss

2002-04-28 Thread Richard Arends

On Sun, 28 Apr 2002, Kris Kennaway wrote:

 procfs is not mounted by default.

New to current (one day old baby :-), so didn't know that. sorry()

Why isn't it mounted by default??

Greetings,

Richard.


An OS is like swiss cheese, the bigger it is, the more holes you get!


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: truss

2002-04-28 Thread Robert Watson


On Sun, 28 Apr 2002, Richard Arends wrote:

 On Sun, 28 Apr 2002, Kris Kennaway wrote:
 
  procfs is not mounted by default.
 
 New to current (one day old baby :-), so didn't know that. sorry()
 
 Why isn't it mounted by default??

I believe DES has a largely rewritten version of truss that doesn't use
procfs.  When I disabled procfs in sysinstall, I did it thinking that had
already been committed, but it turned out not to have been.  Hopefully
he'll get it finished and committed sometime soon.  The rationale for
disabling procfs is that its functionality is largely redundant to
existing sysctls and debugging mechanisms, and that it has been, and will
likely continue to be, an important source of system security holes.  The
very nature of procfs (mapping one kernel abstraction into another with
different security properties) is part of what makes that likely.  In
fact, if it's not already on the how to harden your system list,
unmounting procfs should be at the top of it :-).  I think truss is one of
the last stragglers that relies on it -- the other is 'ps -e', which
gropes through the memory of each process to dig out the environmental
variables.  This requires that ps both have substantial privilege, and
that procfs be present. 

Robert N M Watson FreeBSD Core Team, TrustedBSD Project
[EMAIL PROTECTED]  NAI Labs, Safeport Network Services



To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: truss

2002-04-28 Thread Kris Kennaway

On Sun, Apr 28, 2002 at 08:49:55PM +0200, Richard Arends wrote:
 On Sun, 28 Apr 2002, Kris Kennaway wrote:
 
  procfs is not mounted by default.
 
 New to current (one day old baby :-), so didn't know that. sorry()
 
 Why isn't it mounted by default??

Numerous and horrendous security vulnerabilities in the past.

Kris



msg37821/pgp0.pgp
Description: PGP signature


Re: truss

2002-04-28 Thread Richard Arends

On Sun, 28 Apr 2002, Robert Watson wrote:

 The rationale for disabling procfs is that its functionality is largely
 redundant to existing sysctls and debugging mechanisms, and that it has
 been, and will likely continue to be, an important source of system
 security holes.

Okay disable it :-)

 I think truss is one of the last stragglers that relies on it --
 the other is 'ps -e', which gropes through the memory of each process to
 dig out the environmental variables.  This requires that ps both have
 substantial privilege, and that procfs be present.

Can't we take the privileges away, so that an user only can see his own
procs and only root can see all??

Greetings,

Richard.


An OS is like swiss cheese, the bigger it is, the more holes you get!



To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: truss

2002-04-28 Thread Robert Watson


On Sun, 28 Apr 2002, Richard Arends wrote:

  I think truss is one of the last stragglers that relies on it --
  the other is 'ps -e', which gropes through the memory of each process to
  dig out the environmental variables.  This requires that ps both have
  substantial privilege, and that procfs be present.
 
 Can't we take the privileges away, so that an user only can see his own
 procs and only root can see all?? 

It's a little more complicated than that.  The problem was that procfs
provided extremely broad access to the system, but without much
granularity.  Mostly this meant that if you had root privilege, you could
do whatever you wanted, and otherwise, you got a reasonable view of the
system (modulo the countless security holes in procfs).  So the problem
was that ps ran with a lot of privilege -- generally root or 'gid kmem'
which amounts to much the same thing.  This meant that gating of process
information happened in the ps command, or at least, with the help of the
ps command deciding not to get around the information gating.  In FreeBSD
4.0, this responsibility happens both in userland and the kernel -- the
kernel makes some effort to limit access via procfs, but largely allows
privileged processes access to most things.  So the ps command implemented
the limit on what processes you could extract environmental information
from. 

In FreeBSD 5.0, all this information is exported from the kernel using the
sysctl() interface, which provides much more information gating, and
flexibe policy controls.  This exists in part in 4.x, but not completely. 
In 5.0, ps requires no special privilege, and access control is done
entirely in the kernel.  However, giving up the ability to grope through
the memory of other processes by giving up procfs does limit that one
capability -- listing environmental variables.  For ps to display this
information, either it has to extract it using a kernel facility (such as
procfs), or the kernel has to extract it and provide it to ps.  So far,
we've had to rule out the first due to the security issues, but the second
hasn't been implemented.  It's not clear there's enough interest in it
that someone has felt motivated to do so.  Patches would be accepted here,
but I think there's some concensus it's not really a necessary feature,
and it also raises a lot of security issues of its own (you'd be surprised
what ends up in environmental variables, and how hard it is to keep policy
in sync between userland and kernel).

BTW, 5.0 will also allow (once we commit the MAC framework from the
TrustedBSD Project) kernel modules to tweak process visibility protections
in the kernel at runtime.  For example, you can kldload a
mac_seeotheruids.ko policy module, which can limit what processes can view
of other processes based on a number of factors, including uids, and
information it tags onto the processes.  It can also limit access to
socket information listed in netstat, etc.

Robert N M Watson FreeBSD Core Team, TrustedBSD Project
[EMAIL PROTECTED]  NAI Labs, Safeport Network Services



To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: truss

2002-04-28 Thread Richard Arends

On Sun, 28 Apr 2002, Robert Watson wrote:

 BTW, 5.0 will also allow (once we commit the MAC framework from the
 TrustedBSD Project) kernel modules to tweak process visibility protections
 in the kernel at runtime.  For example, you can kldload a
 mac_seeotheruids.ko policy module, which can limit what processes can view
 of other processes based on a number of factors, including uids, and
 information it tags onto the processes.  It can also limit access to
 socket information listed in netstat, etc.

When will the TrustedBSD modules commited to current??

Greetings,

Richard.


An OS is like swiss cheese, the bigger it is, the more holes you get!


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: truss

2002-04-28 Thread Robert Watson


On Sun, 28 Apr 2002, Richard Arends wrote:

 On Sun, 28 Apr 2002, Robert Watson wrote:
 
  BTW, 5.0 will also allow (once we commit the MAC framework from the
  TrustedBSD Project) kernel modules to tweak process visibility protections
  in the kernel at runtime.  For example, you can kldload a
  mac_seeotheruids.ko policy module, which can limit what processes can view
  of other processes based on a number of factors, including uids, and
  information it tags onto the processes.  It can also limit access to
  socket information listed in netstat, etc.
 
 When will the TrustedBSD modules commited to current?? 

The current (vague) plan is to commit them around mid-June, but that may
slip a bit depending on development rate.  Early access to the feature set
is possible via Perforce, or from cvsup10.FreeBSD.org.  I'm hoping to have
the basic kernel feature set ready for integration by early June, so we
might integrate back the changes back into the main tree in phases.  I
have to warn you that the stuff in the branch is moving pretty quickly,
and there are some known poor interactions, especially with non-IP
networking types, that we're still tracking down.

Robert N M Watson FreeBSD Core Team, TrustedBSD Project
[EMAIL PROTECTED]  NAI Labs, Safeport Network Services



To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: truss

2002-04-28 Thread Crist J. Clark

On Sun, Apr 28, 2002 at 03:59:44PM -0400, Robert Watson wrote:
[snip]

 In FreeBSD 5.0, all this information is exported from the kernel using the
 sysctl() interface, which provides much more information gating, and
 flexibe policy controls.  This exists in part in 4.x, but not completely. 
 In 5.0, ps requires no special privilege, and access control is done
 entirely in the kernel.

I think I'm missing something here.

  $ uname -r
  4.5-RELEASE
  $ ls -l /bin/ps
  -r-xr-xr-x  1 root  wheel  213796 Jan 30 14:30 /bin/ps

ps(1) has no special privileges in 4.x, but I may not understand what
you mean by special privileges? (To me it means s{u,g}id.)
-- 
Crist J. Clark | [EMAIL PROTECTED]
   | [EMAIL PROTECTED]
http://people.freebsd.org/~cjc/| [EMAIL PROTECTED]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: truss

2002-04-28 Thread Robert Watson


On Sun, 28 Apr 2002, Crist J. Clark wrote:

 On Sun, Apr 28, 2002 at 03:59:44PM -0400, Robert Watson wrote:
 [snip]
 
  In FreeBSD 5.0, all this information is exported from the kernel using the
  sysctl() interface, which provides much more information gating, and
  flexibe policy controls.  This exists in part in 4.x, but not completely. 
  In 5.0, ps requires no special privilege, and access control is done
  entirely in the kernel.
 
 I think I'm missing something here.
 
   $ uname -r
   4.5-RELEASE
   $ ls -l /bin/ps
   -r-xr-xr-x  1 root  wheel  213796 Jan 30 14:30 /bin/ps
 
 ps(1) has no special privileges in 4.x, but I may not understand what
 you mean by special privileges? (To me it means s{u,g}id.)

Hmm.  I'd forgotten that the setgid kmem was removed in 4.x; I was
probably thinking of top, which still is setgid in -STABLE.  You'll find
however, that -e won't work without setgid kmem being turned on.  There
are a number of other tools in -CURRENT that aren't setgid kmem where they
are in -STABLE (top, iostat, etc).

Robert N M Watson FreeBSD Core Team, TrustedBSD Project
[EMAIL PROTECTED]  NAI Labs, Safeport Network Services



To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: truss

2002-04-28 Thread Crist J. Clark

On Sun, Apr 28, 2002 at 05:11:14PM -0400, Robert Watson wrote:
 
 On Sun, 28 Apr 2002, Crist J. Clark wrote:
 
  On Sun, Apr 28, 2002 at 03:59:44PM -0400, Robert Watson wrote:
  [snip]
  
   In FreeBSD 5.0, all this information is exported from the kernel using the
   sysctl() interface, which provides much more information gating, and
   flexibe policy controls.  This exists in part in 4.x, but not completely. 
   In 5.0, ps requires no special privilege, and access control is done
   entirely in the kernel.
  
  I think I'm missing something here.
  
$ uname -r
4.5-RELEASE
$ ls -l /bin/ps
-r-xr-xr-x  1 root  wheel  213796 Jan 30 14:30 /bin/ps
  
  ps(1) has no special privileges in 4.x, but I may not understand what
  you mean by special privileges? (To me it means s{u,g}id.)
 
 Hmm.  I'd forgotten that the setgid kmem was removed in 4.x; I was
 probably thinking of top, which still is setgid in -STABLE.  You'll find
 however, that -e won't work without setgid kmem being turned on.

'-e' for ps(1) seems to work fine on processes you own. You cannot see
the environments of other users' processes (of course root can see
everyone's). But you do need /proc for '-e' to work.

 There
 are a number of other tools in -CURRENT that aren't setgid kmem where they
 are in -STABLE (top, iostat, etc). 

You know, I'm not sure why top(1) needs it if ps(1) doesn't.
-- 
Crist J. Clark | [EMAIL PROTECTED]
   | [EMAIL PROTECTED]
http://people.freebsd.org/~cjc/| [EMAIL PROTECTED]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: truss

2002-04-28 Thread Robert Watson


On Sun, 28 Apr 2002, Crist J. Clark wrote:

  Hmm.  I'd forgotten that the setgid kmem was removed in 4.x; I was
  probably thinking of top, which still is setgid in -STABLE.  You'll find
  however, that -e won't work without setgid kmem being turned on.
 
 '-e' for ps(1) seems to work fine on processes you own. You cannot see
 the environments of other users' processes (of course root can see
 everyone's). But you do need /proc for '-e' to work. 

There might be other criteria where you wish to protect environmental
information, such as for setugid processes, in jail, etc.  Having the
policy in kernel means that you can change it in one place, rather that
tracking through various user space programs (which may not even have all
the information they need).

  There
  are a number of other tools in -CURRENT that aren't setgid kmem where they
  are in -STABLE (top, iostat, etc). 
 
 You know, I'm not sure why top(1) needs it if ps(1) doesn't.

My recollection is that Thomas Moestl had to add a number of sysctl's to
return system information that top previously pulled out of /dev/kmem.
There are two related campaigns here:

(1) Eliminate the requirements for procfs due to the risks involved

There have been a large number of serious vulnerabilities due to the
procfs concept a number of operating systems.  A high percentage of our
local anyone-to-root vulnerabilities have come from procfs.  This combined
with a largely redundant feature set lead to the conclusion that we should
try and phase out the requirement that it be mounted, since a common
hardening technique is to unmount it.

(2) Eliminate the requirements for kmem due to the risks involved

As with procfs, there have been a number of vulnerabilities associated
with kmem, and as with procfs, when a vulnerability is present, the level
of privilege that can be attained is high -- usually root with a little
bit of work.  Eiminating the use of kmem and replacing it with better
defined sysctl APIs also means that the tight userland/kernel dependencies
that used to result in failures during upgrades could be partially
eliminated.  Likewise, policy implemented in userspace could be further
migrated to kernel space (limiting netstat socket display, process
listings, etc). 

In both cases, the actual services themselves are not being eliminated,
since they have uses (especially kmem) in some restricted environments
(such as development), but the general requirement that they be used for
common place activities is being reduced.  A number of utilities still use
kmem, and if anyone wants to pick up the task of converting them over the
sysctl or other mechanisms, they should feel free :-).

Robert N M Watson FreeBSD Core Team, TrustedBSD Project
[EMAIL PROTECTED]  NAI Labs, Safeport Network Services



To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message