Re: New kevent types: NOTE_STARTEXEC and NOTE_STOPEXEC

2002-10-26 Thread Nate Lawson
On Thu, 24 Oct 2002, Maxim Sobolev wrote:
> Please review the patch, which adds two new types of events -
> NOTE_STARTEXEC and NOTE_STOPEXEC, that could be used to get
> notification when the image starts or stops executing. For example, it
> could be used to monitor that a daemon is up and running and notify
> administrator when for some reason in exits. I am running this code
> for more than a year now without any problems.
> 
> Any comments and suggestions are welcome.

Couldn't this just be done by init(8) and /etc/ttys?  Or inetd?  If you
want to write your own, couldn't you use waitpid()?  Or a kevent() of
EVFILT_PROC with NOTE_EXIT/NOTE_FORK?  I'm not sure I see the need for
this.

Comments below.

> +.It NOTE_STOPEXEC
> +Execution of the file referenced by the descriptor ended.  Triggered
> when
> +the process associated with the file exited or was replaced with anoter
> +image using
> +.Xr execve 2
> +or simial syscall.  The PID of the process is returned in
  ^
typo

> Index: src/sys/sys/event.h
> ===
> RCS file: /home/ncvs/src/sys/sys/event.h,v
> retrieving revision 1.21
> diff -d -u -r1.21 event.h
> --- src/sys/sys/event.h   29 Jun 2002 19:14:52 -  1.21
> +++ src/sys/sys/event.h   24 Oct 2002 06:57:41 -
> @@ -83,13 +83,15 @@
>  /*
>   * data/hint flags for EVFILT_VNODE, shared with userspace
>   */
> -#define  NOTE_DELETE 0x0001  /* vnode was removed */
> -#define  NOTE_WRITE  0x0002  /* data contents changed */
> -#define  NOTE_EXTEND 0x0004  /* size increased */
> -#define  NOTE_ATTRIB 0x0008  /* attributes changed */
> -#define  NOTE_LINK   0x0010  /* link count changed */
> -#define  NOTE_RENAME 0x0020  /* vnode was renamed */
> -#define  NOTE_REVOKE 0x0040  /* vnode access was revoked */
> +#define  NOTE_DELETE 0x0010  /* vnode was removed */
> +#define  NOTE_WRITE  0x0020  /* data contents changed */
> +#define  NOTE_EXTEND 0x0040  /* size increased */
> +#define  NOTE_ATTRIB 0x0080  /* attributes changed */
> +#define  NOTE_LINK   0x0100  /* link count changed */
> +#define  NOTE_RENAME 0x0200  /* vnode was renamed */
> +#define  NOTE_REVOKE 0x0400  /* vnode access was revoked */
> +#define  NOTE_STARTEXEC  0x0800  /* vnode was executed */
> +#define  NOTE_STOPEXEC   0x1000  /* vnode execution stopped */
> +/* Applies both to EVFILT_VNODE and EVFILT_PROC */
>  #define  NOTE_PDATAMASK  0x000f  /* mask for pid */

I don't think we should burn our 32 bits on this.  Since pids are 32 bits,
this interface will fail unpredictably.

>  /* additional flags for EVFILT_PROC */
> Index: src/sys/kern/kern_exec.c
> ===
> RCS file: /home/ncvs/src/sys/kern/kern_exec.c,v
> retrieving revision 1.193
> diff -d -u -r1.193 kern_exec.c
> --- src/sys/kern/kern_exec.c  11 Oct 2002 21:04:01 -  1.193
> +++ src/sys/kern/kern_exec.c  24 Oct 2002 06:57:41 -
> @@ -518,6 +518,8 @@
>* to locking the proc lock.
>*/
>   textvp = p->p_textvp;
> + if (textvp)
> + VN_KNOTE(textvp, NOTE_STOPEXEC | p->p_pid);
>   p->p_textvp = ndp->ni_vp;

Do these always stay an int or are there casts that could result in endian
problems?

>Index: src/sys/kern/kern_fork.c
>===
>RCS file: /home/ncvs/src/sys/kern/kern_fork.c,v
>retrieving revision 1.172
>diff -d -u -r1.172 kern_fork.c
>--- src/sys/kern/kern_fork.c   18 Oct 2002 17:45:41 -  1.172
>+++ src/sys/kern/kern_fork.c   24 Oct 2002 06:58:03 -
>@@ -724,6 +724,8 @@
>* tell any interested parties about the new process
>*/
>   KNOTE(&p1->p_klist, NOTE_FORK | p2->p_pid);
>+  if (p2->p_textvp != NULL)
>+  VN_KNOTE(p2->p_textvp, NOTE_STARTEXEC | p2->p_pid);
>   PROC_UNLOCK(p1);
> 
>   /*

This shows my doubt for the need for this since the NOTE_FORK is immediately
before your duplicate NOTE_STARTEXEC.

-Nate


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



Re: sfbuf problems

2002-10-26 Thread Mike Silbersack

On Thu, 24 Oct 2002, Ian Campbell wrote:

> I tried a hack sendfile replacement with write() and lseek(), just
> to see if that made a difference... but all it did was chew mbufs
> instead of sf_bufs ... How can I tell if I'm just using all available
> buffer space, or if it's just a leak I'm not seeing? How can I increase
> available kvm if it becomes necessary?

Once you shutdown the server, does netstat -na show all the connections
dying off, and does netstat -m show mbuf usage dropping back to normal?
If connections die off properly and the number of mbufs drops back to
normal, then there is probably no leak.

During normal usage, it is entirely possible to max out mbuf usage without
there being a memory leak.

Mike "Silby" Silbersack


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



size of a named pipe

2002-10-26 Thread Michael Smirnov
My scripts read data from a named pipe,
created using "mkfifo".
I'm trying to way a way 
to monitor how many bytes are currently written, but not read from it?
Unfortunately size of that pipe is always 0. :-(((

I need it to know if my script is fast enough, so the writer process
isn't forced to wait.

FreeBSD 4.4-Release.





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



[About SA_SIGINFO] Getting signal sender's PID and RUID

2002-10-26 Thread Leslie Jackson
I tried to use sigaction(with SA_SIGINFO sa_flags sepecified) to obtain the
catched signal's sending process ID and its real user ID. But all that i got
are both zeros.

Flatform: FreeBSD 4.6-Release on x86.

--8<--
#include 
#include 
#include 
#include 
#include 

static void sig_usr1(int, siginfo_t *, void *);

int main(void)
{
struct sigactionact;

memset(&act, 0, sizeof(act));
act.sa_flags = SA_SIGINFO;
act.sa_sigaction = sig_usr1;

if (sigaction(SIGUSR1, &act, NULL) < 0) {
perror("sigaction error");
exit(1);
}

sleep(3);
kill(getpid(), SIGUSR1);

return 0;
}

static void sig_usr1(int signo, siginfo_t *info, void *ptr)
{
printf("Got SIGUSR1\n");
printf("sending process ID: %d\n", info->si_pid);
printf("sending process real user ID: %d\n", info->si_uid);
}
--8<--

Anything i've missed? Are there any alternative ways?

Any insights would be appreciated. TIA. :-)

-- 
Leslie Jackson

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



[no subject]

2002-10-26 Thread LexSys
Hello freebsd-hackers,

  

-- 
Best regards,
 LexSys  mailto:lexsys@;zgia.zp.ua


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