Re: mountd will not start at boot. Or function later...
Joesh Juphland wrote: You wouldn't happen to have a portmap_enable=NO line in your rc.conf, would you? No, I do not. Further, I see 'portmap' in the process list, so it is indeed running. ipfw add 1 allow all from any to any -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: anoncvs down?
On Fri, Oct 26, 2001 at 09:15:28AM +0200, Peter Wullinger wrote: Err ... just another dump question: I'm unable to access the anoncvs server ... (using bash) % export CVSROOT=:pserver:[EMAIL PROTECTED]:/home/ncvs % cvs login (Logging in to [EMAIL PROTECTED]) CVS password: cvs [login aborted]: connect to anoncvs.FreeBSD.org:2401 failed: Connection refused ... This is better suited for -hubs; it has actually been under discussion there for the past several days. John D. Polstra, the maintainer of the anoncvs server on that machine, said that the machine was going to be unavailable for another couple of days. In the meantime, other anoncvs mirrors are currently under discussion on -hubs. Rest assured, this problem *is* going to be fixed :) G'luck, Peter -- This sentence would be seven words long if it were six words shorter. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: ipfilter changes in rc.network (was: Re: cvs commit: src/etc rc.network)
In some email I received from Giorgos Keramidas, sie wrote: On Tue, Oct 23, 2001 at 07:45:11PM +0200, Gerhard Sittig wrote: I get the feeling this - inappropriate - setting of a _program variable is due to my misguided suggestion in PR conf/20202 which verbatimly made it into the FreeBSD start scripts. If it doesn't fit the usual rules feel free to correct it! :) After all I was a newbee to FreeBSD then (and still I'm not a guru or seasoned hacker:) as well as I understand Darren to do his daytime job with SunOS / Solaris and since he might need some hints on how his software fits even better into FreeBSD. I guess he will happily accept patches improving a wrong approach. Maybe there's need for the following parts: - ipfilter_program - ipfilter_prerules_flags - ipfilter_rules - ipfilter_postrules_flags ? The current situation comes from the fact that I wanted to have a single variable with the rules file only - to check for its existance (if such an additional constraints check matters). Done. I tested on my -current (compiled on Oct 22) the patch you can find at http://labs.gr/~charon/patches/diff.04.ipf-rc-U It is functionally equivalent to our current rc.network behavior, but it uses the variables you proposed, and it moves all the flags out of all the XXX_program variables. How many of the patches at http://labs.gr/~charon/patches/ should go into FreeBSD-current ? Darren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: how can i wipeout swap pages?
On Thu, 25 Oct 2001, Terry Lambert wrote: To do what you want, which is to clean the backing pages, you Yes, i mean cleaning pages in the backing storage. are better off doing it for all freed blocks, not just swap blocks (if someone can read your swap, they can read other data off your unallocated disk blocks from the FS, as well). I clean UFS freed disk blocks, but i don't know how to do it from swap_pager. :( there are some kva to phisical mapping, which i do not understand. So i thought someone could point me how can write block from swap_pager to the disk or where can i read more info (except McKusicks' book and kernel sources). PS. I can make patch, which wipes files(freed blocks) upon deletion for -current, if someone is interested. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: ipfilter changes in rc.network (was: Re: cvs commit: src/etc rc.network)
In article [EMAIL PROTECTED] you write: How many of the patches at http://labs.gr/~charon/patches/ should go into FreeBSD-current ? Darren I wrote similar patches (see http://home.iae.nl/users/devet/freebsd/) trying to fix more or less the same bugs/problems. Maybe it's a good idea if Giorgos and I together come up with 1 'big' ipfilter /etc/rc.* and rc.conf.5 patch which includes the best parts of both our patches? Arjan -- Arjan de Vet, Eindhoven, The Netherlands [EMAIL PROTECTED] URL: http://www.iae.nl/users/devet/ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Bug in FreeBSD 4.4 in su
ok if you into your freebsd box from somewhere else and type su - root and then type the root password it just hangs there and you think I'm sure I typed the password correctly. So then you u think ok the the SSH session died for some reason try to log back in via ssh and you can't and when you try to ping the machine it appears down but its actually not down because if walk over to the machine down and up the network interface and reapply the firewall rules and then try to ssh to it, it works. which currently means I've no FreeBSD computer until I go and fix it. Getting withdrawl simptons already. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: cvs commit: ports/devel/ORBit Makefile ports/devel/ORBit/files patch-src::IIOP::giop-msg-buffer.c
Ian Dowse wrote: In message [EMAIL PROTECTED], Maxim Sobolev writ es: Nautilus from working properly. The problem disappeared when I've replaced writev(2) call with appropriate loop based around ordinary write(2). Perhaps this should be investigated and the real source of the problem fixed instead, but I do not have a time for this right now. For those who interested I'm ready to provide a step-by step instruction on how to reproduce the bug. Hi, If you have the details handy, a post to -hackers is likely to be quite constructive at getting the problem analysed and resolved. Ok, details are below. GNOME oaf is a CORBA-based RPC framework. It uses UNIX domain sockets to communicate between client application and oafd daemon that serves requests. Usually the communication looks like the following: 1. Client connects to the oafd daemon via domain socket and sends marshalled RPC request. 2. The daemon reads request, demarshalls it and executes either internally or by invoking external program/shared library. 3. The daemon marshalls result of the call and passes it back to the client via the same socket. On the step 3, when marshalling results of the call, daemon creates a large collection of small buffers (usually 5-10 bytes long each) arranged as array of struct iovec and then sends this whole buffer to the client using writev(2) call. In my particular case there were some 2,800 entries in the buffer and when the daemon tried to send it to the client writev(2) was returning -1 and setting errno to be EINVAL, which confused the server and the client causing RPC to fail. To check that all buffers are indeed valid I have replaced writev(2) with a simple loop based around write(2), and the problem disappeared. See http://www.freebsd.org/cgi/cvsweb.cgi/ports/devel/ORBit/files/patch-src%3a%3aIIOP%3a%3agiop-msg-buffer.c for details. I suspect that there is some problem associated with the writev(2)'s handling of EAGAIN (in my write(2)-based replacement I've observed EAGAIN on some 800th element of the buffer). If the problem is confirmed, it should be either fixed, or somehow noted in the manual page. -Maxim To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: cvs commit: ports/devel/ORBit Makefile ports/devel/ORBit/files patch-src::IIOP::giop-msg-buffer.c
On Fri, Oct 26, 2001 at 05:49:08PM +0300, Maxim Sobolev wrote: Ian Dowse wrote: In message [EMAIL PROTECTED], Maxim Sobolev writ es: Nautilus from working properly. The problem disappeared when I've replaced writev(2) call with appropriate loop based around ordinary write(2). Perhaps this should be investigated and the real source of the problem fixed instead, but I do not have a time for this right now. For those who interested I'm ready to provide a step-by step instruction on how to reproduce the bug. Hi, If you have the details handy, a post to -hackers is likely to be quite constructive at getting the problem analysed and resolved. Ok, details are below. GNOME oaf is a CORBA-based RPC framework. It uses UNIX domain sockets to communicate between client application and oafd daemon that serves requests. Usually the communication looks like the following: 1. Client connects to the oafd daemon via domain socket and sends marshalled RPC request. 2. The daemon reads request, demarshalls it and executes either internally or by invoking external program/shared library. 3. The daemon marshalls result of the call and passes it back to the client via the same socket. On the step 3, when marshalling results of the call, daemon creates a large collection of small buffers (usually 5-10 bytes long each) arranged as array of struct iovec and then sends this whole buffer to the client using writev(2) call. In my particular case there were some 2,800 entries in the buffer and when the daemon tried to send it to the client writev(2) was returning -1 and setting errno to be EINVAL, which confused the server and the client causing RPC to fail. 2800 entries? Well, from the writev(2) manual page: In addition, writev() may return one of the following errors: ... [EINVAL] Iovcnt was less than or equal to 0, or greater than UIO_MAXIOV. And at least on -stable, UIO_MAXIOV is defined as 1024.. G'luck, Peter -- Thit sentence is not self-referential because thit is not a word. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: ipfilter changes in rc.network (was: Re: cvs commit: src/etc rc.network)
On Fri, Oct 26, 2001 at 09:21:37PM +1000, Darren Reed wrote: In some email I received from Arjan de Vet, sie wrote: In article [EMAIL PROTECTED] you write: How many of the patches at http://labs.gr/~charon/patches/ should go into FreeBSD-current ? I wrote similar patches (see http://home.iae.nl/users/devet/freebsd/) trying to fix more or less the same bugs/problems. Maybe it's a good idea if Giorgos and I together come up with 1 'big' ipfilter /etc/rc.* and rc.conf.5 patch which includes the best parts of both our patches? That sounds like a good plan. Yep, it sounds very good to me too. I've already got myself a copy of Arjan's diffs since last night that I saw his PR, and we'll probably use mail, IRC or something to work out the details. I have a weekend that I want interesting things to do with, and working on this is a very good idea. Darren, sorry for flooding you in email these last few days. When Arjan and I have come up with something that works nice and smooth, we'll let you know :))) -giorgos To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: cvs commit: ports/devel/ORBit Makefile ports/devel/ORBit/files patch-src::IIOP::giop-msg-buffer.c
Peter Pentchev wrote: On Fri, Oct 26, 2001 at 05:49:08PM +0300, Maxim Sobolev wrote: Ian Dowse wrote: In message [EMAIL PROTECTED], Maxim Sobolev writ es: Nautilus from working properly. The problem disappeared when I've replaced writev(2) call with appropriate loop based around ordinary write(2). Perhaps this should be investigated and the real source of the problem fixed instead, but I do not have a time for this right now. For those who interested I'm ready to provide a step-by step instruction on how to reproduce the bug. Hi, If you have the details handy, a post to -hackers is likely to be quite constructive at getting the problem analysed and resolved. Ok, details are below. GNOME oaf is a CORBA-based RPC framework. It uses UNIX domain sockets to communicate between client application and oafd daemon that serves requests. Usually the communication looks like the following: 1. Client connects to the oafd daemon via domain socket and sends marshalled RPC request. 2. The daemon reads request, demarshalls it and executes either internally or by invoking external program/shared library. 3. The daemon marshalls result of the call and passes it back to the client via the same socket. On the step 3, when marshalling results of the call, daemon creates a large collection of small buffers (usually 5-10 bytes long each) arranged as array of struct iovec and then sends this whole buffer to the client using writev(2) call. In my particular case there were some 2,800 entries in the buffer and when the daemon tried to send it to the client writev(2) was returning -1 and setting errno to be EINVAL, which confused the server and the client causing RPC to fail. 2800 entries? Well, from the writev(2) manual page: In addition, writev() may return one of the following errors: ... [EINVAL] Iovcnt was less than or equal to 0, or greater than UIO_MAXIOV. And at least on -stable, UIO_MAXIOV is defined as 1024.. Ah, ok. I've overlooked it somehow. -Maxim To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: cvs commit: ports/devel/ORBit Makefile ports/devel/ORBit/files patch-src::IIOP::giop-msg-buffer.c
On Fri, Oct 26, 2001 at 06:06:59PM +0300, Maxim Sobolev wrote: Peter Pentchev wrote: On Fri, Oct 26, 2001 at 05:49:08PM +0300, Maxim Sobolev wrote: [snip] On the step 3, when marshalling results of the call, daemon creates a large collection of small buffers (usually 5-10 bytes long each) arranged as array of struct iovec and then sends this whole buffer to the client using writev(2) call. In my particular case there were some 2,800 entries in the buffer and when the daemon tried to send it to the client writev(2) was returning -1 and setting errno to be EINVAL, which confused the server and the client causing RPC to fail. 2800 entries? Well, from the writev(2) manual page: In addition, writev() may return one of the following errors: ... [EINVAL] Iovcnt was less than or equal to 0, or greater than UIO_MAXIOV. And at least on -stable, UIO_MAXIOV is defined as 1024.. Ah, ok. I've overlooked it somehow. So basically, you still want a loop, but it could be a writev(2) loop, not a write(2) loop, to keep some of the writev(2) performance benefit. G'luck, Peter -- If the meanings of 'true' and 'false' were switched, then this sentence wouldn't be false. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: cvs commit: ports/devel/ORBit Makefile ports/devel/ORBit/files patch-src::IIOP::giop-msg-buffer.c
Peter Pentchev wrote: On Fri, Oct 26, 2001 at 06:06:59PM +0300, Maxim Sobolev wrote: Peter Pentchev wrote: On Fri, Oct 26, 2001 at 05:49:08PM +0300, Maxim Sobolev wrote: [snip] On the step 3, when marshalling results of the call, daemon creates a large collection of small buffers (usually 5-10 bytes long each) arranged as array of struct iovec and then sends this whole buffer to the client using writev(2) call. In my particular case there were some 2,800 entries in the buffer and when the daemon tried to send it to the client writev(2) was returning -1 and setting errno to be EINVAL, which confused the server and the client causing RPC to fail. 2800 entries? Well, from the writev(2) manual page: In addition, writev() may return one of the following errors: ... [EINVAL] Iovcnt was less than or equal to 0, or greater than UIO_MAXIOV. And at least on -stable, UIO_MAXIOV is defined as 1024.. Ah, ok. I've overlooked it somehow. So basically, you still want a loop, but it could be a writev(2) loop, not a write(2) loop, to keep some of the writev(2) performance benefit. Yes, I've figured it already, because doing 2,800 syscalls when you can do a 3 instead is a bad idea. :) -Maxim To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: cvs commit: ports/devel/ORBit Makefile ports/devel/ORBit/files patch-src::IIOP::giop-msg-buffer.c
On Fri, Oct 26, 2001 at 06:31:56PM +0300, Maxim Sobolev wrote: Peter Pentchev wrote: On Fri, Oct 26, 2001 at 06:06:59PM +0300, Maxim Sobolev wrote: Peter Pentchev wrote: On Fri, Oct 26, 2001 at 05:49:08PM +0300, Maxim Sobolev wrote: [snip] On the step 3, when marshalling results of the call, daemon creates a large collection of small buffers (usually 5-10 bytes long each) arranged as array of struct iovec and then sends this whole buffer to the client using writev(2) call. In my particular case there were some 2,800 entries in the buffer and when the daemon tried to send it to the client writev(2) was returning -1 and setting errno to be EINVAL, which confused the server and the client causing RPC to fail. 2800 entries? Well, from the writev(2) manual page: In addition, writev() may return one of the following errors: ... [EINVAL] Iovcnt was less than or equal to 0, or greater than UIO_MAXIOV. And at least on -stable, UIO_MAXIOV is defined as 1024.. Ah, ok. I've overlooked it somehow. So basically, you still want a loop, but it could be a writev(2) loop, not a write(2) loop, to keep some of the writev(2) performance benefit. Yes, I've figured it already, because doing 2,800 syscalls when you can do a 3 instead is a bad idea. :) Oh, and BTW - writev(2) can also return EINVAL if the total size exceeds some maximum value (the manual page mentions a 32-bit integer). G'luck, Peter -- I am not the subject of this sentence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Bug in FreeBSD 4.4 in su
On Fri, Oct 26, 2001 at 12:46:00PM +0100, Bri wrote: ok if you into your freebsd box from somewhere else and type su - root and then type the root password it just hangs there and you think I'm sure I typed the password correctly. Are you using a serial console? Or, a defferent question, are you letting syslogd write to /dev/console while you are using a serial console? -- Brian 'you Bastard' Reichert[EMAIL PROTECTED] 37 Crystal Ave. #303Daytime number: (603) 434-6842 Derry NH 03038-1713 USA Intel architecture: the left-hand path To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
dummynet stats
Hi, I seem to get inconsistent outputs from the same dummynet stat query. Following is the output from two different queries : bash-2.05$ bash-2.05$ ipfw pipe 3 show 3: unlimited0 ms 2048 B 0 queues (1 buckets) droptail mask: 0x00 0x/0x - 0x/0x bash-2.05$ bash-2.05$ ipfw pipe 3 show 3: unlimited0 ms 2048 B 1 queues (1 buckets) droptail mask: 0x00 0x/0x - 0x/0x BKT Prot ___Source IP/port Dest. IP/port Tot_pkt/bytes Pkt/Byte Drp 0 icmp 127.0.31.1/0 127.0.31.1/0 3139 1695060 0 0 0 bash-2.05$ The only difference between the two dumps is that a flood ping was stopped and then restated. In both cases, the same ruleset and dummynet pipes were in effect. I am using flood pings for a data stream in both cases. The first dump is after a flush and reinstallation of the pipe rules. The data stream was running while the rules were being installed. The ping was then stopped and restarted followed by the second stat query. My question is why didn't the stats reflect the stream until it had been stopped and restarted ? Rick To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: dummynet stats
On Fri, Oct 26, 2001 at 10:22:48AM -0700, rick norman wrote: Hi, I seem to get inconsistent outputs from the same dummynet stat query. Following is the output from two different queries : bash-2.05$ bash-2.05$ ipfw pipe 3 show 3: unlimited0 ms 2048 B 0 queues (1 buckets) droptail mask: 0x00 0x/0x - 0x/0x bash-2.05$ bash-2.05$ ipfw pipe 3 show 3: unlimited0 ms 2048 B 1 queues (1 buckets) droptail mask: 0x00 0x/0x - 0x/0x BKT Prot ___Source IP/port Dest. IP/port Tot_pkt/bytes Pkt/Byte Drp 0 icmp 127.0.31.1/0 127.0.31.1/0 3139 1695060 0 0 0 bash-2.05$ The only difference between the two dumps is that a flood ping was stopped and then restated. In both cases, the same ruleset and dummynet pipes were in effect. I am using flood pings for a data stream in both cases. The first dump is after a flush and reinstallation of the pipe rules. The data stream was running while the rules were being installed. The ping was then stopped and restarted followed by the second stat query. My question is why didn't the stats reflect the stream until it had been stopped and restarted ? i actually doubt that any traffic went throught he pipe before the first ipfw pipe show or you would have seen it. packets are accounted for immediately as they go through. cheers luigi To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: dummynet stats
I guess my question then is why did I need to stop the stream and restart it before it would show up in the pipe? It seems that if I repeatedly flush, delete pipes, reinstall pipes, without stopping the data stream, that I get into a state where no data will register in the pipes until I stop and restart the stream. Rick Luigi Rizzo wrote: On Fri, Oct 26, 2001 at 10:22:48AM -0700, rick norman wrote: Hi, I seem to get inconsistent outputs from the same dummynet stat query. Following is the output from two different queries : bash-2.05$ bash-2.05$ ipfw pipe 3 show 3: unlimited0 ms 2048 B 0 queues (1 buckets) droptail mask: 0x00 0x/0x - 0x/0x bash-2.05$ bash-2.05$ ipfw pipe 3 show 3: unlimited0 ms 2048 B 1 queues (1 buckets) droptail mask: 0x00 0x/0x - 0x/0x BKT Prot ___Source IP/port Dest. IP/port Tot_pkt/bytes Pkt/Byte Drp 0 icmp 127.0.31.1/0 127.0.31.1/0 3139 1695060 0 0 0 bash-2.05$ The only difference between the two dumps is that a flood ping was stopped and then restated. In both cases, the same ruleset and dummynet pipes were in effect. I am using flood pings for a data stream in both cases. The first dump is after a flush and reinstallation of the pipe rules. The data stream was running while the rules were being installed. The ping was then stopped and restarted followed by the second stat query. My question is why didn't the stats reflect the stream until it had been stopped and restarted ? i actually doubt that any traffic went throught he pipe before the first ipfw pipe show or you would have seen it. packets are accounted for immediately as they go through. cheers luigi To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
system hung with runnable processes
I didn't see anything like this in the archives, so I'm sending this to the questions list and hackers list for assistance. I am running FreeBSD 4.3 on a L440GX+ motherboard with dual PCI buses: 32/33 and 32/66 dual Pentium III @ 700MHz with 256KB L2 cache. The system is running in Uniprocessor mode. Although running the tests on FreeBSD 4.1 has not caused the problem. My problem: I have an application that reads from a SCSI bus, and forwards the SCSI CDB's to another system over TCP. When running a large load the system gets SCSI bus device reset's that the application acknowledges and clears an error bit. After a period of time, in this example about 2.5 hours, the system stops processing any SCSI CDB's. In DDB the ps output show 11 runnable process, p_wchan == 0, and curproc points to one of the processes. However, when checking the run queues via gdb, none of the runnable processes is in a run queue. According to rtqueuebits, queuebits, and idqueuebits, only queue[12] has any runnable processes. Examing the proc structures for the runnable processes, their priority is 6, so they should be in queue[6]. I cannot determine anything obvious in the process scheduling code, but something is happening. I am attaching the system dmesg output from boot to taking the system dump, the ddb output on the serial console, and the output from gdb of the process' stack trace and proc structure. If anyone needs more information just ask and I'll try to get it for you. Does anyone believe upgrading to FreeBSD 4.4 would resolve the problem? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
syslogd and kqueue
If syslogd used the kqueue interface, I believe it could open a new log file as soon as it was created, rather than waiting to receive a signal. Would this be worth doing, or would it be too big a divergence from the traditional behavior? -- Ben An art scene of delight I created this to be ... -- Sun Ra To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: anoncvs down?
On Fri, Oct 26, 2001 at 09:15:28AM +0200, Peter Wullinger wrote: Have I just missed, that anoncvs.FreeBSD.org was shut down? This would be a problem for me since I do not have access to a FreeBSD machine with good internet connection and I didn't get cvsup (i.e. M3) to compile on the machines which I could use to access the CVS repo, so I've at last given up to get a repo copy (of course, if somebody can help ;-) ...). If you had searched the archives, I said: For occational personal use, you may use [EMAIL PROTECTED]:/home/ncvs CVS_RSH=ssh The none ssh encryption method is available. You may use it by adding the appropiate lines to ~/.ssh_config I'd prefer it if people wouldn't overuse this, otherwise I might have to take it away, as the machine has limited bandwidth/resources. The repository syncs via cvsup twice a day. -Jon To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: syslogd and kqueue
On Fri, Oct 26, 2001 at 11:39:57PM +0100, void wrote: If syslogd used the kqueue interface, I believe it could open a new log file as soon as it was created, rather than waiting to receive a signal. Would this be worth doing, or would it be too big a divergence from the traditional behavior? I assume you mean as soon as the configuration file is modified? That would be a big violation of POLA. Kris PGP signature
Re: syslogd and kqueue
void [EMAIL PROTECTED] writes: On Fri, Oct 26, 2001 at 08:04:36PM -0700, Kris Kennaway wrote: I assume you mean as soon as the configuration file is modified? That would be a big violation of POLA. No ... Yes! The traditional log-rotation dance goes something like: mv log log.0 touch log kill -1 `cat /var/run/syslogd.pid` gzip log.0 I'm suggesting that the kill could be left out if syslogd got the same smarts as tail -F. I recommend using newsyslog(8) for rotating log files. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: syslogd and kqueue
Mike Barcroft [EMAIL PROTECTED] writes: void [EMAIL PROTECTED] writes: On Fri, Oct 26, 2001 at 08:04:36PM -0700, Kris Kennaway wrote: I assume you mean as soon as the configuration file is modified? That would be a big violation of POLA. No ... Yes! Just to clarify. This is still a POLA violation. If a log file is pulled out from underneath syslogd(8), one wouldn't expect it to start logging again, even if the file was re-created. Just like one wouldn't expect it to create a new log file. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: syslogd and kqueue
On Sat, Oct 27, 2001 at 12:26:22AM -0400 I heard the voice of Mike Barcroft, and lo! it spake thus: Just to clarify. This is still a POLA violation. If a log file is pulled out from underneath syslogd(8), one wouldn't expect it to start logging again, even if the file was re-created. Just like one wouldn't expect it to create a new log file. Actually, one would. It always takes conscious effort for me to remember that syslog won't create non-existent logfiles. That means I have to go touch a bunch of files when, for instance, I'm setting up a jail(8). It seems extremely counter-intuitive to me that I can't just say Log to this file and have it start logging there, without me laying out a yellow brick road. Forget kqueue. Just an O_CREAT. -- Matthew Fuller (MF4839) |[EMAIL PROTECTED] Unix Systems Administrator |[EMAIL PROTECTED] Specializing in FreeBSD |http://www.over-yonder.net/ The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
