Ankündigung

Einklappen
Keine Ankündigung bisher.

unerklärliche reboots

Einklappen
X
Einklappen
 
  • Seite von 1
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge
Vorherige template Weiter
    #1

    unerklärliche reboots

    Moin,

    wir haben das OfficeMaster Gate mit aktueller Firmware laufen und haben das Phänomen, dass die Box sich von Zeit zur Zeit einfach rebootet.
    Im Syslog steht nur folgendes:
    Feb 8 08:51:36 OMG200788 callp: sip_isdn:3592 (2) BCHANNEL: ============================= CN Payload type 13 and value=65
    Feb 8 08:51:36 OMG200788 callp: sip_isdn:3592 (2) BCHANNEL: ============================= set ILID_MGMT_JB_NOISE_LEVEL to 66
    Feb 8 08:51:37 OMG200788 callp: mux_isdn:0 (1) ISDN[2](4391): L2X : 2011-02-08 08:51.37,835 R:02 01 01 05
    Feb 8 08:51:37 OMG200788 callp: mux_isdn:0 (1) ISDN[2](4391): L2X : 2011-02-08 08:51.37,836 T:02 01 01 0d
    Feb 8 08:51:38 OMG200788 callp: sip_isdn:a79d06f2-9ff1-4de5-8e92-0208d0966cf7 (1) BCHANNEL: [pid/23617 +1721 rtp.c] Profile specific SR extension ignored
    Feb 8 08:52:52 OMG200788 syslogd 1.5.0#1ubuntu1: restart.
    Feb 8 08:52:53 OMG200788 kernel: Inspecting /boot/System.map-2.6.24-23-generic
    Feb 8 08:52:54 OMG200788 kernel: Loaded 27906 symbols from /boot/System.map-2.6.24-23-generic.
    Feb 8 08:52:54 OMG200788 kernel: Symbols match kernel version 2.6.24.
    Feb 8 08:52:54 OMG200788 kernel: Loaded 11867 symbols from 57 modules.
    Feb 8 08:52:54 OMG200788 kernel: [ 0.000000] Initializing cgroup subsys cpuset
    Feb 8 08:52:54 OMG200788 kernel: [ 0.000000] Initializing cgroup subsys cpu
    Feb 8 08:52:54 OMG200788 kernel: [ 0.000000] Linux version 2.6.24-23-generic (buildd@palmer) (gcc version 4.2.4 (Ubuntu 4.2.4-1ubuntu3)) #1 SMP Wed Apr 1 21:47:28 UTC 2009 (Ubuntu 2.6.24-23.52-generic)
    Feb 8 08:52:54 OMG200788 kernel: [ 0.000000] BIOS-provided physical RAM map:
    Feb 8 08:52:54 OMG200788 kernel: [ 0.000000] BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
    Feb 8 08:52:54 OMG200788 kernel: [ 0.000000] BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
    Feb 8 08:52:54 OMG200788 kernel: [ 0.000000] BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved)
    Feb 8 08:52:54 OMG200788 kernel: [ 0.000000] BIOS-e820: 0000000000100000 - 00000000067c0000 (usable)
    Feb 8 08:52:54 OMG200788 kernel: [ 0.000000] BIOS-e820: 0000000040400000 - 0000000040440004 (reserved)
    Feb 8 08:52:54 OMG200788 kernel: [ 0.000000] BIOS-e820: 00000000f0000000 - 0000000100000000 (reserved)
    Feb 8 08:52:54 OMG200788 kernel: [ 0.000000] 0MB HIGHMEM available.
    Feb 8 08:52:54 OMG200788 kernel: [ 0.000000] 103MB LOWMEM available.
    Im Einsatz ist die Box zum Telefonieren über Lync und zum Fax Empfang und Versand.

    Jemand eine Idee wieso hier reboots passieren?

    Mfg Frank
    Stichworte: -
    #2
    Was ist denn zu diesem Zeitpunkt im omcums0.0 log von OfficeMaster zu sehen? Ansonsten riecht das nach einem Fall für unsere Hotline.
    Johann Deutinger

    Kommentar

      #3
      Ok. Da hab ich dann folgendes im Log:

      (3524) 11/02/08 08:51:09 - INFO: <-- :sh --status=0
      (3524) 11/02/08 08:51:09 - INFO: <-- date is simulated.
      (3524) 11/02/08 08:51:09 - INFO: <-- :sh --status=0
      (3444) 11/02/08 08:51:10 - INFO: <-- Tue Feb 8 08:51:09 CET 2011
      (3444) 11/02/08 08:51:10 - INFO: <-- :sh --status=0
      (3524) 11/02/08 08:52:19 - WARNING: DChannel::CheckJcAlive(): initiating maintenance cycle because of job control message missing for 70 seconds.
      (3524) 11/02/08 08:52:19 - INFO: DChannel::ThreadMethod(): shutting down D channel handler after socket error.
      (3524) 11/02/08 08:52:19 - INFO: DChannel::ShutDown(): disconnecting from job control while shutting down D channel handler.
      (3524) 11/02/08 08:52:19 - INFO: --> :quit

      (3444) 11/02/08 08:52:19 - WARNING: DChannel::CheckJcAlive(): initiating maintenance cycle because of job control message missing for 69 seconds.
      (3444) 11/02/08 08:52:19 - INFO: DChannel::ThreadMethod(): shutting down D channel handler after socket error.
      (3444) 11/02/08 08:52:19 - INFO: JobQueue<AppSpec>::RemoveChannel(): removing channel 00AC30E4 from list at 00AC3010.
      (3444) 11/02/08 08:52:19 - INFO: DChannel::ShutDown(): disconnecting from job control while shutting down D channel handler.
      (3444) 11/02/08 08:52:19 - INFO: --> :exit

      (3524) 11/02/08 08:52:39 - INFO: DChannel::Connect(): connecting to fax device 192.168.111.25/3218.
      (3444) 11/02/08 08:52:39 - INFO: DChannel::Connect(): connecting to fax device 192.168.111.25/3217.
      (3524) 11/02/08 08:52:42 - INFO: OmcSock::Connect(): cannot connect socket.
      (3524) 11/02/08 08:52:42 - ERROR: DChannel::Connect(): cannot connect to fax device 192.168.111.25/3218.
      (3524) 11/02/08 08:52:43 - WARNING: DChannel::InitJobControl(): could not connect to job control.
      (3444) 11/02/08 08:52:48 - INFO: OmcSock::Connect(): cannot connect socket.
      (3444) 11/02/08 08:52:48 - ERROR: DChannel::Connect(): cannot connect to fax device 192.168.111.25/3217.
      (3444) 11/02/08 08:52:49 - WARNING: DChannel::InitJobControl(): could not connect to job control.
      (3524) 11/02/08 08:52:53 - INFO: DChannel::Connect(): connecting to fax device 192.168.111.25/3218.
      (3524) 11/02/08 08:52:54 - INFO: OmcSock::Connect(): cannot connect socket.
      (3524) 11/02/08 08:52:54 - ERROR: DChannel::Connect(): cannot connect to fax device 192.168.111.25/3218.
      (3524) 11/02/08 08:52:55 - WARNING: DChannel::InitJobControl(): could not connect to job control.
      (3444) 11/02/08 08:52:59 - INFO: DChannel::Connect(): connecting to fax device 192.168.111.25/3217.
      (3444) 11/02/08 08:52:59 - INFO: --> :sh date 020808522011.59

      (3444) 11/02/08 08:53:01 - INFO: <-- Tue Feb 8 08:52:59 CET 2011
      (3444) 11/02/08 08:53:01 - INFO: <-- :sh --status=0
      (3444) 11/02/08 08:53:01 - INFO: --> :c --dchan_param=" --l2-protocol=pp --l3-protocol=dss1 --dial-mode=block --debug-l1=1 --debug-l2=1 --debug-l3=1 --debug-l4=0 --base-number= --ddi-length=3333333333" --bchan_param="" --log_level=1 --calling_party_number="" --receive_mask=""


      (3444) 11/02/08 08:53:01 - INFO: --> :dstart

      (3444) 11/02/08 08:53:01 - INFO: --> :dev

      (3444) 11/02/08 08:53:01 - INFO: DChannel::InitJobControl(): watchdog is on.
      (3444) 11/02/08 08:53:01 - INFO: <-- jobcontrolPort=3217
      (3444) 11/02/08 08:53:01 - INFO: <-- jobcontrolPortFixed=1
      (3444) 11/02/08 08:53:01 - INFO: <-- jobcontrolChannels=4
      (3444) 11/02/08 08:53:01 - INFO: <-- dchan_exec="/usr/fb/bin/isdn.prc"
      (3444) 11/02/08 08:53:01 - INFO: <-- dchan_param=" --l2-protocol=pp --l3-protocol=dss1 --dial-mode=block --debug-l1=1 --debug-l2=1 --debug-l3=1 --debug-l4=0 --base-number= --ddi-length=3333333333"
      (3444) 11/02/08 08:53:01 - INFO: <-- bchan_exec="/usr/fb/bin/fax.prc"
      (3444) 11/02/08 08:53:01 - INFO: <-- bchan_param=""
      (3444) 11/02/08 08:53:01 - INFO: <-- called_party_number=0455321
      (3444) 11/02/08 08:53:01 - INFO: <-- calling_party_number=
      (3444) 11/02/08 08:53:01 - INFO: <-- noalive=0
      (3444) 11/02/08 08:53:01 - INFO: <-- :jobcontrol --message="D-Channel started"
      (3444) 11/02/08 08:53:02 - INFO: <-- count B-channels
      (3444) 11/02/08 08:53:02 - INFO: <-- :if --channel_name="1.a/B2/S0/HFC-4S"
      (3444) 11/02/08 08:53:02 - INFO: <-- :if --channel_name="1.a/B1/S0/HFC-4S"
      (3444) 11/02/08 08:53:02 - INFO: <-- :if --channel_count=2
      (3444) 11/02/08 08:53:02 - INFO: DChannel::OnIfMsg(): device reports 2 B channels.
      (3444) 11/02/08 08:53:02 - INFO: JobQueue<AppSpec>::AddChannel(): adding channel 00AC30E4 to list at 00AC3010.
      (3524) 11/02/08 08:53:05 - INFO: DChannel::Connect(): connecting to fax device 192.168.111.25/3218.
      (3524) 11/02/08 08:53:05 - INFO: --> :sh date 020808532011.05

      (3524) 11/02/08 08:53:06 - INFO: <-- date is simulated.
      (3524) 11/02/08 08:53:06 - INFO: <-- :sh --status=0
      (3524) 11/02/08 08:53:06 - INFO: --> :c --dchan_param=" --l2-protocol=pp --l3-protocol=dss1 --dial-mode=block --debug-l1=1 --debug-l2=1 --debug-l3=1 --debug-l4=0 --base-number= --ddi-length=3333333333" --bchan_param="" --log_level=1 --calling_party_number="" --receive_mask=""


      (3524) 11/02/08 08:53:06 - INFO: --> :dstart

      (3524) 11/02/08 08:53:06 - INFO: --> :dev

      (3524) 11/02/08 08:53:06 - INFO: DChannel::InitJobControl(): watchdog is on.

      Kommentar

        #4
        Hi,

        ich seh grad in der Messaging Server Konfiguration gibt es die Option "Watchdog aktiv" welche bei mir aktiviert ist.
        Die wird wohl dafür verantwortlich sein, dass die Kiste dann einen Reboot macht oder?

        Gruß
        Frank

        Kommentar

          #5
          Hallo,

          bei uns gab/gibt es diesen Fehler auch.

          Heute wurde eine neue Firmware eingespielt. Beim Firmware Update ist jedoch ein Fehler aufgetreten. Es sollte ein Befehl ausgeführt werden "... --configure -a". Den genauen Wortlaut habe ich leider nicht mehr im Kopf. Bisher läuft das System ohne Problem. Ich bin sehr gespannt wie sich das Ganze entwickelt.

          Kommentar

            #6
            Hallo,

            bevor das Ganze in die völlig falsche Richtung läuft, vielleicht mal ein paar erklärende Worte.

            Es ist kein einziger Fall eines Firmwarebugs bekannt, welcher unbeabsichtigterweise zu einem Reboot führt. Vielmehr gibt es zahlreiche Watchdogs und Überwachungsmechanismen, welche im Fehlerzustand bewusst einen Reboot veranlassen, im Versuch die Betriebsbereitschaft wiederherzustellen. Folglich ist weder zu erwarten, dass jedes hier genannte Reboot auf die gleiche Ursache zurückzuführen ist, noch ist es ratsam die Watchdogs zu deaktivieren, da somit allenfalls das Reboot aber nicht der zugrundeliegende auslösende Fehlerzustand behoben wird.

            Wie Hr. Deutinger bereits schilderte, sollten derartige Probleme daher individuell durch unsere Hotline untersucht und analysiert werden. Aus einem kurzen Traceausschnitt lässt sich meist ohnehin kaum etwas ermitteln, da die auslösenden Ereignisse durchaus schon einige Zeit zurückliegen können.

            Im speziellen Fall des lordlamer lässt der oben gezeigte Ausschnitt der OMCUMS-Logdatei jedoch vermuten, dass die Ursache vielmehr in einer fehleingestellten Uhrzeit des Serverhosts begründet ist, welche gravierend von der vom OfficeMaster Gate ermittelten ntp-Zeit abweicht. Dies lassen aber nur die Indizien dieses speziellen Rebootfalls vermuten und kann endgültig auch nur mittels eines vollständigen Logs (im Rahmen einer Hotlineanfrage) geklärt werden.

            Gruß
            Waldemar

            Kommentar

            Vorherige template Weiter
            Lädt...
            X