here ya go. if you'd like, i can also attach the RPMS i built of libol (0.3.7) and syslog-ng (1.5.25)

-----Original Message----- From: syslog-ng-admin@lists.balabit.hu [mailto:syslog-ng-admin@lists.balabit.hu]On Behalf Of Balazs Scheidler Sent: Tuesday, January 21, 2003 5:49 AM To: syslog-ng@lists.balabit.hu Subject: Re: [syslog-ng]syslog-ng 1.5.25 released

On Mon, Jan 20, 2003 at 03:41:27PM -0500, Blaise St-Laurent wrote:

...

strangely enough, i can't get this version to work for me at all. 1.5.24 worked fine. I've compiled both the new syslog-ng and libol, installed (via RPM) as a drop in replacement for 1.5.24, and as a result i don't get any log output. reverting back to 1.5.24 restores functionality.

Built and running on a Redhat 8.0 system. Any ideas?

can you send me an strace output? it worked for me on a couple of test cases and Nate also uses it as this version includes the 'bad_hostnames' feature he was asking for.

...

BTW would anyone object to me packaging the contrib initscript

and default

...

config into the spec file? that way anyone building the RPM would have an out of the box functioning system.

This requires two additional changes: the spec file would create /etc/syslog-ng and put the conf file in there. the spec file would copy a syslog-ng file into /etc/sysconfig whose contents are SYSLOGNG_OPTIONS="-f /etc/syslog-ng/syslog-ng.conf"

Send me an updated .spec file (patch preferred) and I add it to my tree.

-- Bazsi PGP info: KeyID 9AF8D0A9 Fingerprint CD27 CFB0 802C 0944 9CFD 804E C82C 8EB1

_______________________________________________ syslog-ng maillist - syslog-ng@lists.balabit.hu https://lists.balabit.hu/mailman/listinfo/syslog-ng Frequently asked questions at http://www.campin.net/syslog-ng/faq.html

On Mon, Jan 20, 2003 at 03:41:27PM -0500, Blaise St-Laurent wrote:

...

strangely enough, i can't get this version to work for me at all. 1.5.24 worked fine. I've compiled both the new syslog-ng and libol, installed (via RPM) as a drop in replacement for 1.5.24, and as a result i don't get any log output. reverting back to 1.5.24 restores functionality.

Built and running on a Redhat 8.0 system. Any ideas?

can you send me an strace output? it worked for me on a couple of test cases and Nate also uses it as this version includes the 'bad_hostnames' feature he was asking for.

Confirmed on Mandrake 9.0 with glibc-2.2.5-16mdk. It simple does not get any messages and sits there in poll. Strace and config attached. -andrey

Thanks. I've found the problem, it is in libol and was committed independently of my syslog-ng release. Here is the fix, I'll release a new libol ASAP.

Is it possible to change configure to require libol >= 0.3.8? -andrey

...

Would you care to explain to me this fix, please? As I read it, it only kicks in in case write(2) returns with a 0. But this 0 doesn't mean 0 bytes have been written, but something else. I'm a bit confused. Keep in mind that I haven't read your code all too well yet ;).

check fd_write in libol/src/io.c, which handles EINTR and EAGAIN and returns 0 instead of -1 for those reasons.

I see, thanks for the pointer (I'm surprised EWOULDBLOCK is portable enough). Additional question: Have you or anyone else done any tests with O_SYNC or mounting the log partition with noatime? I'm asking because I'm trying to isolate a performance issue on a central loghost.

thanks for the report.

I should also like to ask you about the status of the template() patch [1] done by one of my team mates. He's not working on this project anymore and I've taken over. If I get around to fix your concerns mentioned in [2], would you still consider it for inclusion into 1.6.0? [1] https://lists.balabit.hu/pipermail/syslog-ng/2002-September/003839.html [2] https://lists.balabit.hu/pipermail/syslog-ng/2002-October/004047.html Best regards, Roberto Nibali, ratz -- echo '[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq' | dc

Syslog-ng has been running on a couple of Unixes and nobody complained about EWOULDBLOCK. I think it is defined as EAGAIN on most platforms.

It should be, yes, though it wouldn't hurt to add both to the list. I simply mention it because the GNU libc manual reads: - Macro: int EAGAIN Resource temporarily unavailable; the call might work if you try again later. The macro `EWOULDBLOCK' is another name for `EAGAIN'; they are always the same in the GNU C library. This error can happen in a few different situations: * An operation that would block was attempted on an object that has non-blocking mode selected. Trying the same operation again will block until some external condition makes it possible to read, write, or connect (whatever the operation). You can use `select' to find out when the operation will be possible; *note Waiting for I/O::. *Portability Note:* In many older Unix systems, this condition was indicated by `EWOULDBLOCK', which was a distinct error code different from `EAGAIN'. To make your program portable, you should check for both codes and treat them the same. * A temporary resource shortage made an operation impossible. `fork' can return this error. It indicates that the shortage is expected to pass, so your program can try the call again later and it may succeed. It is probably a good idea to delay for a few seconds before trying it again, to allow time for other processes to release scarce resources. Such shortages are usually fairly serious and affect the whole system, so usually an interactive program should report the error to the user and return to its command loop. - Macro: int EWOULDBLOCK In the GNU C library, this is another name for `EAGAIN' (above). The values are always the same, on every operating system. C libraries in many older Unix systems have `EWOULDBLOCK' as a separate error code. But this is up to you and I guess after so many years without problems one can safely assume that it definitely doesn't matter.

O_SYNC would certainly increase your load. noatime could help though.

I checked with O_SYNC because I wanted to fix the truncated messages. Now I have libol-0.3.8.

Checking the output of vmstat (disk i/o, swap i/o, system and user cpu time spent) usually helps locating performance issues.

I am going to do such profiling. In the meantime I've realized that fiddling around with the buffer_size can already improve things to a certain degree.

...

I should also like to ask you about the status of the template() patch [1] done by one of my team mates. He's not working on this project anymore and I've taken over. If I get around to fix your concerns mentioned in [2], would you still consider it for inclusion into 1.6.0?

Today I to him on the phone and he told me that he'd be willing to have a look at it until next week. We (probably he) shall submit it by the end of next week. Since he's more familiar with it I reckon this is a good plan. I have one last question to bother you. I'm scanning through your code and I've found following code snippet in src/afinet.c:do_init_afinet_dest(...): self->conn_fd = io_connect(cfg->backend, fd, self->super.dest_addr, make_afsocket_dest_connected(cfg->backend, &self->super)); if (self->conn_fd) { return ST_OK | ST_GOON; } else { if (errno == ECONNREFUSED) { ^^^^^^^^^^^^^^^^^^^^^^^^^^ This yields different behaviour on Linux and Solaris for link state down and primary link flushed interfaces. io_callout(self->cfg->backend, self->cfg->time_reopen, make_driver_reinit(&self->super.super.super, self->cfg)); return ST_OK | ST_GOON; } werror("Error creating AF_INET socket (%z)\n", strerror(errno)); } return ST_FAIL | ST_QUIT; I'm talking about the ECONNREFUSED. Why do you only _reinit() when you get a connection refused and not all the time? Consider following usage: You start syslog-ng before the interface is up (link state up and primary address assigned). In your case you'd do no new _reinit(). What's the hitch in removing this 'if'-part? I apologise to the list if this has been discussed before and humbly ask for pointers because I couldn't find any discussing this problem. Regards, Roberto Nibali, ratz -- echo '[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq' | dc

IIRC I tried but gcc then complained I have two case statements in my switch with the same value.

Yes, that's correct. You'd probably need to add something along the lines of: #ifndef __GNUC__ EWOULDBLOCK: #else EAGAIN: #endif Anyway, it's not important.

This case was added especially to handle Solaris. The fd here is set into non-blocking mode in which case Linux _always_ returns EINPROGRESS, the poll loop then checks for writability and calls the callback for afsocket_dest_connected. (probably defined in afsocket.c)

Exactly.

On the other hand Solaris returned ECONNREFUSED when connecting to a local socket immediately regardless whether the fd was set into non-blocking mode.

Oh, didn't know that.

Thus I reinit when I get ECONNREFUSED or in the connected callback called from the main loop.

Ok.

Syslog-ng currently does not start if initialization fails. If the interface is not up or the routing table not complete syslog-ng might not start.

That's what I mean, yes. As you state below you will not change this anymore, so I guess I have to patch my local copy of syslog-ng then for my purposes ;).

This was intended at the time I implemented this code. This decision might not be the best but I wouldn't bother fixing those as I am currently rewriting syslog-ng from scratch. (see my announcement about the 1.9.x branch)

I know I said 'last question ...' and so forth but do you have a architecture plan for syslog-ng 2.0.0? Why is there the big rewrite, once I got familiar with the code? :) Thanks for the information so far and have a nice weekend, Roberto Nibali, ratz -- echo '[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq' | dc

Why not

#if EWOULDBLOCK != EAGAIN case EAGAIN: #endif case EWOULDBLOCK:

That of course works too (is probably even neater), but as it has already been stated, there's no problem at all with the author's original implementation. Regards, Roberto Nibali, ratz -- echo '[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq' | dc