Serveur qui crash sans raison

Support Debian
#1

Bonjour à tous !

Je suis nouveau sur ce forum, et j’ai un petit problème avec un serveur qui tourne sous Debian 8 avec deux seedbox dessus (RuTorrent + rTorrent), et de manière aléatoire ou lorsque qu’on envoie trop de torrent d’un coup, le serveur est down. Enfin c’est un peu plus compliqué, plus d’accès WEB, plus de SSH, mais il continue de répondre au ping… De plus, si j’attends 30/40 minutes, tout reviens à la normal (pendant 10 minutes avant de replanter). Le seul moyen pour moi de m’en sortir est de redémarrer le serveur depuis l’interface de l’hébergeur.

Il faut savoir que les deux seedbox sont limité à 30Mio/s chacune, et que les deux disque sont séparé comme ceci :
sda : [— sda1 RAID 1 —][— sda2 RAID 0 —]
sdb : [— sdb1 RAID 1—][— sdb2 RAID 0 —]
Bien sûr le système est sur le RAID 1, et la partition /home est sur le RAID 0. Les seedbox eneregistre les fichiers dans le dossier home de chaque user.

Voici le résultat de quelques commandes et log :

tutur:~/ $ sudo df -h                                                                                                                                        
[sudo] password for tutur:
Sys. de fichiers Taille Utilisé Dispo Uti% Monté sur
/dev/md1            48G    2,0G   44G   5% /
udev                10M       0   10M   0% /dev
tmpfs              1,6G    8,5M  1,6G   1% /run
tmpfs              3,9G       0  3,9G   0% /dev/shm
tmpfs              5,0M       0  5,0M   0% /run/lock
tmpfs              3,9G       0  3,9G   0% /sys/fs/cgroup
/dev/md0           1,7T    159G  1,5T  10% /home

Voici un bout de mon kern.log :

Jan 22 14:29:27 sperec kernel: [    5.679073] fbcon: inteldrmfb (fb0) is primary device
Jan 22 14:29:27 sperec kernel: [    5.702367] Console: switching to colour frame buffer device 128x48
Jan 22 14:29:27 sperec kernel: [    5.703938] i915 0000:00:02.0: fb0: inteldrmfb frame buffer device
Jan 22 14:29:27 sperec kernel: [    5.703939] i915 0000:00:02.0: registered panic notifier
Jan 22 14:29:27 sperec kernel: [    5.721879] i915: No ACPI video bus found
Jan 22 14:29:27 sperec kernel: [    5.721910] [drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0 on minor 0
Jan 22 14:29:27 sperec kernel: [    6.577500] EXT4-fs (md0): mounted filesystem with ordered data mode. Opts: (null)
Jan 22 14:29:27 sperec kernel: [    6.728293] atl1c 0000:02:00.0: irq 43 for MSI/MSI-X
Jan 22 14:29:27 sperec kernel: [    6.742926] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
Jan 22 14:29:27 sperec kernel: [    6.960858] atl1c 0000:02:00.0: atl1c: eth0 NIC Link is Up<1000 Mbps Full Duplex>
Jan 22 14:29:27 sperec kernel: [    6.960874] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
Jan 22 14:29:27 sperec kernel: [    7.013810] [drm] Enabling RC6 states: RC6 on, RC6p off, RC6pp off
Jan 22 14:29:30 sperec kernel: [   10.723106] ip_tables: (C) 2000-2006 Netfilter Core Team
Jan 22 16:00:19 sperec kernel: [ 5458.714295] Peer 0000:0000:0000:0000:0000:ffff:53e4:91e2:6883/50278 unexpectedly shrunk window 2880852938:2880855818 (repaired)
Jan 22 16:00:20 sperec kernel: [ 5459.338124] Peer 0000:0000:0000:0000:0000:ffff:53e4:91e2:6883/50278 unexpectedly shrunk window 2880852938:2880855818 (repaired)
Jan 22 16:00:30 sperec kernel: [ 5469.579901] Peer 0000:0000:0000:0000:0000:ffff:53e4:91e2:6883/50278 unexpectedly shrunk window 2881100890:2881103770 (repaired)
Jan 22 16:00:31 sperec kernel: [ 5470.139773] Peer 0000:0000:0000:0000:0000:ffff:53e4:91e2:6883/50278 unexpectedly shrunk window 2881100890:2881103770 (repaired)
Jan 22 16:00:32 sperec kernel: [ 5471.263540] Peer 0000:0000:0000:0000:0000:ffff:53e4:91e2:6883/50278 unexpectedly shrunk window 2881100890:2881103770 (repaired)
Jan 22 16:01:27 sperec kernel: [ 5526.559325] Peer 0000:0000:0000:0000:0000:ffff:53e4:91e2:6883/50278 unexpectedly shrunk window 2882210782:2882222302 (repaired)
Jan 22 16:01:44 sperec kernel: [ 5543.567569] Peer 0000:0000:0000:0000:0000:ffff:53e4:91e2:6883/50278 unexpectedly shrunk window 2882610193:2882614526 (repaired)
Jan 22 16:01:49 sperec kernel: [ 5548.110564] Peer 0000:0000:0000:0000:0000:ffff:53e4:91e2:6883/50278 unexpectedly shrunk window 2882742526:2882743870 (repaired)
Jan 22 16:01:50 sperec kernel: [ 5548.902391] Peer 0000:0000:0000:0000:0000:ffff:53e4:91e2:6883/50278 unexpectedly shrunk window 2882742526:2882743870 (repaired)
Jan 22 16:01:56 sperec kernel: [ 5555.704887] Peer 0000:0000:0000:0000:0000:ffff:53e4:91e2:6883/50278 unexpectedly shrunk window 2882938702:2882940238 (repaired)
Jan 22 16:01:57 sperec kernel: [ 5556.296760] Peer 0000:0000:0000:0000:0000:ffff:53e4:91e2:6883/50278 unexpectedly shrunk window 2882938702:2882940238 (repaired)
Jan 22 16:01:58 sperec kernel: [ 5557.484463] Peer 0000:0000:0000:0000:0000:ffff:53e4:91e2:6883/50278 unexpectedly shrunk window 2882938702:2882940238 (repaired)
Jan 22 16:49:56 sperec kernel: [    0.000000] Initializing cgroup subsys cpuset
Jan 22 16:49:56 sperec kernel: [    0.000000] Initializing cgroup subsys cpu
Jan 22 16:49:56 sperec kernel: [    0.000000] Initializing cgroup subsys cpuacct
Jan 22 16:49:56 sperec kernel: [    0.000000] Linux version 3.16.0-4-amd64 (debian-kernel@lists.debian.org) (gcc version 4.8.4 (Debian 4.8.4-1) ) #1 SMP Debian 3.16.39-1 (2016-12-30)

Vous pouvez voir qu’on a plus rien à partir de 14H30, qu’il a donné un nouveau signe de vie pendant deux minutes, et plus rien jusqu’à ce que je redémarre à 16H50. Et tous mes logs sont comme ça, aucune trace de vie, pas une ligne rien…

J’avoue que je commence à sécher, j’ai même surveiller les I/O sur les disques (on dépasse rarement les 60Mo/s sur md0), la RAM ne dépasse jamais les 50/60%… Je bloque totalement :smile:

Si vous avez besoin de log, de fichier de configuration, n’importe quoi, n’hésitez pas :wink:

Et merci d’avance pour votre aide :smiley:

#2

C’est-à-dire, concrètement ?
Une session SSH en cours ne répond plus ?
Refus de nouvelle connexion ?
Time-out sur une nouvelle demande de connexion ?
Autre ?

L’absence de messages dans les logs du noyau ne signifie pas forcément qu’il y a un problème. C’est aussi le cas quand il ne se passe rien de nouveau qui intéresse le noyau.

#3

Si j’ai une session en cours, j’obtiens ce message :

tutur:~/ $ Write failed: Broken pipe

Si je veux me connecter à nouveau j’obtiens ceci :

ssh: connect to host sperec.fr port 22: Resource temporarily unavailable

Après je n’ai rien non plus dans syslog, mais effectivement ça ne prouve rien du tout :confused:

#4

Je suppose que tu as écumé le web à la recherche des causes possibles de ces messages, comme la limite du nombre de processus.

#5

Ça fait effectivement quelques jours que je cherche, mais je ne me suis pas trop penché sur le sujet, puisque l’installation de Debian à été fait il y a quelques jours, et il n’y a que Apache, les deux rTorrent et un serveur FTP qui tourne sur un core i3 et 8Go de ram, je penses que ça devrait suffire :smiley:

#6

Salut,

Tu peux nous filer le retour des commandes sudo smartctl -a /dev/sda et sudo smartctl -a /dev/sdb.
S’il te dit que la commande smartctl n’existe pas, elle se trouve dans le paquet smartmontools.

Je ne connaissais pas ce message…

#7

Alors voilà pour sda :

smartctl 6.4 2014-10-07 r4002 [x86_64-linux-3.16.0-4-amd64] (local build)
Copyright (C) 2002-14, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Model Family:     Western Digital Caviar Green (AF, SATA 6Gb/s)
Device Model:     WDC WD10EZRX-00A8LB0
Serial Number:    WD-WMC1U8047095
LU WWN Device Id: 5 0014ee 6ada1f2d1
Firmware Version: 01.01A01
User Capacity:    1 000 204 886 016 bytes [1,00 TB]
Sector Sizes:     512 bytes logical, 4096 bytes physical
Device is:        In smartctl database [for details use: -P show]
ATA Version is:   ATA8-ACS (minor revision not indicated)
SATA Version is:  SATA 3.0, 6.0 Gb/s (current: 3.0 Gb/s)
Local Time is:    Mon Jan 23 09:51:23 2017 CET
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

General SMART Values:
Offline data collection status:  (0x82)	Offline data collection activity
					was completed without error.
					Auto Offline Data Collection: Enabled.
Self-test execution status:      (   0)	The previous self-test routine completed
					without error or no self-test has ever 
					been run.
Total time to complete Offline 
data collection: 		(12540) seconds.
Offline data collection
capabilities: 			 (0x7b) SMART execute Offline immediate.
					Auto Offline data collection on/off support.
					Suspend Offline collection upon new
					command.
					Offline surface scan supported.
					Self-test supported.
					Conveyance Self-test supported.
					Selective Self-test supported.
SMART capabilities:            (0x0003)	Saves SMART data before entering
					power-saving mode.
					Supports SMART auto save timer.
Error logging capability:        (0x01)	Error logging supported.
					General Purpose Logging supported.
Short self-test routine 
recommended polling time: 	 (   2) minutes.
Extended self-test routine
recommended polling time: 	 ( 144) minutes.
Conveyance self-test routine
recommended polling time: 	 (   5) minutes.
SCT capabilities: 	       (0x30b5)	SCT Status supported.
					SCT Feature Control supported.
					SCT Data Table supported.

SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x002f   200   200   051    Pre-fail  Always       -       0
  3 Spin_Up_Time            0x0027   139   138   021    Pre-fail  Always       -       4016
  4 Start_Stop_Count        0x0032   100   100   000    Old_age   Always       -       12
  5 Reallocated_Sector_Ct   0x0033   200   200   140    Pre-fail  Always       -       0
  7 Seek_Error_Rate         0x002e   100   253   000    Old_age   Always       -       0
  9 Power_On_Hours          0x0032   063   063   000    Old_age   Always       -       27313
 10 Spin_Retry_Count        0x0032   100   253   000    Old_age   Always       -       0
 11 Calibration_Retry_Count 0x0032   100   253   000    Old_age   Always       -       0
 12 Power_Cycle_Count       0x0032   100   100   000    Old_age   Always       -       12
192 Power-Off_Retract_Count 0x0032   200   200   000    Old_age   Always       -       10
193 Load_Cycle_Count        0x0032   134   134   000    Old_age   Always       -       200623
194 Temperature_Celsius     0x0022   118   089   000    Old_age   Always       -       25
196 Reallocated_Event_Count 0x0032   200   200   000    Old_age   Always       -       0
197 Current_Pending_Sector  0x0032   200   200   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0030   200   200   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x0032   200   200   000    Old_age   Always       -       0
200 Multi_Zone_Error_Rate   0x0008   200   200   000    Old_age   Offline      -       0

SMART Error Log Version: 1
No Errors Logged

SMART Self-test log structure revision number 1
Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Extended offline    Completed without error       00%     11367         -
# 2  Extended offline    Aborted by host               10%     11363         -

SMART Selective self-test log data structure revision number 1
 SPAN  MIN_LBA  MAX_LBA  CURRENT_TEST_STATUS
    1        0        0  Not_testing
    2        0        0  Not_testing
    3        0        0  Not_testing
    4        0        0  Not_testing
    5        0        0  Not_testing
Selective self-test flags (0x0):
  After scanning selected spans, do NOT read-scan remainder of disk.
If Selective self-test is pending on power-up, resume after 0 minute delay.

Et la c’est pour sdb :

smartctl 6.4 2014-10-07 r4002 [x86_64-linux-3.16.0-4-amd64] (local build)
Copyright (C) 2002-14, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Model Family:     Western Digital Caviar Green (AF, SATA 6Gb/s)
Device Model:     WDC WD10EZRX-00A8LB0
Serial Number:    WD-WMC1U7938850
LU WWN Device Id: 5 0014ee 6584d57e6
Firmware Version: 01.01A01
User Capacity:    1 000 204 886 016 bytes [1,00 TB]
Sector Sizes:     512 bytes logical, 4096 bytes physical
Device is:        In smartctl database [for details use: -P show]
ATA Version is:   ATA8-ACS (minor revision not indicated)
SATA Version is:  SATA 3.0, 6.0 Gb/s (current: 3.0 Gb/s)
Local Time is:    Mon Jan 23 09:50:54 2017 CET
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

General SMART Values:
Offline data collection status:  (0x82)	Offline data collection activity
					was completed without error.
					Auto Offline Data Collection: Enabled.
Self-test execution status:      (   0)	The previous self-test routine completed
					without error or no self-test has ever 
					been run.
Total time to complete Offline 
data collection: 		(12660) seconds.
Offline data collection
capabilities: 			 (0x7b) SMART execute Offline immediate.
					Auto Offline data collection on/off support.
					Suspend Offline collection upon new
					command.
					Offline surface scan supported.
					Self-test supported.
					Conveyance Self-test supported.
					Selective Self-test supported.
SMART capabilities:            (0x0003)	Saves SMART data before entering
					power-saving mode.
					Supports SMART auto save timer.
Error logging capability:        (0x01)	Error logging supported.
					General Purpose Logging supported.
Short self-test routine 
recommended polling time: 	 (   2) minutes.
Extended self-test routine
recommended polling time: 	 ( 145) minutes.
Conveyance self-test routine
recommended polling time: 	 (   5) minutes.
SCT capabilities: 	       (0x30b5)	SCT Status supported.
					SCT Feature Control supported.
					SCT Data Table supported.

SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x002f   200   200   051    Pre-fail  Always       -       0
  3 Spin_Up_Time            0x0027   134   133   021    Pre-fail  Always       -       4283
  4 Start_Stop_Count        0x0032   100   100   000    Old_age   Always       -       12
  5 Reallocated_Sector_Ct   0x0033   200   200   140    Pre-fail  Always       -       0
  7 Seek_Error_Rate         0x002e   100   253   000    Old_age   Always       -       0
  9 Power_On_Hours          0x0032   057   057   000    Old_age   Always       -       32083
 10 Spin_Retry_Count        0x0032   100   253   000    Old_age   Always       -       0
 11 Calibration_Retry_Count 0x0032   100   253   000    Old_age   Always       -       0
 12 Power_Cycle_Count       0x0032   100   100   000    Old_age   Always       -       12
192 Power-Off_Retract_Count 0x0032   200   200   000    Old_age   Always       -       10
193 Load_Cycle_Count        0x0032   160   160   000    Old_age   Always       -       121113
194 Temperature_Celsius     0x0022   119   090   000    Old_age   Always       -       24
196 Reallocated_Event_Count 0x0032   200   200   000    Old_age   Always       -       0
197 Current_Pending_Sector  0x0032   200   200   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0030   200   200   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x0032   200   200   000    Old_age   Always       -       0
200 Multi_Zone_Error_Rate   0x0008   200   200   000    Old_age   Offline      -       0

SMART Error Log Version: 1
No Errors Logged

SMART Self-test log structure revision number 1
Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Extended offline    Completed without error       00%     13749         -

SMART Selective self-test log data structure revision number 1
 SPAN  MIN_LBA  MAX_LBA  CURRENT_TEST_STATUS
    1        0        0  Not_testing
    2        0        0  Not_testing
    3        0        0  Not_testing
    4        0        0  Not_testing
    5        0        0  Not_testing
Selective self-test flags (0x0):
  After scanning selected spans, do NOT read-scan remainder of disk.
If Selective self-test is pending on power-up, resume after 0 minute delay.

Pour le fameux message inconnu, ça peut venir du fait que j’utilise BashForWindows intégré avec Windows 10 ?

Merci de ton aide :wink:

#8

C’est le nouveau nom de Cygwin ?

1 J'aime
#9

Non je ne crois Cygwin est un logiciel tiers, BashForWindows c’est une association entre Microsoft et Canonical qui a permit de développer un sous système Linux entièrement intégré à Windows

#10

@Almtesh alors, là, j’avoue que tu fais fort … tu ne suis pas l’actu informatique ?!
Cela fait des mois qu’on en entend parler, du Bash dans Windows grâce à la collaboration Microsoft <=> Ubuntu.

@MrCourgettos Concernant le message SSH, sans plus d’info, il est normal vu les symptômes décris.

#11

Il me semblait que c’était un poisson d’avril. Ça existe vraiment ? Trop cool, ça donerai presque envie d’installer la version 9 de Debian.

1 J'aime
#12

@Almtesh Non non ce n’est pas un poisson d’avril ^^ Ça fonctionne même plutôt bien :wink:

@PengouinPdt Hum est ce que tu aurais une idée de où cela pourrait venir ? :confused: Ou besoin de plus d’informations ?

#13

2 seedboxs limitées à 30 Mio, ça fait tout de même du 600 Mbps, au final. Sans compter le débit utilisé par le reste des services.

As-tu vérifié que ce n’est pas ton hébergeur qui interrompt automatiquement l’accès réseau du serveur ?
Soit par un programme qui vérifie que les clients n’abusent pas sur la bande passante, soit par une “protection anti-DOS”.

–
AnonymousCoward

#14

Ah oui vu comme ça, ça fait beaucoup ^^ D’ailleurs j’ai avancé dans mes recherches et je me suis rendu compte que le serveur planté quand les deux seedbox télécharger plus de 30 torrent (cumulés), par contre aucun problème si tout est fait sur une seule des deux seedbox.

Mais comment est-ce qu’un trop gros download pourrait mettre down tout un serveur ?

@AnonymousCoward Merci pour ton aide, et je vais me renseigner auprès de mon hebergeur, mais même s’il me coupe l’accès réseau, je devrais avoir des logs non ?

Merci à tous pour votre aide :smiley:

#15

Est-ce indiscret de te demander s’il s’agit de l’offre “Core i3 3220” ou de l’offre “Celeron 8Go +” ?

Dans tous les cas de figure, cela fait entre 150Mbps et 100Mbps de débit garanti. Et il n’est pas trop précisé s’il s’agit de débit symétrique ou non.

Ceci dit, leurs CGV pour les dédiés précisent : […] se réserve le droit de restreindre, sans néanmoins désactiver, la bande passage mise à disposition du Client […]
Recopié fidèlement, faute comprise

Ce que tu peux faire pour tester, c’est faire tourner la commande ping pour tester régulièrement la connectivité. Et rediriger la sortie de la commande ping vers un fichier. Comme cela tu as un espoir de connaître le moment où tu perds la connexion.

Une commande dans ce goût là :

ping -n -i 60 91.229.20.1 | while IFS= read -r line; do printf '[%s] %s\n' "$(date '+%Y-%m-%d %H:%M:%S')" "$line"; done | tee ping.log

(juste faire attention à bien la lancer à l’intérieur d’un screen)

–
AnonymousCoward

#16

Alors c’est une offre qui n’est plus disponible, j’ai un i3 2100 depuis 2012, et à ce moment là la bande passante garantie n’étais que de 10Mbps, depuis ils ont changé leurs réseau et je ne me suis jamais renseigné sur la nouvelle BP garantie :confused:

Je vais lancer la commande dans un screen et provoquer un plantage (en lançant pas mal de torrent), on verra bien ce qu’il se passe sur le serveur :wink:

Merci de ton aide :slight_smile:

[EDIT à 22H05]
Voilà les résultats : j’ai lancé pleins de torrents à 21H30, tout de suite plus aucun accès (SSH, WEB, mais réponse au ping), et voilà les résultats :

[2017-01-23 21:18:09] PING 91.229.20.1 (91.229.20.1) 56(84) bytes of data.
[2017-01-23 21:18:09] 64 bytes from 91.229.20.1: icmp_seq=1 ttl=255 time=0.209 ms
[2017-01-23 21:19:11] 64 bytes from 91.229.20.1: icmp_seq=2 ttl=255 time=0.273 ms
[2017-01-23 21:20:12] 64 bytes from 91.229.20.1: icmp_seq=3 ttl=255 time=0.282 ms
[2017-01-23 21:21:13] 64 bytes from 91.229.20.1: icmp_seq=4 ttl=255 time=0.295 ms
[2017-01-23 21:22:15] 64 bytes from 91.229.20.1: icmp_seq=5 ttl=255 time=0.279 ms
[2017-01-23 21:23:16] 64 bytes from 91.229.20.1: icmp_seq=6 ttl=255 time=0.351 ms
[2017-01-23 21:24:18] 64 bytes from 91.229.20.1: icmp_seq=7 ttl=255 time=0.206 ms
[2017-01-23 21:25:19] 64 bytes from 91.229.20.1: icmp_seq=8 ttl=255 time=0.288 ms
[2017-01-23 21:26:21] 64 bytes from 91.229.20.1: icmp_seq=9 ttl=255 time=0.302 ms
[2017-01-23 21:27:21] 64 bytes from 91.229.20.1: icmp_seq=10 ttl=255 time=0.276 ms
[2017-01-23 21:28:21] 64 bytes from 91.229.20.1: icmp_seq=11 ttl=255 time=0.234 ms
[2017-01-23 21:29:21] 64 bytes from 91.229.20.1: icmp_seq=12 ttl=255 time=0.359 ms
[2017-01-23 21:30:21] 64 bytes from 91.229.20.1: icmp_seq=13 ttl=255 time=0.215 ms
[2017-01-23 21:31:22] 64 bytes from 91.229.20.1: icmp_seq=14 ttl=255 time=0.284 ms
[2017-01-23 21:32:23] 64 bytes from 91.229.20.1: icmp_seq=15 ttl=255 time=2.38 ms
[2017-01-23 21:33:23] 64 bytes from 91.229.20.1: icmp_seq=16 ttl=255 time=0.278 ms
[2017-01-23 21:34:24] 64 bytes from 91.229.20.1: icmp_seq=17 ttl=255 time=0.300 ms
[2017-01-23 21:35:24] 64 bytes from 91.229.20.1: icmp_seq=18 ttl=255 time=0.268 ms
[2017-01-23 21:36:24] 64 bytes from 91.229.20.1: icmp_seq=19 ttl=255 time=0.566 ms
[2017-01-23 21:37:24] 64 bytes from 91.229.20.1: icmp_seq=20 ttl=255 time=0.289 ms
[2017-01-23 21:38:26] 64 bytes from 91.229.20.1: icmp_seq=21 ttl=255 time=0.273 ms
[2017-01-23 21:39:26] 64 bytes from 91.229.20.1: icmp_seq=22 ttl=255 time=0.274 ms
[2017-01-23 21:40:26] 64 bytes from 91.229.20.1: icmp_seq=23 ttl=255 time=0.267 ms
[2017-01-23 21:41:28] 64 bytes from 91.229.20.1: icmp_seq=24 ttl=255 time=0.269 ms
[2017-01-23 21:42:28] 64 bytes from 91.229.20.1: icmp_seq=25 ttl=255 time=0.246 ms
[2017-01-23 21:43:29] 64 bytes from 91.229.20.1: icmp_seq=26 ttl=255 time=0.368 ms
[2017-01-23 21:44:30] 64 bytes from 91.229.20.1: icmp_seq=27 ttl=255 time=0.285 ms
[2017-01-23 21:45:30] 64 bytes from 91.229.20.1: icmp_seq=28 ttl=255 time=0.335 ms
[2017-01-23 21:46:30] 64 bytes from 91.229.20.1: icmp_seq=29 ttl=255 time=0.263 ms
[2017-01-23 21:47:30] 64 bytes from 91.229.20.1: icmp_seq=30 ttl=255 time=0.322 ms
[2017-01-23 21:48:32] 64 bytes from 91.229.20.1: icmp_seq=31 ttl=255 time=0.275 ms
[2017-01-23 21:49:33] 64 bytes from 91.229.20.1: icmp_seq=32 ttl=255 time=0.349 ms
[2017-01-23 21:50:35] 64 bytes from 91.229.20.1: icmp_seq=33 ttl=255 time=0.286 ms

Donc apparemment le serveur est toujours vivant :smiley: Mais du coup je comprends encore moins x)

#17

Alors, cette adresse IP, 91.229.20.1 , est probablement celle de ta passerelle par défaut / ton routeur chez l’hébergeur.

Maintenant, on pourrait vérifier plus avant en effectuant un ping sur une autre adresse IP, qui ne réside probablement pas à proximité de la tienne. Comme l’IP actuelle pour www.orange.fr , 193.252.148.241 .

Et comme on peut aussi imaginer que cela vienne d’autre chose que du réseau, comme d’autres que moi l’ont dit plus haut, tu peux éventuellement utiliser dstat pour vérifier :

https://www.rootusers.com/my-top-3-linux-commands-for-logging-problems/

–
AnonymousCoward

#18

Bon… Les logs en locale fonctionne toujours (pas étonnant), mais je ping aussi les serveurs d’Orange… Donc la je comprends pas trop…

Pour dStat, tout m’a l’air en ordre, voilà le lien du CSV, j’ai utilisé ce site pour visualiser : http://lamada.eu/dstat-graph/# et je ne vois pas de chose anormal… Les torrents sont ajouté à 22H31, et j’ai reboot le serveur à 22H40. Entre temps bien sûr pas d’accès…
Donc là j’avoue que je sais pas x)

D’ailleurs si tu veux plus de graph, il y a munin sur mon serveur : https://munin.sperec.fr/

EDIT : Je me permets un petit UP, est-ce que quelqu’un aurais une idée ? Ou au moins une piste de recherche ?

#19

Bonsoir,

Tu as peut-être atteint une limite sur les connexions en Timewait ?

Après un redémarrage, il suffit d’aller voir ce qu’il en est (en ssh)

netstat -antu

Si le nombre de sockets en TIMEWAIT ne fait qu’augmenter à 1/2/3 mins d’intervalle , c’est un signe…

mais s’il te suffit d’avoir 10 mins de fonctionnement pour être bloqué, cela me parait vachement bizarre quand même