Loading ...
Sorry, an error occurred while loading the content.

Re: New document: STRESS_README

Expand Messages
  • Andreas Grimm
    Hello Victor, i traced the anvil process after increasing to 2000 procs, i had to wait for an attack. These are the last lines: alarm(6000)
    Message 1 of 38 , Nov 1, 2007
    • 0 Attachment
      Hello Victor,

      i traced the anvil process after increasing to 2000 procs, i had to wait for an attack. These are the last lines:

      alarm(6000)                             = 6000
      time(NULL)                              = 1193908489
      epoll_wait(8, {{EPOLLIN, {u32=361, u64=13829101863355548009}}, {EPOLLIN, {u32=155, u64=13829101863355547803}}, {EPOLLIN, {u32=1173, u64=13829101863355548821}}}, 100, 1000) = 3
      time(NULL)                              = 1193908489
      ioctl(361, FIONREAD, [43])              = 0
      write(5, "\3137\0\0\34\0\0\0\0\0\0\0", 12) = 12
      poll([{fd=361, events=POLLIN, revents=POLLIN}], 1, 3600000) = 1
      read(361, "request=disconnect\nident=smtp:59"..., 4096) = 43
      gettimeofday({1193908489, 431172}, NULL) = 0
      poll([{fd=361, events=POLLOUT, revents=POLLOUT}], 1, 3600000) = 1
      write(361, "status=0\n\n", 10)          = 10
      gettimeofday({1193908489, 431256}, NULL) = 0
      write(5, "\3137\0\0\34\0\0\0\1\0\0\0", 12) = -1 ECONNRESET (Connection reset by peer)
      time(NULL)                              = 1193908492
      stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=837, ...}) = 0
      stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=837, ...}) = 0
      stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=837, ...}) = 0
      send(7, "<22>Nov  1 10:14:52 postfthoseix/anvi"..., 123, MSG_NOSIGNAL) = 123
      time(NULL)                              = 1193908496
      stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=837, ...}) = 0
      stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=837, ...}) = 0
      stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=837, ....}) = 0
      send(7, "<22>Nov  1 10:14:56 postfix/anvi"..., 121, MSG_NOSIGNAL) = 121
      time(NULL)                              = 1193908497
      stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=837, ...}) = 0
      stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=837, ...}) = 0
      stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=837, ...}) = 0
      send(7, "<22>Nov  1 10:14:57 postfix/anvi"..., 92, MSG_NOSIGNAL) = 92
      exit_group(0)                           = ?

      It seems anvil is dieing, strace stops recording. Master logs nothing so far. The warn-log shows these three lines:

      Nov  1 10:14:52 mx-01 postfix/smtpd[3789]: warning: problem talking to service rewrite: Connection reset by peer
      Nov  1 10:14:59 mx-01 postfix/smtpd[3611]: warning: connect to private/anvil: Resource temporarily unavailable
      Nov  1 10:14:59 mx-01 postfix/smtpd[4192]: warning: problem talking to server private/anvil: Resource temporarily unavailable



      ----- Original Message ----
      From: Victor Duchovni <Victor.Duchovni@...>
      To: postfix-users@...
      Sent: Wednesday, October 31, 2007 2:38:07 AM
      Subject: Re: New document: STRESS_README

      On Tue, Oct 30, 2007 at 02:55:56PM -0700, Andreas Grimm wrote:

      > >> smtp_connect_timeout = 5s
      > >> smtp_helo_timeout = 5s
      > >
      > >Aggressive.
      >
      > Really? A test with telnet shows that it has no effect. After starting
      > a connection with telnet without saying helo it takes the default 5
      > minutes until postfix kicks me out. That's strange.

      Don't confuse smtp(8) and smtpd(8). Ditch these and just set smtpd_timeout..

      > >> smtp_timeout = 60s
      > >
      > >What is this?
      > A type error. Postfix was kind enough to ignore it.

      Don't confuse smtp(8) and smtpd(8).

      > I will try cdb, and have a look on glds performance during an
      > attack,currently it is very silent. What made me wondering too, is that
      > the client_restrictions are working not until "rcpt to".

          See the docs for "smtpd_delay_reject".

      As for the kernel limits, I have not heard of similar per-process limits
      in Linux that require kernel rebuilds. Is there some of sort of security
      add-on that is preventing master(8) from raising default hard resource
      limits?

      --
          Viktor.

      Disclaimer: off-list followups get on-list replies or get ignored.
      Please do not ignore the "Reply-To" header.

      To unsubscribe from the postfix-users list, visit
      http://www.postfix.org/lists.html or click the link below:
      <mailto:majordomo@...?body=unsubscribe%20postfix-users>

      If my response solves your problem, the best way to thank me is to not
      send an "it worked, thanks" follow-up. If you must respond, please put
      "It worked, thanks" in the "Subject" so I can delete these quickly.


      __________________________________________________
      Do You Yahoo!?
      Tired of spam? Yahoo! Mail has the best spam protection around
      http://mail.yahoo.com
    • Victor Duchovni
      ... Why not just a single mail log file? How does mail.info differ from mail ? I am guessing you are writing each info (majority) log message to disk
      Message 38 of 38 , Nov 1, 2007
      • 0 Attachment
        On Thu, Nov 01, 2007 at 10:10:30AM -0700, Andreas Grimm wrote:

        > Hello,
        >
        > no, destinations are local files:
        > destination mailinfo { file("/var/log/mail.info"); };
        > destination mailwarn { file("/var/log/mail.warn"); };
        > destination mailerr { file("/var/log/mail.err" fsync(yes)); };
        > destination mail { file("/var/log/mail"); };

        Why not just a single mail log file? How does "mail.info" differ from
        "mail"? I am guessing you are writing each "info" (majority) log message
        to disk twice. This is wasteful.

        > Messages in the fifo should be dropped, thats right. Maybe the release
        > comes from the simple restart of syslog-ng (cleaning up garbage?). It's
        > confusing.

        Either the log socket was actually unix-stream, or the sync flags were
        wrong, or syslog-ng was unwell after running a long time, but that should
        not happen.

        Perhaps there were other settings in syslog-ng.conf that had not yet
        taken effect? Also, you will lose some messages when you rotate
        log files by renaming, and send SIGHUP to the log server. It rebinds
        the /dev/log unix-domain socket, and messages are lost (briefly)
        while the socket is rebuilt.

        I avoid this, by not using fixed file names, and not sending SIGHUP.

        destination mail {
        file("/d/d1/log/raw/mail/$YEAR/$MONTH/$DAY/$HOUR"
        template("$ISODATE $HOST $MSG\n") template_escape(no)
        owner("root") group("log") perm(0640)
        dir_owner("root") dir_group("log") dir_perm(02750)
        create_dirs(yes));
        };

        These log files don't require external rotation, it is enough to just
        delete sufficiently old ones periodically. We compress them first
        (writing compressed data to a parallel directory tree) and move
        sync the compressed files to a log aggregation server.

        --
        Viktor.

        Disclaimer: off-list followups get on-list replies or get ignored.
        Please do not ignore the "Reply-To" header.

        To unsubscribe from the postfix-users list, visit
        http://www.postfix.org/lists.html or click the link below:
        <mailto:majordomo@...?body=unsubscribe%20postfix-users>

        If my response solves your problem, the best way to thank me is to not
        send an "it worked, thanks" follow-up. If you must respond, please put
        "It worked, thanks" in the "Subject" so I can delete these quickly.
      Your message has been successfully submitted and would be delivered to recipients shortly.