'Failed to start vserver' nach backup

  • Hallo vserver-Gemeinde,


    nach Erstellung eines neuen backups startet mein vserver nicht mehr richtig und ist nicht zu erreichen ( ssh, ping )
    Es gibt eine Fehlermeldung die besagt 'Failed to start vserver ....' und danach steht wieder 'vserver ..... successfully started'.


    Hatte jemand schon mal ein ähnliches Problem?


    Stefan

    Starting system log daemon....
    Starting kernel log daemon...
    An error occured while executing the vserver startup sequence; when
    there are no other messages, it is very likely that the init-script
    (/etc/init.d/rc 3) failed.


    Common causes are:
    * /etc/rc.d/rc on Fedora Core 1 and RH9 fails always; the 'apt-rpm' build
    method knows how to deal with this, but on existing installations,
    appending 'true' to this file will help.



    Failed to start vserver 'vxxxxxxxxxxxx'
    failed!


    vserver vxxxxxxxxxxxx sucessfully started

  • Haste mal nachgesehen, ob in den Serverlogs irgendwas zu finden ist?
    Was ist seit dem letzten funktionierendem Stand passiert?

    Mein Server:
    v(olks)Server 1. Serie: 2,5GHz, 1024MB RAM, 1024MB Swap, 2x60GB-Raid1-HDD, Traffic-Flat
    Node:
    78.46.117.9x | hos-tr2.ex3k4.rz7.hetzner.de

  • Anscheinend startet der vserver schon 'etwas', aber nicht richtig.


    Hier das Serverlog vom startup ...


    Mar 13 19:10:04 v220091013951770 syslogd 1.5.0#5: restart.
    Mar 13 19:15:05 v220091013951770 named[18044]: starting BIND 9.5.1-P3 -u bind
    Mar 13 19:15:05 v220091013951770 named[18044]: found 16 CPUs, using 16 worker threads
    Mar 13 19:15:05 v220091013951770 named[18044]: using up to 4096 sockets
    Mar 13 19:15:05 v220091013951770 named[18044]: loading configuration from '/etc/bind/named.conf'
    Mar 13 19:15:05 v220091013951770 named[18044]: using default UDP/IPv4 port range: [1024, 65535]
    Mar 13 19:15:05 v220091013951770 named[18044]: using default UDP/IPv6 port range: [1024, 65535]
    Mar 13 19:15:05 v220091013951770 named[18044]: no IPv6 interfaces found
    Mar 13 19:15:05 v220091013951770 named[18044]: listening on IPv4 interface lo, 127.0.0.1#53
    Mar 13 19:15:05 v220091013951770 named[18044]: automatic empty zone: 254.169.IN-ADDR.ARPA
    Mar 13 19:15:05 v220091013951770 named[18044]: automatic empty zone: 2.0.192.IN-ADDR.ARPA
    Mar 13 19:15:05 v220091013951770 named[18044]: automatic empty zone: 255.255.255.255.IN-ADDR.ARPA
    Mar 13 19:15:05 v220091013951770 named[18044]: automatic empty zone: 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA
    Mar 13 19:15:05 v220091013951770 named[18044]: automatic empty zone: 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA
    Mar 13 19:15:05 v220091013951770 named[18044]: automatic empty zone: D.F.IP6.ARPA
    Mar 13 19:15:05 v220091013951770 named[18044]: automatic empty zone: 8.E.F.IP6.ARPA
    Mar 13 19:15:05 v220091013951770 named[18044]: automatic empty zone: 9.E.F.IP6.ARPA
    Mar 13 19:15:05 v220091013951770 named[18044]: automatic empty zone: A.E.F.IP6.ARPA
    Mar 13 19:15:05 v220091013951770 named[18044]: automatic empty zone: B.E.F.IP6.ARPA
    Mar 13 19:15:05 v220091013951770 named[18044]: command channel listening on 127.0.0.1#953
    Mar 13 19:15:05 v220091013951770 named[18044]: zone 0.in-addr.arpa/IN: loaded serial 1
    Mar 13 19:15:05 v220091013951770 named[18044]: zone 127.in-addr.arpa/IN: loaded serial 1
    Mar 13 19:15:05 v220091013951770 named[18044]: zone 255.in-addr.arpa/IN: loaded serial 1
    Mar 13 19:15:05 v220091013951770 named[18044]: zone localhost/IN: loaded serial 2
    Mar 13 19:15:05 v220091013951770 named[18044]: running
    Mar 13 19:15:05 v220091013951770 dovecot: Dovecot v1.0.15 starting up
    Mar 13 19:15:05 v220091013951770 proftpd[18320]: vXXXXXXXXXX.yourvserver.net - ProFTPD 1.3.1 (stable) (built Thu Oct 29 09:01:50 UTC 2009) standalone mode STARTUP
    Mar 13 19:15:05 v220091013951770 /usr/sbin/cron[18352]: (CRON) INFO (pidfile fd = 6)
    Mar 13 19:15:05 v220091013951770 /usr/sbin/cron[18353]: (CRON) STARTUP (fork ok)
    Mar 13 19:15:05 v220091013951770 /usr/sbin/cron[18353]: (CRON) INFO (Running @reboot jobs)


    Ich habe leider nur ein backup und zwar genau das, auf Grund dessen der vserver rebooted wurde. Das werde ich jetzt einfach mal zurückspielen, obwohl es eigentlich genau den aktuellen Stand widerspiegelt.


    Stefan

  • Hallo,


    habe auch eben ein Backup gemacht und dann beim wieder Starten des vservers das gleiche bekommen (bzw. fast, bei mir heißt es am Ende "failed"):



    Kann es sein, dass der vserver kein Netzwerk-Device (ethx) zugewiesen bekommt? Laut logs bootet er schon und auch einige Dienste starten, aber er ist von außen nicht zu erreichen (ping, etc)...

  • Noch ein Nachtrag: Beim Stoppen des vServers kommt noch folgende Meldung: "RTNETLINK answers: Cannot assign requested address"


  • Die Fehlermeldung kam beim neustart übers VCP oder?


    Da ist die Meldung nicht so wichtig, sagt halt nur aus das irgendwas nicht richtig durchgeführt werden konnte. Da du aber keine Berechtigung hast an der Grundkonfiguration rumzuspielen (mounten, ip ändern, usw.) kommt es gerne mal zu solchen Fehlermeldungen.


    Ist aber nur in den seltensten Fällen schlimm, denn die Einträge sind entweder bereits vorhanden, oder du konntest diese so oder so nicht setzen.

  • Ja, die Meldung kommt beim Neustarten über VCP (nach Backup oder manuellem Neustart).


    Allerdings schon schlimm, da wie gesagt der vserver nach dem Booten nicht mehr von außen erreichbar ist (ping).


    Folgendes habe ich Netz dazu gefunden (wenn dies das Problem ist, kann aber wohl nur netcup daran etwas ändern):


    http://oldwiki.linux-vserver.org/Linux-Vserver+FAQ


  • Zitat von micon;15174

    RTNETLINK answers: Cannot assign requested address


    Das hört sich für mich nach einem Konfigurationsfehler auf dem Node an. Die Meldung hatte ich nach dem Zuweisen einer neuen IP auch einmal, wenn ich mich nicht täusche. Wende dich doch einmal mit deinem vServer-Namen und diesem Fehler per E-Mail den den Support. Das Problem wirst du vermutlich selbst nicht lösen können.



    Mfg Christian

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

  • Hallo micon,


    hast Du bereits beim Support angefragt?


    Auf meine Anfrage wurde mir empfohlen syslog durch rsyslogd zu ersetzen ..


    Zitat


    .....
    wir empfehlen Ihnen den syslog zu entfernen und stattdessen auf den
    rsyslogd zu setzen.


    Dies am besten aus dem rescue System installieren......

    Wenn ich rsyslog im rescue System installiere, dann ist das nach meinem Verständnis nur dort vorhanden. Muss ich die Dateien und Konfiguration dann in den vserver kopieren? Wer hat das schon mal erfolgreich praktiziert?


    Stefan

  • Hallo sh-gfeld,


    ja, ich hatte gestern noch dem Support geschrieben (mit dem Hinweis auf die Fehlermeldung "RTNETLINK answers: Cannot assign requested address") und dieser hat das Problem mit der Nichtereichbarkeit des vServers behoben, die Fehlerursache ist aber wohl noch nicht endgültig geklärt.


    Ich habe nun außerdem syslogd/klogd durch rsyslog ersetzt. Dies hat bei mir im laufenden System (debian lenny) mittels "aptitude install rsyslog" funktioniert (hat die Pakete syslogd/klogd entfernt).


    Danach habe ich noch einmal ein Backup erzeugt - und siehe da der anschließende Neustart des vServers hat nun funktioniert und er ist auch wieder erreichbar.


    Gruß
    micon

  • Hallo micon,


    habe den Support nochmals mit dem Hinweis auf die Meldung "RTNETLINK answers: Cannot assign requested address" angeschrieben, die auch bei mir ausgegeben wird.
    Dann wird der vserver hoffentlich bald wieder erreichbar sein.


    Stefan