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

Re: rsync does not log files transfered

Expand Messages
  • bloedmann999
    ... Someone answered me in another forum (and I missed it, ashamed to say) that any Dirvish RC over 128 is caused by a signal. So 139 would be signal 11 and
    Message 1 of 4 , Apr 4, 2007
    • 0 Attachment
      --- In nslu2-linux@yahoogroups.com, "bloedmann999" <Brian_Dorling@...>
      wrote:
      >
      > HI,
      > I am using rsync, controlled by dirvish to backup various machines in
      > my local network. It works pretty well. But sometimes the dirvish
      > process will give a RC=139 or RC=145 back, and I am trying to debug
      > that. I ping the target machines to check they are up before
      > attempting the backup on each machine.
      > In my rsyncd.conf I have these options set:
      >
      > list = yes
      > log file = /var/log/rsyncd.log
      > transfer logging = yes
      >
      > I never see more messages than that rsync is stopping, or starting.
      >
      > Just wondering (as this may be a dirvish problem) does anyone have
      > rsync on unslung running OK and logging the files transfered? I have
      > the 2.6.9 version, which seems to be the newest ipkg could find.
      >
      > I've also tried rebooting the slug just before the backup, in case of
      > a memory shortage for example, and recycling rsync too just before the
      > backup. Still the same problem.
      >
      > The backups will die 1 night a week on average.
      >
      > Cheers Brian
      >
      Someone answered me in another forum (and I missed it, ashamed to say)
      that any Dirvish RC over 128 is caused by a signal. So 139 would be
      signal 11 and 145 would be signal 17. As dirvish just calls rsync I
      assume it must be rsync that is dying, or being killed somehow. So
      sig11 is a segmentation fault, that must be internal from rsync. sig17
      is sigstop, will that be from something external to rsync??
    • bloedmann999
      ... Hi, after someone gave me the tip to set ulimit I now have 3 coredumps from Perl segmentation faults, those are the root cause of my problems. I have
      Message 2 of 4 , Apr 10, 2007
      • 0 Attachment
        --- In nslu2-linux@yahoogroups.com, "bloedmann999" <Brian_Dorling@...>
        wrote:
        >
        > --- In nslu2-linux@yahoogroups.com, "bloedmann999" <Brian_Dorling@>
        > wrote:
        > >
        > > HI,
        > > I am using rsync, controlled by dirvish to backup various machines in
        > > my local network. It works pretty well. But sometimes the dirvish
        > > process will give a RC=139 or RC=145 back, and I am trying to debug
        > > that. I ping the target machines to check they are up before
        > > attempting the backup on each machine.
        > > In my rsyncd.conf I have these options set:
        > >
        > > list = yes
        > > log file = /var/log/rsyncd.log
        > > transfer logging = yes
        > >
        > > I never see more messages than that rsync is stopping, or starting.
        > >
        > > Just wondering (as this may be a dirvish problem) does anyone have
        > > rsync on unslung running OK and logging the files transfered? I have
        > > the 2.6.9 version, which seems to be the newest ipkg could find.
        > >
        > > I've also tried rebooting the slug just before the backup, in case of
        > > a memory shortage for example, and recycling rsync too just before the
        > > backup. Still the same problem.
        > >
        > > The backups will die 1 night a week on average.
        > >
        > > Cheers Brian
        > >
        > Someone answered me in another forum (and I missed it, ashamed to say)
        > that any Dirvish RC over 128 is caused by a signal. So 139 would be
        > signal 11 and 145 would be signal 17. As dirvish just calls rsync I
        > assume it must be rsync that is dying, or being killed somehow. So
        > sig11 is a segmentation fault, that must be internal from rsync. sig17
        > is sigstop, will that be from something external to rsync??
        >
        Hi,
        after someone gave me the tip to set ulimit I now have 3 coredumps
        from Perl segmentation faults, those are the root cause of my problems.
        I have upgraded to the 5.8.8 version of Perl on unslung from 5.8.6.
        I now need to find a gdb howto or something to see if there is
        anything useful in the core.
        Cheers Brian
      • bloedmann999
        ... machines in ... case of ... before the ... Hi, The problem is somehow caused by cron. After a certain point all backup attempts via cron will fail, but
        Message 3 of 4 , Apr 18, 2007
        • 0 Attachment
          --- In nslu2-linux@yahoogroups.com, "bloedmann999" <Brian_Dorling@...>
          wrote:
          >
          > --- In nslu2-linux@yahoogroups.com, "bloedmann999" <Brian_Dorling@>
          > wrote:
          > >
          > > --- In nslu2-linux@yahoogroups.com, "bloedmann999" <Brian_Dorling@>
          > > wrote:
          > > >
          > > > HI,
          > > > I am using rsync, controlled by dirvish to backup various
          machines in
          > > > my local network. It works pretty well. But sometimes the dirvish
          > > > process will give a RC=139 or RC=145 back, and I am trying to debug
          > > > that. I ping the target machines to check they are up before
          > > > attempting the backup on each machine.
          > > > In my rsyncd.conf I have these options set:
          > > >
          > > > list = yes
          > > > log file = /var/log/rsyncd.log
          > > > transfer logging = yes
          > > >
          > > > I never see more messages than that rsync is stopping, or starting.
          > > >
          > > > Just wondering (as this may be a dirvish problem) does anyone have
          > > > rsync on unslung running OK and logging the files transfered? I have
          > > > the 2.6.9 version, which seems to be the newest ipkg could find.
          > > >
          > > > I've also tried rebooting the slug just before the backup, in
          case of
          > > > a memory shortage for example, and recycling rsync too just
          before the
          > > > backup. Still the same problem.
          > > >
          > > > The backups will die 1 night a week on average.
          > > >
          > > > Cheers Brian
          > > >
          > > Someone answered me in another forum (and I missed it, ashamed to say)
          > > that any Dirvish RC over 128 is caused by a signal. So 139 would be
          > > signal 11 and 145 would be signal 17. As dirvish just calls rsync I
          > > assume it must be rsync that is dying, or being killed somehow. So
          > > sig11 is a segmentation fault, that must be internal from rsync. sig17
          > > is sigstop, will that be from something external to rsync??
          > >
          > Hi,
          > after someone gave me the tip to set ulimit I now have 3 coredumps
          > from Perl segmentation faults, those are the root cause of my problems.
          > I have upgraded to the 5.8.8 version of Perl on unslung from 5.8.6.
          > I now need to find a gdb howto or something to see if there is
          > anything useful in the core.
          > Cheers Brian
          >
          Hi,
          The problem is somehow caused by cron. After a certain point all
          backup attempts via cron will fail, but those from the command line
          will be OK. After a reboot the backups via cron will work again, for a
          while.
          I solved the problem by having cron send the command to run the script
          to the at daemon. Now it works every time.
          I cannot debug this anymore with my knowledge, is anyone else involved
          with unslung interested in why this happens?

          Cheers Brian
        Your message has been successfully submitted and would be delivered to recipients shortly.