Webserver sporadisch nicht erreichbar

[xelarep]

Hallo,

ich hab nun seit ein paar Wochen Zeit meine DS zwecks Photostation und einer kleinen Startseite für meine Verwandtschaft über's Web per DynDNS erreichbar gemacht. Meine DS fährt jeden Tag um 8:00 Uhr hoch und legt sich um Mitternacht schlafen.

Prinzipiell funktioniert das auch alles hervorragend. Allerdings ist es mir jetzt schon 2x passiert, dass der Webserver weder extern (DynDNS) noch intern (feste IP) erreichbar ist. Ich kann mich noch übers Webmanagement anmelden auf die Shares zugreifen usw. Es scheint also nur der Webserver nicht zu laufen. Richtig "helfen" tut ein Neustart der DS, dann geht wieder alles.

In den Log's die ich per Managementoberfläche sehe bekomm ich keine weiteren Infos.

In welchen logfiles und wo müsste ich nachsehen um weitere sachdienliche Hinweise auf mein Problem zu bekommen?

Ich verwende DSM 2.1-0844

Gruß,
Alexander

 

[itari]

Wann kann man deine DS nicht mehr erreichen? Morgens nach dem Aufwecken der DS? Oder geht es mitten am Tag auf einmal nicht mehr?

Itari

 

[jahlives]

Ich kann mich noch übers Webmanagement anmelden auf die Shares zugreifen usw. Es scheint also nur der Webserver nicht zu laufen. Richtig "helfen" tut ein Neustart der DS, dann geht wieder alles.

Der Webserver muss aber laufen wenn du dich am Webmanagement anmelden kannst. Den Neustart kannst du ja über das Webmanagement auslösen.
Interessant wäre es aber mal zu wissen ob der User Apache in diesem Falle läuft oder nicht.
Wenn also der Server nicht erreichbar ist, dann melde dich aus dem LAN mal per telnet oder ssh am Server an und schau mittels

$ ps | grep httpd

ob auch eine Instanz des Webservers unter nobody läuft

 

[xelarep]

Wann kann man deine DS nicht mehr erreichen? Morgens nach dem Aufwecken der DS? Oder geht es mitten am Tag auf einmal nicht mehr? Itari

Also prinzipiell nach dem Aufwecken. Dass Sie später mal nicht erreichbar, wenn ich vorher schon mal darauf zugegriffen habe, habe ich bisher noch nicht feststellen können.

 

[itari]

Das sieht dann so aus, wie es Tobi schon vermutet hat, der User-Apache läuft nicht ordentlich. Schau mal auf der Kommandozeile ins Logbuch:

grep httpd /var/log/messages

ob da irgendwelche Zeilen angezeigt werden.

Itari

 

[xelarep]

Der Webserver muss aber laufen wenn du dich am Webmanagement anmelden kannst. Den Neustart kannst du ja über das Webmanagement auslösen.

Du meinst den kompletten Neustart der DS? Das hab ich auch schon mal so gemacht. Ansonsten halt per 4s On-Schalter drücken.

Interessant wäre es aber mal zu wissen ob der User Apache in diesem Falle läuft oder nicht.
Wenn also der Server nicht erreichbar ist, dann melde dich aus dem LAN mal per telnet oder ssh am Server an und schau mittels

$ ps | grep httpd

ob auch eine Instanz des Webservers unter nobody läuft

OK, werde ich beim nächsten mal testen. Blöd ist halt, dass das sporadisch ist.
Gibt's nicht irgendwo ein log wo ich das für die letzten X-Tage nachschauen kann?

 

[xelarep]

Das sieht dann so aus, wie es Tobi schon vermutet hat, der User-Apache läuft nicht ordentlich. Schau mal auf der Kommandozeile ins Logbuch:

grep httpd /var/log/messages

ob da irgendwelche Zeilen angezeigt werden.

Itari

Prima, sowas hab ich gemeint. Schau ich mir heute abend an und melde mich dann wieder.

Danke,
Alexander

 

[xelarep]

Sodele, gerade läuft der httpd.

ps | grep httpd

liefert 4 prozesse für 'root' und 5 für 'nobody'

grep httpd /var/log/messages

ist leer

In dem ganzen Verzeichnis /var/log/messages ist nix drin?! Ich war ber SSH als root angemeldet.

Und nun?

Alexander

 

[xelarep]

Erst denken dann antworten... Hab' gerade kapiert, dass 'messages' eine Datei und kein Verzeichnis ist...

Hier ist der Auszug vom letzten "Klemmer". Ich kann darin nichts aussergewöhnliches entdecken?!

Jul 27 08:00:22 kernel: CPU: ARM926EJ-Sid(wb) [41069260] revision 0 (ARMv5TEJ)
Jul 27 08:00:22 kernel: Machine: MV-88fxx81
Jul 27 08:00:22 kernel: Using UBoot passing parameters structure
Jul 27 08:00:22 kernel: Sys Clk = 166666667, Tclk = 166666667
Jul 27 08:00:22 kernel: Internal HD num: 0
Jul 27 08:00:22 kernel: Synology Hareware Version: DS107v30
Jul 27 08:00:22 kernel: Memory policy: ECC disabled, Data cache writeback
Jul 27 08:00:22 kernel: CPU0: D VIVT write-back cache
Jul 27 08:00:22 kernel: CPU0: I cache: 32768 bytes, associativity 1, 32 byte lines, 1024 sets
Jul 27 08:00:22 kernel: CPU0: D cache: 32768 bytes, associativity 4, 32 byte lines, 256 sets
Jul 27 08:00:22 kernel: Built 1 zonelists
Jul 27 08:00:22 kernel: PID hash table entries: 1024 (order: 10, 16384 bytes)
Jul 27 08:00:22 kernel: Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
Jul 27 08:00:22 kernel: Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
Jul 27 08:00:22 kernel: Mount-cache hash table entries: 512
Jul 27 08:00:22 kernel: 
Jul 27 08:00:22 kernel: CPU Interface
Jul 27 08:00:22 kernel: -------------
Jul 27 08:00:22 kernel: SDRAM_CS0 ....base 00000000, size 128MB 
Jul 27 08:00:22 kernel: SDRAM_CS1 ....disable
Jul 27 08:00:22 kernel: SDRAM_CS2 ....disable
Jul 27 08:00:22 kernel: SDRAM_CS3 ....disable
Jul 27 08:00:22 kernel: PEX0_MEM ....base e0000000, size 128MB 
Jul 27 08:00:22 kernel: PEX0_IO ....base f2000000, size   1MB 
Jul 27 08:00:22 kernel: PCI0_MEM ....base e8000000, size 128MB 
Jul 27 08:00:22 kernel: PCI0_IO ....base f2100000, size   1MB 
Jul 27 08:00:22 kernel: INTER_REGS ....base f1000000, size   1MB 
Jul 27 08:00:22 kernel: DEVICE_CS0 ....base fa000000, size   2MB 
Jul 27 08:00:22 kernel: DEVICE_CS1 ....base f8000000, size  32MB 
Jul 27 08:00:22 kernel: DEVICE_CS2 ....base fa800000, size   1MB 
Jul 27 08:00:22 kernel: DEV_BOOCS ....base ffc00000, size   4MB 
Jul 27 08:00:22 kernel: Marvell USB EHCI Host controller #0: c0bf3e00
Jul 27 08:00:22 kernel: Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
Jul 27 08:00:22 kernel: RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
Jul 27 08:00:22 kernel: Marvell Gigabit Ethernet Driver 'egiga':
Jul 27 08:00:22 kernel:   o Ethernet descriptors in DRAM
Jul 27 08:00:22 kernel:   o DRAM SW cache-coherency
Jul 27 08:00:22 kernel:   o Checksum offload enabled
Jul 27 08:00:22 kernel:   o Loading network interface 'egiga0' as eth0
Jul 27 08:00:22 kernel:   o Radom MAC address 00:8c:09:31:d4:bf
Jul 27 08:00:22 kernel: 
Jul 27 08:00:22 kernel: ata1: Device not ready. Try to reset...
Jul 27 08:00:22 kernel: drivers/scsi/sd.c (1713) Internal disk with bus id: 0
Jul 27 08:00:22 kernel:  Amd/Fujitsu Extended Query Table at 0x0040
Jul 27 08:00:22 kernel: DS406-0: Swapping erase regions for broken CFI table.
Jul 27 08:00:22 kernel: Mac1: 00:11:32:04:05:39
Jul 27 08:00:22 kernel: vender Mac1 checksum error ucSum:0x00 Buf:0x00 Sum:0.
Jul 27 08:00:22 kernel: Vender partition MacNum:1 retlen:128
Jul 27 08:00:22 kernel: Serial Number: 89E3N00537
Jul 27 08:00:22 kernel: raid6: int32x1     29 MB/s
Jul 27 08:00:22 kernel: raid6: int32x2     45 MB/s
Jul 27 08:00:22 kernel: raid6: int32x4     51 MB/s
Jul 27 08:00:22 kernel: raid6: int32x8     48 MB/s
Jul 27 08:00:22 kernel: raid6: using algorithm int32x4 (51 MB/s)
Jul 27 08:00:22 kernel:    arm4regs  :   429.600 MB/sec
Jul 27 08:00:22 kernel:    8regs     :   369.200 MB/sec
Jul 27 08:00:22 kernel:    32regs    :   513.600 MB/sec
Jul 27 08:00:22 kernel: raid5: using function: 32regs (513.600 MB/sec)
Jul 27 08:00:22 kernel: IP route cache hash table entries: 2048 (order: 1, 8192 bytes)
Jul 27 08:00:22 kernel: TCP established hash table entries: 8192 (order: 3, 32768 bytes)
Jul 27 08:00:22 kernel: TCP bind hash table entries: 8192 (order: 3, 32768 bytes)
Jul 27 08:00:22 kernel: VFS: Mounted root (ext2 filesystem).
Jul 27 08:00:22 kernel: ds107+_synobios: module license 'Synology Inc.' taints kernel.
Jul 27 08:00:22 kernel: Brand: Synology
Jul 27 08:00:22 kernel: Model: DS-107+
Jul 27 08:00:22 kernel: synobios: unload
Jul 27 08:00:22 kernel: EXT3-fs warning: maximal mount count reached, running e2fsck is recommended
Jul 27 08:00:22 kernel: VFS: Mounted root (ext3 filesystem).
Jul 27 08:00:22 kernel: Brand: Synology
Jul 27 08:00:22 kernel: Model: DS-107+
Jul 27 08:00:23 kernel: EXT3-fs warning: maximal mount count reached, running e2fsck is recommended
Jul 27 08:00:29 scemd: scemd.c:97 fan_type=5,  led_type=2, raid_type=2, dual_power_type=1, auto_poweron_type=1
Jul 27 08:00:29 scemd: modules/disk_hibernation.c:86 Force hibernation enable, idle minutes 15
Jul 27 08:00:29 synoprint: printer_device_open.c:16 bad parameter.
Jul 27 08:00:29 synousbdisk: RCClean succeeded
Jul 27 08:00:32 synocheckshare: service_user_home.c:276 SYNOShareRSectionRemove failed. synoerr=[0x2000]
Jul 27 08:00:33 ddnsd: main(ddnsd.c:1729):  not enable DDNS, shutdown daemon 
Jul 27 08:00:38 kernel: Got empty serial number. Generate serial number from product.
Jul 27 08:00:39 syno_hdd_util: Model:[WDC WD5000AAJS-0], Firmware:[01.03B01], S/N:[WD-WMASY1388720] in [/dev/sda] is not ssd
Jul 27 08:00:50 synorcd: hw_raytac.c (126) failed to open /dev/usb/hiddev5 (No such device).
Jul 27 08:01:57 kernel: ata_qc_timeout^I(3360): cannot delete scsicmd timer
Jul 27 08:01:57 kernel: ata1: command 0x25 timeout, stat 0x50 host_stat 0x0
Jul 27 11:54:26 scemd: scemd: power button pressed, ret = 0
Jul 27 11:54:26 scemd: SCEMD: Shutdown the system.

8:00 Uhr automatischer Start, 11:54 manueller Reset per PowerButton

Any ideas?

Alexander

 

[goetz]

Hallo,
der apache ist von Hause aus mundtot. Du könntest an der /usr/syno/apache/config/httpd.conf-user drehen und die Einträge für die logs anpassen

# ErrorLog: The location of the error log file.
# If you do not specify an ErrorLog directive within a <VirtualHost>
# container, error messages relating to that virtual host will be
# logged here.  If you *do* define an error logfile for a <VirtualHost>
# container, that host's errors will be logged there and not here.
#
#ErrorLog /var/log/httpd-error-user.log
ErrorLog /dev/null
TraceEnable off

#
# LogLevel: Control the number of messages logged to the error_log.
# Possible values include: debug, info, notice, warn, error, crit,
# alert, emerg.
#
#LogLevel debug
LogLevel warn

und schauen was da landet.
Gruß Götz

 

[itari]

Wie Götz schon sagt, offensichtlich muss man sich nun den Apache vornehmen, weil es wohl offensichtlich - laut /var/log/messages - keine äußeren Einflüsse gibt, die den Webserver still legen.

Itari

 

[xelarep]

Danke euch beiden, sobald Töchterchen heute abend in der Heia liegt werd ich das mal machen.

Bisher gab's keine Ausfälle mehr. Aber ich möchte auf den nächsten vorbereitet sein

Alexander

 

[steffi]

hallo

ich kann zwar nur vermuten, aber schau dir mal diesen beitrag an: KLICK

dort gibt es augenscheinlich ein ähnliches problem mit dem webserver. du könntest zu testzwecken den cache ebenfalls abschalten. sollte der server danach durchlaufen, dann würde ein update auf die neue beta dein problem beheben.

 

[xelarep]

Hallo

danke steffi für den Link. Hört sich ähnlich an. Werde das mal verfolgen und auch das Abschalten des caches testen.

Gerade war's mal wieder soweit: Keine Verbindung zum Webserver. Also mal schnell alle obigen Prozeduren durchlaufen:

$ps | grep httpd liefert keine Prozesse für nobody!
$grep httpd /var/log/messages ist wieder leer

Hatte aber logging auch noch nicht aktiviert...

Hier nochmal die komplette messages datei für heute

Aug  5 00:30:11 scheduler: scheduler.c (1346) Got signal. Die gracefully.
Aug  5 00:30:11 scheduler: scheduler.c (1364) rTorrent is killed.
Aug  5 08:00:22 kernel: Mac1: 00:11:32:04:05:39
Aug  5 08:00:22 kernel: vender Mac1 checksum error ucSum:0x00 Buf:0x00 Sum:0.
Aug  5 08:00:22 kernel: Vender partition MacNum:1 retlen:128
Aug  5 08:00:22 kernel: Serial Number: 89E3N00537
Aug  5 08:00:22 kernel: raid6: int32x1     29 MB/s
Aug  5 08:00:22 kernel: raid6: int32x2     45 MB/s
Aug  5 08:00:22 kernel: raid6: int32x4     52 MB/s
Aug  5 08:00:22 kernel: raid6: int32x8     48 MB/s
Aug  5 08:00:22 kernel: raid6: using algorithm int32x4 (52 MB/s)
Aug  5 08:00:22 kernel:    arm4regs  :   429.600 MB/sec
Aug  5 08:00:22 kernel:    8regs     :   369.200 MB/sec
Aug  5 08:00:22 kernel:    32regs    :   513.600 MB/sec
Aug  5 08:00:22 kernel: raid5: using function: 32regs (513.600 MB/sec)
Aug  5 08:00:22 kernel: IP route cache hash table entries: 2048 (order: 1, 8192 bytes)
Aug  5 08:00:22 kernel: TCP established hash table entries: 8192 (order: 3, 32768 bytes)
Aug  5 08:00:22 kernel: TCP bind hash table entries: 8192 (order: 3, 32768 bytes)
Aug  5 08:00:22 kernel: VFS: Mounted root (ext2 filesystem).
Aug  5 08:00:22 kernel: ds107+_synobios: module license 'Synology Inc.' taints kernel.
Aug  5 08:00:22 kernel: Brand: Synology
Aug  5 08:00:22 kernel: Model: DS-107+
Aug  5 08:00:22 kernel: synobios: unload
Aug  5 08:00:22 kernel: EXT3-fs warning: maximal mount count reached, running e2fsck is recommended
Aug  5 08:00:22 kernel: VFS: Mounted root (ext3 filesystem).
Aug  5 08:00:22 kernel: Brand: Synology
Aug  5 08:00:22 kernel: Model: DS-107+
Aug  5 08:00:23 kernel: EXT3-fs warning: maximal mount count reached, running e2fsck is recommended
Aug  5 08:00:28 scemd: scemd.c:97 fan_type=5,  led_type=2, raid_type=2, dual_power_type=1, auto_poweron_type=1
Aug  5 08:00:28 scemd: modules/disk_hibernation.c:86 Force hibernation enable, idle minutes 15
Aug  5 08:00:29 synoprint: printer_device_open.c:16 bad parameter.
Aug  5 08:00:29 synousbdisk: RCClean succeeded
Aug  5 08:00:32 synocheckshare: service_user_home.c:276 SYNOShareRSectionRemove failed. synoerr=[0x2000]
Aug  5 08:00:33 ddnsd: main(ddnsd.c:1729):  not enable DDNS, shutdown daemon 
Aug  5 08:00:38 kernel: Got empty serial number. Generate serial number from product.
Aug  5 08:00:39 syno_hdd_util: Model:[WDC WD5000AAJS-0], Firmware:[01.03B01], S/N:[WD-WMASY1388720] in [/dev/sda] is not ssd
Aug  5 08:00:54 synorcd: hw_raytac.c (126) failed to open /dev/usb/hiddev5 (No such device).
Aug  5 08:02:00 kernel: ata_qc_timeout^I(3360): cannot delete scsicmd timer
Aug  5 08:02:00 kernel: ata1: command 0x25 timeout, stat 0x50 host_stat 0x0

Vielleicht sieht da wer was

Alexander

 

[steffi]

Hallo

danke steffi für den Link. Hört sich ähnlich an. Werde das mal verfolgen und auch das Abschalten des caches testen.


Alexander

hallo

das abschalten des cache nimmt nur ein paar minuten in anspruch.
dies kannst du einfach im ds management erledigen. (third party applikations ---> config file editor ---> php ; hier dann runterscrollen zum eaccelerator.cache)

so sollte der eintrag dann aussehen. KLICK

ich denke, du hast das selbe problem, wie ich (es hatte)....

 

[xelarep]

Hallo,

ich hab's dann doch noch bis zum Release der DSM 2.2 ausgehalten. Bin mal gespannt was mein Webserver die nächsten Tage so macht. Ich hatte die letzten Wochen nur 2-3 Ausfälle (die ich auch mitbekommen habe) ohne was zu ändern.

Gruß,
Alexander

 

[xelarep]

Schade,

heute war's wieder soweit. Konnte meine Webseite/Photostation nicht erreichen Also Reboot.

Hab gerade bei Synology ein Ticket aufgemacht und meine Kerneldumps und logs abgeworfen. Hab eh noch ein Ticket offen wegen meinen Runterfahrhängern. Mal gespannt was da rauskommt. Denke mal, dass das zusammenhängt.

Wird diese Woche wohl nix mehr, bei Sysnology ist internes Training

Halte euch auf dem Laufenden!

Alexander

 

[brakeprofi]

Schade,

heute war's wieder soweit. Konnte meine Webseite/Photostation nicht erreichen Also Reboot.

Hab gerade bei Synology ein Ticket aufgemacht und meine Kerneldumps und logs abgeworfen. Hab eh noch ein Ticket offen wegen meinen Runterfahrhängern. Mal gespannt was da rauskommt. Denke mal, dass das zusammenhängt.

Wird diese Woche wohl nix mehr, bei Sysnology ist internes Training

Halte euch auf dem Laufenden!

Alexander

Hab meine Fehlermeldung in die Suche eingeben und Deinen Beitrag gefunden.
Bei mir verursachen bestimmte Dateien die aufgerufen werden auch einen kompletten Hänger der DS107+ da geht dann nix mehr.

http://www.synology-forum.de/showthread.html?t=9768