• This forum has a zero tolerance policy regarding spam. If you register here to publish advertising, your user account will be deleted without further questions.

Confixx Updatescript Problem

pinkysnet

New Member
Hallo,

nach stundenlanger Verzweifelung und durchackern aller Confixx-Updatescript Threads, habe ich mich entschlossen hier mal einen Thread zu erstellen.

Ich habe folgendes Problem: Das Updatescript von Confixx funktioniert misst den Transfer und den Soeicher nicht richtig. Wenn ich das Script manuell ausführe kommt folgender Fehler:

Code:
vadmin471:/var/www/confixx# ./confixx_updatescript.pl -fa -dbg
3.3.0 - 20070406.13
PID file /var/www/confixx/run/confixx_update.pid found
SUB: main::StillRunning
No running instance found
SUB: main::check_essentials
SUB: main::check_essentials3
SUB: main::check_essentials4
SUB: main::check_essentials5
Valid until: Fri Mar 20 23:45:02 2009
Version: 3pro
Checking datacenter mode.
SUB: main::check_datacenter
SUB: main::set_uids
SUB: main::check_if_update
SUB: main::fpaliasdel
SUB: main::delftps
SUB: main::delusers
SUB: main::delpops
SUB: main::updatesystem
SUB: main::checkSysDir (/var/www/web0/html)
SUB: main::checkSysDir (/var/www/web1/html)
SUB: main::addusers
SUB: main::addScponlyRoot
SUB: main::addpops
SUB: main::addftps
SUB: main::changeQuota
SUB: main::changeUserQuota
Setze Quota f?r Kunden "web0" auf "-1kb".SUB: Modules::ConfixxLog::addEvent (mlf||scripts_done_quota_user_set||web0||0)
Setze Quota f?r Kunden "web1" auf "-1kb".SUB: Modules::ConfixxLog::addEvent (mlf||scripts_done_quota_user_set||web1||0)
SUB: main::changeMailQuota
SUB: main::htaccess
SUB: main::lokaleips
SUB: main::GetLocalIPs
SUB: main::domainLog
SUB: main::userBackup
SUB: main::httpdconf
SUB: main::checkLogFileDir (web0)
SUB: main::checkSysDir (/var/www/web0/log)
SUB: main::checkLogFileDir (web1)
SUB: main::checkSysDir (/var/www/web1/log)
SUB: main::ssl_update
SUB: main::checkSysDir (/var/www/web0/atd)
SUB: main::checkSysDir (/var/www/web1/atd)
Modules::System::callSystem:
/usr/sbin/apache2ctl configtest
Syntax OK
SUB: main::reloadDaemon (apache)
SUB: main::frontpageadd
SUB: main::fpaliasadd
SUB: main::emailaliases
SUB: main::delaliases
Modules::System::callSystem:
/var/www/confixx/subs_include_postfix.pl -d 1
version: 3.1.0
SUB: main::CreateVirtDomainsFile
SUB: main::CreateVirtUserTable
SUB: main::CleanMailLists
SUB: main::CreateMailLists
Modules::System::callSystem:
/usr/sbin/postfix reload  >/dev/null 2>&1
SUB: main::GetDiskUsagePerUser
Segmentation fault

Die Quotas und der Cronjob sind richtig aktiviert.

Edit: Wie stell ich in der Confixx Admin Oberfläche das Updatescript richtig ein? Ich habe schon alle möglichen Einstellungen probiert, aber es funktioniert auch nicht richtig?! Ich möchte das das Script alle 60 Minuten den Traffic Verbrauch misst.
 
Last edited by a moderator:
Hi,

"Segmentation fault" macht mich stutzig. Haste mal /var/log/messages , syslog , etc. geprüft. Könnte ein Hardwaredefekt von RAM sein.

Gruß

Bernd
 
Jo...

ist ein VServer, könnte das wirklich am RAM liegen?
kernel.log sagt das:
Code:
---schnip
Mar 24 14:42:02 vadmin471 kernel: confixx_counter[1802]: segfault at 0000000000000098 rip 00000000f7abf548 rsp 00000000ffc
8d7ec error 4                                                                                                             
Mar 24 14:45:02 vadmin471 kernel: confixx_counter[1880]: segfault at 0000000000000098 rip 00000000f7b1e548 rsp 00000000fff
9aaec error 4                                                                                                             
Mar 24 14:48:02 vadmin471 kernel: confixx_counter[1932]: segfault at 0000000000000098 rip 00000000f7aa5548 rsp 00000000ff8
d9c2c error 4                                                                                                             
Mar 24 14:50:01 vadmin471 kernel: confixx_counter[1982]: segfault at 0000000000000098 rip 00000000f7af8548 rsp 00000000ffd
638bc error 4                                                                                                             
Mar 24 14:52:01 vadmin471 kernel: confixx_counter[2009]: segfault at 0000000000000098 rip 00000000f7a42548 rsp 00000000ff9
0bc5c error 4
 
vadmin ist glaube ich xen-Virtualisierung. Da kenne ich mich nicht so mit aus. Könnte was mit RAM zu tun haben. Haste noch genug RAM frei? Ggf. mal dein vServer-Provider fragen, ob er in den Logs des Host was erkennen kann.
 
Ja RAM ist noch ausreichend da.

Gibt es eine Möglichkeit bei Confixx das Updatescript manuell anlaufen zu lassen, so das nur der Traffic gemessen wird? Der Fehler kommt ja nur wenn er auch den Speicherverbrauch mit überprüft.
 
Danke. Das Traffic Update funktioniert.

Hab gerade gemerkt, das beim Speicherplatz Verbrauch auch nur Mist angezeigt wirx. Werd den Hoster mal ne EMail schicken.
 
Ja.

Code:
vadmin471:/var/www/confixx# quotaon -a
quotaon: using //aquota.user on /dev/hda1 [/]: Device or resource busy
 
Code:
vadmin471:/var/www/confixx# repquota -a
*** Report for user quotas on device /dev/hda1
Block grace time: 7days; Inode grace time: 7days
                        Block limits                File limits
User            used    soft    hard  grace    used  soft  hard  grace
----------------------------------------------------------------------
root      -- 1235400       0       0          45301     0     0       
man       --     476       0       0             24     0     0       
mail      --      44       0       0              2     0     0       
news      --       4       0       0              1     0     0       
www-data  --      16       0       0              4     0     0       
nobody    --      80       0       0              3     0     0       
mysql     --   27156       0       0            316     0     0       
postfix   --     184       0       0             70     0     0       
ftp       --       4       0       0              1     0     0       
confixx   --   54476       0       0           8629     0     0       
clamav    --       0       0       0              1     0     0       
amavis    --   28176       0       0             74     0     0       
gameserver --      60       0       0             12     0     0       
web0      -- 1315856       0       0             40     0     0       
web0p1    --       0  512000  768000              1     0     0       
web1      --     100 1048576 1048576             22     0     0       
#1002     --    2976       0       0            254     0     0
 
Ich hatte mal ein ähnliches Problem und bin dem Fehler mit einem

Code:
strace -ff -v ./confixx_counterscript.pl DEBUG --force-all

auf die Schliche gekommen.
 
Hallo, hab es am so durchlaufen lassen wie du es gepostet hast:

Code:
[pid 19322] rt_sigprocmask(SIG_BLOCK, [ALRM], [], 8) = 0
[pid 19322] rt_sigaction(SIGALRM, {SIG_DFL}, {SIG_DFL}, 8) = 0
[pid 19322] rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
[pid 19322] rt_sigprocmask(SIG_BLOCK, [ALRM], [], 8) = 0
[pid 19322] rt_sigaction(SIGALRM, {0x80afdd0, [], 0}, {SIG_DFL}, 8) = 0
[pid 19322] rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
[pid 19322] alarm(64)                   = 0
[pid 19322] select(16, [7 8 9], NULL, [7 8 9], {2, 0}) = 0 (Timeout)
[pid 19322] alarm(0)                    = 62
[pid 19322] rt_sigprocmask(SIG_BLOCK, [ALRM], [], 8) = 0
[pid 19322] rt_sigaction(SIGALRM, {SIG_DFL}, {0x80afdd0, [], 0}, 8) = 0
[pid 19322] rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
[pid 19322] alarm(0)                    = 0
[pid 19322] time(NULL)                  = 1207139169
[pid 19322] rt_sigprocmask(SIG_BLOCK, [ALRM], [], 8) = 0
[pid 19322] rt_sigaction(SIGALRM, {SIG_DFL}, {SIG_DFL}, 8) = 0
[pid 19322] rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
[pid 19322] rt_sigprocmask(SIG_BLOCK, [ALRM], [], 8) = 0
[pid 19322] rt_sigaction(SIGALRM, {0x80afdd0, [], 0}, {SIG_DFL}, 8) = 0
[pid 19322] rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
[pid 19322] alarm(64)                   = 0
[pid 19322] select(16, [7 8 9], NULL, [7 8 9], {2, 0}) = 0 (Timeout)
[pid 19322] alarm(0)                    = 62
[pid 19322] rt_sigprocmask(SIG_BLOCK, [ALRM], [], 8) = 0
[pid 19322] rt_sigaction(SIGALRM, {SIG_DFL}, {0x80afdd0, [], 0}, 8) = 0
[pid 19322] rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
[pid 19322] alarm(0)                    = 0
[pid 19322] time(NULL)                  = 1207139171
[pid 19322] rt_sigprocmask(SIG_BLOCK, [ALRM], [], 8) = 0
[pid 19322] rt_sigaction(SIGALRM, {SIG_DFL}, {SIG_DFL}, 8) = 0
[pid 19322] rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
[pid 19322] rt_sigprocmask(SIG_BLOCK, [ALRM], [], 8) = 0
[pid 19322] rt_sigaction(SIGALRM, {0x80afdd0, [], 0}, {SIG_DFL}, 8) = 0
[pid 19322] rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
[pid 19322] alarm(64)                   = 0

Das wiederholt sich am ende immer. Aber was sagt mir die Debugausgabe?
 
Das Programm wartet darauf, dass auf einem der angegebenen Filedescriptoren (7, 8 oder 9) endlich Daten verfügbar werden, damit es weiter machen kann. Welche Datei bzw. (wahrscheinlicher) welcher Socket sich dahinter verbirgt, steht weiter oben (der jeweilige Filedescriptor ist das Ergebnis eines Systemcalls wie open, popen, socketpair, accept, etc.).
 
Vielleicht finde ich morgen die Zeit mir den trace mal anzuschauen -- allerdings all zu viel Hoffnung will ich Dir nicht machen, da ich das Script selber nicht kenne und daher auch nicht sagen kann, was z.B. an Eingaben erwartet wird. Das macht das Debuggen deutlich schwieriger.
Du kannst den vollständigen Trace ja mal hier als Attachment posten (mit der Option "-o dateiname.txt" kann man die Ausgabe in eine Datei umlenken). Vorher solltest Du noch sicherstellen, dass darin keine Passworte und andere sensitive Informationen vorhanden sind ;)
 
Der Trace enthält leider keine Hinweise auf die Fehlerursache. Insofern würde ich mal weiter in Richtung defektes RAM suchen. Früher war das Compilieren eines Kernels ein beliebter Speichertest. Das könntest Du ja mal machen (sofern Du einen Compiler auf dem Server installiert hast)
 
Ich habe genau den gleichen Fehler und der Trace hängt an der selben Stelle. Der RAM wirds wohl nicht sein. Auch ich setze XEN ein. Aufgetreten ist das bei einem Serverwechsel. Also die Domu ist auf einen neues Hostsystem gezogen. Da das wahrscheinlich an der Quota liegt, habe ich eine Vermutung. Unter vadmin wird hda in der fstab benutzt. Nun ist es sda. Das ist zwar egal, aber irgendwas ist ja nun kaputt. Also entweder stimmen Einträge nicht mehr, oder es liegt am domu Kernel. Ich werde es probieren und berichten.

Bist Du weiter gekommen?
 
Back
Top