SYSTEM WARNING: 'date_default_timezone_get(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected the timezone 'UTC' for now, but please set date.timezone to select your timezone.' in '/usr/share/mantis/www/core.php' line 264

0003002: Daily Backup doesn´t work - MantisBT Endian Bugtracker
Endian Issue Tracker





Please see now our new Bugtracker system: JIRA







Main | My View | View Issues | Change Log | Roadmap
  

View Issue Details [ Jump to Notes ] [ Issue History ] [ Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0003002Endian FirewallBackup and Updatespublic2010-06-14 08:412011-09-09 07:25
Reporteraender 
Assigned Topeter-endian 
PrioritynormalSeveritymajorReproducibilityalways
StatusfeedbackResolutionreopened 
PlatformOSOS Version
Product Version2.3.1 
Target Version2.4.1Fixed in Version2.4.1 
Summary0003002: Daily Backup doesn´t work
DescriptionWe changed our weekly backup to daily backup. Now backup works no longer. What´s wrong?

See attached screenshots.

Endian 2.3.1 Enterprise.
TagsNo tags attached.
Attached Filesjpeg file icon backup.jpeg [^] (69,595 bytes) 2010-06-14 08:41


jpeg file icon backup2.jpeg [^] (43,831 bytes) 2010-06-14 08:41

- Relationships
related to 0002915closedpeter-endian dnsmasq blocking cron 

-  Notes
(0004591)
peter-endian (administrator)
2010-07-05 16:24

 can you try the fix of 0002915?
(0004708)
mschwenk (reporter)
2010-09-06 09:08

 Got the same issue. Thomas already gave me the hint with the blackholedns script but it doesn't seem to work. We are pretty sure it is related to the blackholedns because this process is allays stuck:

Here is pstree sometime the next morning after backup failed:

init???clamd
     ??collectd
     ??dnsmasq
     ??6*[efw-console]
     ??efw-console???bash
     ??emi
     ??fcron???fcron???bash???run-parts???blackholedns
     ??2*[getblackholedns]
     ??havp???20*[havp???havp]
     ??httpd???6*[httpd]
     ??keepalived???2*[keepalived]
     ??lcd-daemon
     ??logsurfer
     ??monit
     ??ntpd
     ??2*[python]
     ??snmpd
     ??snort
     ??squid???squid???20*[ncsa_auth]
     ? ??unlinkd
     ??sshd???sshd???bash
     ? ??sshd???bash???pstree
     ??stslog???openvpn
     ??syslog-ng
     ??udevd
     ??ulogd
     ??uplinksdaemon

Here a ps aux sometime the next morning after backup failed:

ps aux | grep cron
root 6408 0.0 0.0 1876 552 ? S Sep03 0:00 /usr/sbin/fcron -c /etc/fcron.conf
root 6409 0.0 0.1 3248 1064 ? S Sep03 0:00 /bin/bash -c [ -x /bin/run-parts ] && run-parts --report /etc/cron.daily
root 6410 0.0 0.0 1496 604 ? S Sep03 0:00 run-parts --report /etc/cron.daily
root 8241 0.0 0.0 2896 676 pts/1 R+ 10:34 0:00 grep cron
root 12575 0.0 0.0 1876 596 ? Ss Aug28 0:02 /usr/sbin/fcron -c /etc/fcron.conf

As soon as i kill the hanging cron.daily processes it will run the next day fine. This all happens randomly on my EFW's. I have a 2 Cluster and 3 nonclusteresd ones. And sometimes it works fine on one for a couple of days but on another one it fails then it changes and fails on a different one. So absolutly not reproducable. Any clue?
(0004872)
mschwenk (reporter)
2010-09-24 16:23

 Seems to work now again. No idea why. Will keep you up to date.
(0004873)
peter-endian (administrator)
2010-09-24 16:36

 changed the cronscript that it runs the download completely detached

here's the patch:
Index: src/lib/blackholedns.cron
===================================================================
--- src/lib/blackholedns.cron (revision 23770)
+++ src/lib/blackholedns.cron (working copy)
@@ -33,7 +33,7 @@
 # Author: Peter Warasin <peter@endian.it>
 # Description: calls blackholedns list retriever
 
-PATH=/sbin:/bin:/usr/sbin:/usr/bin
-/usr/local/bin/getblackholedns.py &>/dev/null &
+PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin
+run-detached getblackholedns.py &>/dev/null
 
 exit 0
(0004874)
peter-endian (administrator)
2010-09-24 16:37

 i will completely detach the process, so it can't happen anymore. so we are on the secure side.
(0004879)
peter-endian (administrator)
2010-09-28 10:16

 detaching does not block run-parts anymore, so this is resolved

- Issue History
Date Modified Username Field Change
2010-06-14 08:41 aender New Issue
2010-06-14 08:41 aender File Added: backup.jpeg
2010-06-14 08:41 aender File Added: backup2.jpeg
2010-06-21 14:53 luca-endian Relationship added child of 0002915
2010-07-05 16:20 peter-endian Relationship replaced related to 0002915
2010-07-05 16:24 peter-endian Note Added: 0004591
2010-07-05 16:24 peter-endian Status new => feedback
2010-09-06 09:08 mschwenk Note Added: 0004708
2010-09-23 10:59 peter-endian Status feedback => acknowledged
2010-09-23 11:00 peter-endian Target Version => 2.4.1
2010-09-24 16:05 peter-endian Status acknowledged => assigned
2010-09-24 16:05 peter-endian Status assigned => new
2010-09-24 16:05 peter-endian Assigned To => peter-endian
2010-09-24 16:05 peter-endian Status new => assigned
2010-09-24 16:23 mschwenk Note Added: 0004872
2010-09-24 16:36 peter-endian Note Added: 0004873
2010-09-24 16:37 peter-endian Note Added: 0004874
2010-09-28 10:16 peter-endian Note Added: 0004879
2010-09-28 10:16 peter-endian Status assigned => resolved
2010-09-28 10:16 peter-endian Fixed in Version => 2.4.1
2010-09-28 10:16 peter-endian Resolution open => fixed
2010-09-29 16:32 luca-endian Status resolved => feedback
2010-09-29 16:32 luca-endian Resolution fixed => reopened
2010-10-01 09:39 peter-endian Status feedback => resolved
2010-10-01 09:39 peter-endian Resolution reopened => fixed
2010-11-22 11:49 peter-endian Status resolved => closed
2011-09-09 07:25 Anonymous Status closed => feedback
2011-09-09 07:25 Anonymous Resolution fixed => reopened

Copyright © 2005-2008 Endian, SRL. All rights reserved.

Copyright © 2000 - 2012 MantisBT Group
Powered by Mantis Bugtracker