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 log
- 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
> > 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 ha
> 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 b
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 shoo
[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
> > grin
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 t
> 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 exam
> 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 sysl
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
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.
Thi
> 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, 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
> 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,
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 tra
- 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 b
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.
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 t
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 to
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 p
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 shou
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
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 pre
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 wan
[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 rig
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 o
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
no
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,
34 matches
Mail list logo
