David O'Brien wrote:
If it created the file itself, there would be a potential
race issue that would remain unresolved, which is hidden by
the seperation of the create and the subsequent signal.
Come again?
1. syslogd calls open(2) with O_CREAT. At this point syslogd happily
David O'Brien wrote:
On Mon, Oct 29, 2001 at 08:35:35AM -0800, Terry Lambert wrote:
No muss, no fuss. So where is the race?
Mike had the only justification so far -- that of permissions of the
file.
Think multiple instances of syslogd.
You are going to have to help me out a
On Sun, Oct 28, 2001 at 07:40:34PM -0800, Terry Lambert wrote:
The _useful_ thing to do would be to roll the newsyslog
functionality into syslogd; however, as a .conf file that
is expected to be distributed over NIS, I think that doing
the syntax change is probably a bad idea...
After seeing
On Mon, Oct 29, 2001 at 01:16:29PM -0500, Leo Bicknell wrote:
On Sun, Oct 28, 2001 at 07:40:34PM -0800, Terry Lambert wrote:
The _useful_ thing to do would be to roll the newsyslog
functionality into syslogd; however, as a .conf file that
is expected to be distributed over NIS, I think
On Mon, Oct 29, 2001 at 09:42:19AM -0800, Terry Lambert wrote:
David O'Brien wrote:
On Mon, Oct 29, 2001 at 08:35:35AM -0800, Terry Lambert wrote:
No muss, no fuss. So where is the race?
Mike had the only justification so far -- that of permissions of the
file.
Think
David O'Brien wrote:
On Sat, Oct 27, 2001 at 12:26:22AM -0400, Mike Barcroft wrote:
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.
I disagree, if
* Michael Sinz [EMAIL PROTECTED] [011029 14:07] wrote:
This has bitten a number of support people - a server fills up and they
get a bit too loose with the rm command and logging stops.
I actually somewhat understand why syslogd does not open/create the file
using the current syslog.conf
Garance A Drosihn wrote:
Until newsyslog is fixed to not be able to stage a
denial of service attack against you, I really, really
recommend against its use.
Seems like it would be more user-friendly (to freebsd users
in general) to fix newsyslog, instead of just telling people
that they
On Sat, Oct 27, 2001 at 12:26:22AM -0400, Mike Barcroft wrote:
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.
I disagree, if the file was re-created.
David O'Brien [EMAIL PROTECTED] writes:
Actually, I find it weird and counter intuitive that syslogd will not
log to the files in the config file (/etc/syslog.conf) unless they
already exists. It really feels like we are living with a programming
bug 25 years later
If I didn't want
David O'Brien wrote:
Actually, I find it weird and counter intuitive that syslogd will not
log to the files in the config file (/etc/syslog.conf) unless they
already exists. It really feels like we are living with a programming
bug 25 years later
If I didn't want syslogd to log
On Sun, Oct 28, 2001 at 07:40:34PM -0800, Terry Lambert wrote:
By using the rename/create/signal approach, syslogd is
guaranteed to log new messages to the old file, despite the
rename, until signalled to close and reopen the file (or a
new file of another name, if syslog.conf is changed).
David O'Brien wrote:
| On Sun, Oct 28, 2001 at 07:40:34PM -0800, Terry Lambert wrote:
| By using the rename/create/signal approach, syslogd is
| guaranteed to log new messages to the old file, despite the
| rename, until signalled to close and reopen the file (or a
| new file of another name,
On Fri, Oct 26, 2001 at 11:25:43PM -0500, Matthew D. Fuller wrote:
Forget kqueue. Just an O_CREAT.
For log rotation anyway. It might make sense to use kqueue within syslogd
instead of select for waiting on messages from the kernel, the logging
socket and udp port 514.
David
Kris Kennaway wrote:
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
Mike Barcroft wrote:
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.
I recommend _NOT_ using newsyslog for rotating files.
The newsyslog program bit us on the ass numerous times at
Whistle,
void wrote:
On Fri, Oct 26, 2001 at 08:04:36PM -0700, Kris Kennaway wrote:
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
At 11:29 AM -0700 10/27/01, Terry Lambert wrote:
Mike Barcroft wrote:
I recommend using newsyslog(8) for rotating log files.
I recommend _NOT_ using newsyslog for rotating files.
The problem is that newsyslog doesn't rewrite history.
As an example, say you have [...]
Now you can only rotate
On Sun, Oct 28, 2001 at 12:22:40AM +0200, Cyrille Lefevre wrote:
The traditional log-rotation dance goes something like:
mv log log.0
touch log
never do a mv/touch on a log file to avoid full filled file systems,
use cp instead...
cp log log.0
(there is a delta here which can be
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
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
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
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
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
24 matches
Mail list logo
