Stephen Harris <[EMAIL PROTECTED]>:
> > It was NOT ignored. If syslogd dies, then the system SHOULD stop, after a
>
> Huh? "SHOULD"? Why? If syslog dies for any reason (bug, DOS, hack,
> admin stupidity) then I sure don't want the system freezing up.
Should because this is the only audit
- Received message begins Here -
Jesse Pollard <[EMAIL PROTECTED]>:
> On Sun, 29 Oct 2000, Stephen Harris wrote:
> >Horst von Brand wrote:
> >
> >> > > If you send SIGSTOP to syslogd on a Red Hat 6.2 system (glibc 2.1.3,
> >> > > kernel 2.2.x), within a few minutes you will
- Received message begins Here -
Jesse Pollard [EMAIL PROTECTED]:
On Sun, 29 Oct 2000, Stephen Harris wrote:
Horst von Brand wrote:
If you send SIGSTOP to syslogd on a Red Hat 6.2 system (glibc 2.1.3,
kernel 2.2.x), within a few minutes you will find your entire
Stephen Harris [EMAIL PROTECTED]:
It was NOT ignored. If syslogd dies, then the system SHOULD stop, after a
Huh? "SHOULD"? Why? If syslog dies for any reason (bug, DOS, hack,
admin stupidity) then I sure don't want the system freezing up.
Should because this is the only audit logging
> > It was NOT ignored. If syslogd dies, then the system SHOULD stop, after a
>
> Huh? "SHOULD"? Why? If syslog dies for any reason (bug, DOS, hack,
> admin stupidity) then I sure don't want the system freezing up.
In some cases, I find the syslog messages of more importance then a
working
On Sun, 29 Oct 2000, Jesse Pollard wrote:
> On Sun, 29 Oct 2000, Stephen Harris wrote:
> >Horst von Brand wrote:
> >
> >> > > If you send SIGSTOP to syslogd on a Red Hat 6.2 system (glibc 2.1.3,
> >> > > kernel 2.2.x), within a few minutes you will find your entire machine
> >> > > grinds to a
> It was NOT ignored. If syslogd dies, then the system SHOULD stop, after a
Huh? "SHOULD"? Why? If syslog dies for any reason (bug, DOS, hack,
admin stupidity) then I sure don't want the system freezing up.
( heh... at work on Solaris I monitor 300+ systems, and it's not unusual
to find 1
On Sun, 29 Oct 2000, Stephen Harris wrote:
>Horst von Brand wrote:
>
>> > > If you send SIGSTOP to syslogd on a Red Hat 6.2 system (glibc 2.1.3,
>> > > kernel 2.2.x), within a few minutes you will find your entire machine
>> > > grinds to a halt. For example, nobody can log in.
>>
>> Great! Yet
Horst von Brand wrote:
> > > If you send SIGSTOP to syslogd on a Red Hat 6.2 system (glibc 2.1.3,
> > > kernel 2.2.x), within a few minutes you will find your entire machine
> > > grinds to a halt. For example, nobody can log in.
>
> Great! Yet another way in which root can get the rope to
Horst von Brand wrote:
If you send SIGSTOP to syslogd on a Red Hat 6.2 system (glibc 2.1.3,
kernel 2.2.x), within a few minutes you will find your entire machine
grinds to a halt. For example, nobody can log in.
Great! Yet another way in which root can get the rope to shoot herself
On Sun, 29 Oct 2000, Stephen Harris wrote:
Horst von Brand wrote:
If you send SIGSTOP to syslogd on a Red Hat 6.2 system (glibc 2.1.3,
kernel 2.2.x), within a few minutes you will find your entire machine
grinds to a halt. For example, nobody can log in.
Great! Yet another way in
On Sun, 29 Oct 2000, Jesse Pollard wrote:
On Sun, 29 Oct 2000, Stephen Harris wrote:
Horst von Brand wrote:
If you send SIGSTOP to syslogd on a Red Hat 6.2 system (glibc 2.1.3,
kernel 2.2.x), within a few minutes you will find your entire machine
grinds to a halt. For example,
It was NOT ignored. If syslogd dies, then the system SHOULD stop, after a
Huh? "SHOULD"? Why? If syslog dies for any reason (bug, DOS, hack,
admin stupidity) then I sure don't want the system freezing up.
In some cases, I find the syslog messages of more importance then a
working
[EMAIL PROTECTED] (Stephen Harris) said:
> A lot of talk here has been about syslog and DNS blocking, but the
> original message mentioned:
>
> > If you send SIGSTOP to syslogd on a Red Hat 6.2 system (glibc 2.1.3,
> > kernel 2.2.x), within a few minutes you will find your entire machine
> >
A lot of talk here has been about syslog and DNS blocking, but the
original message mentioned:
> If you send SIGSTOP to syslogd on a Red Hat 6.2 system (glibc 2.1.3,
> kernel 2.2.x), within a few minutes you will find your entire machine
> grinds to a halt. For example, nobody can log in.
Has
A lot of talk here has been about syslog and DNS blocking, but the
original message mentioned:
If you send SIGSTOP to syslogd on a Red Hat 6.2 system (glibc 2.1.3,
kernel 2.2.x), within a few minutes you will find your entire machine
grinds to a halt. For example, nobody can log in.
Has
[EMAIL PROTECTED] (Stephen Harris) said:
A lot of talk here has been about syslog and DNS blocking, but the
original message mentioned:
If you send SIGSTOP to syslogd on a Red Hat 6.2 system (glibc 2.1.3,
kernel 2.2.x), within a few minutes you will find your entire machine
grinds to a
> Sadly, you WILL still lose entries if the system crashes before fs metadata
> has been flushed to disk. Unless the inode has the correct size stored, the
> crap fsync()ed to disk doesn't make much difference.
Yep. I can't really think of a case where you wouldn't lose data in case
of for
> This is not an option for us, unfortunately. Many of our IP addresses
> are dynamically assigned, with the DNS tables dynamically updated.
Not an option in that case.
> Thank you for the patch to syslogd, though! Can you try to get your
> "-x" option into the standard distributions of
On Thu, 26 Oct 2000, Igmar Palsenberg wrote:
>> Per chance are you running the name service caching daemon (nscd)? I'd
>> also guess you aren't disabling fsync() for your sysylog files (it's part
>> of the syslog.conf format) -- this is a conciderable drain on syslogd.
>
>Agree. It is there for
Igmar Palsenberg <[EMAIL PROTECTED]> writes:
> On 23 Oct 2000, Patrick J. LoPresti wrote:
>
> > Not true. The named on our loghost is authoritative for the reverse
> > mappings for all of the machines which can log there.
>
> Put the names of your machines in /etc/hosts on your logmachine.
> Perhaps syslogd is not giving higher priority to local messages; if it
> did, maybe it could recover from the deadlock. But this would not be
> a reliable solution; the only reliable solution is for syslogd to be
> independent of any processes which need to talk to it.
In that case, don't do
> No, I didn't say they "should" be dropped but merely that dropping them
> would fix your problem. Personally, I'd look closely at your setup to
> determine exactly why this has become a problem. named is being blocked
> on writing to /dev/log. This should only happen if there is sufficient
On 23 Oct 2000, Patrick J. LoPresti wrote:
> Jesse Pollard <[EMAIL PROTECTED]> writes:
>
> > Don't configure syslogd to do reverse lookups.
>
> Our syslogd has no option to disable the reverse lookups.
Requires a recompile.
> > You can NEVER guarantee that the reverse lookup will succeed,
> Ulrich Drepper <[EMAIL PROTECTED]> writes:
>
> > If anything has to be changed it's (as suggested) the configuration
> > or even the implementation of syslogd. Make it robust.
>
> OK, but my current syslogd only listens to /dev/log as a SOCK_DGRAM.
> If I wanted reliable syslogging, it
> You obviously don't understand the communication channel being used.
> "/dev/log" is a UNIX DOMAIN SOCKET -- AF_UNIX. Datagrams are unreliable
> for _IP_ (AF_INET). Traffic on an AF_UNIX socket is always reliable.
>
> Ok, smarty, go change the syslogd source to open /dev/log as SOCK_STREAM
On 23 Oct 2000, Patrick J. LoPresti wrote:
> If you send SIGSTOP to syslogd on a Red Hat 6.2 system (glibc 2.1.3,
> kernel 2.2.x), within a few minutes you will find your entire machine
> grinds to a halt. For example, nobody can log in.
>
> This happens because once the /dev/log buffer fills,
You obviously don't understand the communication channel being used.
"/dev/log" is a UNIX DOMAIN SOCKET -- AF_UNIX. Datagrams are unreliable
for _IP_ (AF_INET). Traffic on an AF_UNIX socket is always reliable.
Ok, smarty, go change the syslogd source to open /dev/log as SOCK_STREAM
and
Ulrich Drepper [EMAIL PROTECTED] writes:
If anything has to be changed it's (as suggested) the configuration
or even the implementation of syslogd. Make it robust.
OK, but my current syslogd only listens to /dev/log as a SOCK_DGRAM.
If I wanted reliable syslogging, it would be
On 23 Oct 2000, Patrick J. LoPresti wrote:
Jesse Pollard [EMAIL PROTECTED] writes:
Don't configure syslogd to do reverse lookups.
Our syslogd has no option to disable the reverse lookups.
Requires a recompile.
You can NEVER guarantee that the reverse lookup will succeed, and
can be
No, I didn't say they "should" be dropped but merely that dropping them
would fix your problem. Personally, I'd look closely at your setup to
determine exactly why this has become a problem. named is being blocked
on writing to /dev/log. This should only happen if there is sufficient
Perhaps syslogd is not giving higher priority to local messages; if it
did, maybe it could recover from the deadlock. But this would not be
a reliable solution; the only reliable solution is for syslogd to be
independent of any processes which need to talk to it.
In that case, don't do
Igmar Palsenberg [EMAIL PROTECTED] writes:
On 23 Oct 2000, Patrick J. LoPresti wrote:
Not true. The named on our loghost is authoritative for the reverse
mappings for all of the machines which can log there.
Put the names of your machines in /etc/hosts on your logmachine.
This is not
On Thu, 26 Oct 2000, Igmar Palsenberg wrote:
Per chance are you running the name service caching daemon (nscd)? I'd
also guess you aren't disabling fsync() for your sysylog files (it's part
of the syslog.conf format) -- this is a conciderable drain on syslogd.
Agree. It is there for a reason
Followup to: <[EMAIL PROTECTED]>
By author:Kurt Roeckx <[EMAIL PROTECTED]>
In newsgroup: linux.dev.kernel
>
> On Mon, Oct 23, 2000 at 03:58:39PM -0400, Patrick J. LoPresti wrote:
> > "David S. Miller" <[EMAIL PROTECTED]> writes:
> >
> > > SOCK_DGRAM over AF_UNIX is reliable, it's a local
Followup to: [EMAIL PROTECTED]
By author:Kurt Roeckx [EMAIL PROTECTED]
In newsgroup: linux.dev.kernel
On Mon, Oct 23, 2000 at 03:58:39PM -0400, Patrick J. LoPresti wrote:
"David S. Miller" [EMAIL PROTECTED] writes:
SOCK_DGRAM over AF_UNIX is reliable, it's a local transport.
- Received message begins Here -
>
> Jesse Pollard <[EMAIL PROTECTED]> writes:
>
> > Don't configure syslogd to do reverse lookups.
>
> Our syslogd has no option to disable the reverse lookups.
>
> > You can NEVER guarantee that the reverse lookup will succeed, and
> > can
On Mon, Oct 23, 2000 at 04:56:26PM -0400, Patrick J. LoPresti wrote:
> You are effectively suggesting that named should be rewritten not to
> use the glibc syslog functions at all. That strikes me as the worst
> suggestion so far; it would be far better for syslogd not to do name
>
On 23 Oct 2000, Patrick J. LoPresti wrote:
>Once the name resolution times out, you might expect things to become
>unstuck. But they don't.
Negative. Things have been queued. The deadlock will only go away if the
very next message processed is the named local message. And then it would
have
Ricky Beam <[EMAIL PROTECTED]> writes:
> Personally, I'd look closely at your setup to determine exactly why
> this has become a problem. named is being blocked on writing to
> /dev/log. This should only happen if there is sufficient _local_
> syslog traffic to fill the buffer or syslogd has
On 23 Oct 2000, Patrick J. LoPresti wrote:
>So I have the glibc maintainer (and others) saying that syslog
>messages should never be dropped, and you saying that named should be
>dropping its syslog messages.
No, I didn't say they "should" be dropped but merely that dropping them
would fix your
Ricky Beam <[EMAIL PROTECTED]> writes:
> syslogd isn't the blocker. The syslog functions in glibc being
> called by named are the problem. Stop named from blocking on syslog
> writes and the world will be happy again.
So I have the glibc maintainer (and others) saying that syslog
messages
On 23 Oct 2000, Patrick J. LoPresti wrote:
>Turning down the DNS timeout would affect *all* name resolution on the
>system, right? That is not acceptable.
You should be able to set it on a per-process basis (via an ENV var.)
>As I said, I already have a workaround, which is to have named log
Ricky Beam <[EMAIL PROTECTED]> writes:
> I would suggest disabling name resolution for syslog, but that's an
> ugly option. There's no way to stop a glibc system from doing a DNS
> query for a reverse lookup. HOWEVER, you can set the DNS timeout to
> 1 second and set the resolver options to
On 23 Oct 2000, Patrick J. LoPresti wrote:
>Ulrich Drepper <[EMAIL PROTECTED]> writes:
>> If anything has to be changed it's (as suggested) the configuration
>> or even the implementation of syslogd. Make it robust.
>
>OK, but my current syslogd only listens to /dev/log as a SOCK_DGRAM.
>If I
[EMAIL PROTECTED] (Patrick J. LoPresti) writes:
> OK, but my current syslogd only listens to /dev/log as a SOCK_DGRAM.
> [...]
I don't care what the current syslogd does. Changing the libc just to
work around the limitations of current implementations is wrong.
Write a new syslogd and do it
Ulrich Drepper <[EMAIL PROTECTED]> writes:
> If anything has to be changed it's (as suggested) the configuration
> or even the implementation of syslogd. Make it robust.
OK, but my current syslogd only listens to /dev/log as a SOCK_DGRAM.
If I wanted reliable syslogging, it would be listening
Jesse Pollard <[EMAIL PROTECTED]> writes:
> It's not a bug, but a security feature. NO log to syslogd should be lost,
> since it may be related to an attack.
That's exactly the argument I'm always using to turn down change
requests like this. If the syslog() function could drop an entry and
Jesse Pollard <[EMAIL PROTECTED]> writes:
> Don't configure syslogd to do reverse lookups.
Our syslogd has no option to disable the reverse lookups.
> You can NEVER guarantee that the reverse lookup will succeed, and
> can be delayed several minutes for a single reply.
Not true. The named on
[EMAIL PROTECTED] (Patrick J. LoPresti):
>
> If you send SIGSTOP to syslogd on a Red Hat 6.2 system (glibc 2.1.3,
> kernel 2.2.x), within a few minutes you will find your entire machine
> grinds to a halt. For example, nobody can log in.
>
> This happens because once the /dev/log buffer fills,
[EMAIL PROTECTED] (Patrick J. LoPresti):
If you send SIGSTOP to syslogd on a Red Hat 6.2 system (glibc 2.1.3,
kernel 2.2.x), within a few minutes you will find your entire machine
grinds to a halt. For example, nobody can log in.
This happens because once the /dev/log buffer fills, the
Jesse Pollard [EMAIL PROTECTED] writes:
Don't configure syslogd to do reverse lookups.
Our syslogd has no option to disable the reverse lookups.
You can NEVER guarantee that the reverse lookup will succeed, and
can be delayed several minutes for a single reply.
Not true. The named on our
Jesse Pollard [EMAIL PROTECTED] writes:
It's not a bug, but a security feature. NO log to syslogd should be lost,
since it may be related to an attack.
That's exactly the argument I'm always using to turn down change
requests like this. If the syslog() function could drop an entry and
not
Ulrich Drepper [EMAIL PROTECTED] writes:
If anything has to be changed it's (as suggested) the configuration
or even the implementation of syslogd. Make it robust.
OK, but my current syslogd only listens to /dev/log as a SOCK_DGRAM.
If I wanted reliable syslogging, it would be listening on
On 23 Oct 2000, Patrick J. LoPresti wrote:
Ulrich Drepper [EMAIL PROTECTED] writes:
If anything has to be changed it's (as suggested) the configuration
or even the implementation of syslogd. Make it robust.
OK, but my current syslogd only listens to /dev/log as a SOCK_DGRAM.
If I wanted
Ricky Beam [EMAIL PROTECTED] writes:
I would suggest disabling name resolution for syslog, but that's an
ugly option. There's no way to stop a glibc system from doing a DNS
query for a reverse lookup. HOWEVER, you can set the DNS timeout to
1 second and set the resolver options to prevent
On 23 Oct 2000, Patrick J. LoPresti wrote:
Turning down the DNS timeout would affect *all* name resolution on the
system, right? That is not acceptable.
You should be able to set it on a per-process basis (via an ENV var.)
As I said, I already have a workaround, which is to have named log to
a
Ricky Beam [EMAIL PROTECTED] writes:
syslogd isn't the blocker. The syslog functions in glibc being
called by named are the problem. Stop named from blocking on syslog
writes and the world will be happy again.
So I have the glibc maintainer (and others) saying that syslog
messages should
On 23 Oct 2000, Patrick J. LoPresti wrote:
So I have the glibc maintainer (and others) saying that syslog
messages should never be dropped, and you saying that named should be
dropping its syslog messages.
No, I didn't say they "should" be dropped but merely that dropping them
would fix your
Ricky Beam [EMAIL PROTECTED] writes:
Personally, I'd look closely at your setup to determine exactly why
this has become a problem. named is being blocked on writing to
/dev/log. This should only happen if there is sufficient _local_
syslog traffic to fill the buffer or syslogd has too
On 23 Oct 2000, Patrick J. LoPresti wrote:
Once the name resolution times out, you might expect things to become
unstuck. But they don't.
Negative. Things have been queued. The deadlock will only go away if the
very next message processed is the named local message. And then it would
have to
On Mon, Oct 23, 2000 at 04:56:26PM -0400, Patrick J. LoPresti wrote:
You are effectively suggesting that named should be rewritten not to
use the glibc syslog functions at all. That strikes me as the worst
suggestion so far; it would be far better for syslogd not to do name
lookups.
62 matches
Mail list logo
