[syslog-ng]syslog-ng 1.5.25 released

[Roberto Nibali]

> 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