Contenu | Rechercher | Menus

Annonce

Si vous avez des soucis pour rester connecté, déconnectez-vous puis reconnectez-vous depuis ce lien en cochant la case
Me connecter automatiquement lors de mes prochaines visites.

À propos de l'équipe du forum.

nombre réponses : 25

#0 -1 »  [Résolu] Problème d'affichage avec une carte RX9 380 » Le 16/09/2023, à 12:52

phiibuntu
Réponses : 13

Bonjour à tous, j'ai le même problème, ou approchant avec une carte RX9 380.
L'écran noir arrive au moment du login.
quelques tests...j'ai forcé l'update en 23.04 (espérant qu'un upgrade de kernel arrangerait quoique ce soit on peut rêver smile )
lorsque je démarre en mode rescue et que je fait un resume j'ai bien l'environnement graphique qui fonctionne...
je pense que le problème provient de ça :
avec cette commande :

sudo lshw -c video

j'obtiens :

*-display NON-RÉCLAMÉ     
       description: VGA compatible controller
       produit: Tonga PRO [Radeon R9 285/380]
       fabricant: Advanced Micro Devices, Inc. [AMD/ATI]
       identifiant matériel: 0
       information bus: pci@0000:03:00.0
       version: f1
       bits: 64 bits
       horloge: 33MHz
       fonctionnalités: pm pciexpress msi vga_controller bus_master cap_list
       configuration : latency=0
       ressources : mémoire:e0000000-efffffff mémoire:f0000000-f01fffff portE/S:e000(taille=256) mémoire:fbe00000-fbe3ffff mémoire:c0000-dffff

non-réclamé ça me fait penser a un problème de driver...j'ai essayé d'install amdgpu sans succès rien ne semble empecher l'écran noir au démarrage...
si quelqu'un avait une idée je suis preneur. (j'ai essayé une fresh install en 23.04 et idem écran noir au démarrage, à force de bidouiller je me disais que le problème c'était moi ).


Modération

Afin d'éviter la confusion; merci de ne pas squatter la discussion d'un autre membre : deux problèmes d'apparence similaire peuvent avoir des causes différentes et nécessiter des solutions différentes.

#1 Re : -1 »  [Résolu] Problème d'affichage avec une carte RX9 380 » Le 16/09/2023, à 13:04

phiibuntu
Réponses : 13

ah cela pourra peut être aider  en tentant d'installer amdgpu :

Les paquets suivants contiennent des dépendances non satisfaites :
 libwayland-amdgpu-client0 : Dépend: libffi7 (>= 3.3~20180313) mais il n'est pas installable
 libwayland-amdgpu-client0:i386 : Dépend: libffi7:i386 (>= 3.3~20180313) mais il n'est pas installable
 libwayland-amdgpu-server0 : Dépend: libffi7 (>= 3.3~20180313) mais il n'est pas installable
 libwayland-amdgpu-server0:i386 : Dépend: libffi7:i386 (>= 3.3~20180313) mais il n'est pas installable
 xserver-xorg-amdgpu-video-amdgpu : Dépend: xorg-video-abi-24 mais il n'est pas installable
E: Impossible de corriger les problèmes, des paquets défectueux sont en mode « garder en l'état ».

#2 Re : -1 »  [Résolu] Problème d'affichage avec une carte RX9 380 » Le 16/09/2023, à 13:31

phiibuntu
Réponses : 13

première commande

Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances... Fait
Lecture des informations d'état... Fait      
Tous les paquets sont à jou

seconde :

||/ Nom                                                         Version                                             Architecture Description
+++-===========================================================-===================================================-============-================================================================================
rc  dctrl-tools                                                 2.24-3build2                                        amd64        Command-line tools to process Debian package information
rc  initscripts                                                 2.88dsf-59.3ubuntu2                                 amd64        scripts for initializing and shutting down the system
rc  libkf5idletime5:amd64                                       5.104.0-0ubuntu1                                    amd64        library to provide information about idle time
rc  libpython3.10-minimal:amd64                                 3.10.12-1~22.04.2                                   amd64        Minimal subset of the Python language (version 3.10)
rc  libsystemd-journal0:amd64                                   204-5ubuntu20.18                                    amd64        systemd journal utility library
rc  libsystemd-login0:amd64                                     204-5ubuntu20.18                                    amd64        systemd login utility library
rc  pipewire-media-session                                      0.4.1-2ubuntu1                                      amd64        example session manager for PipeWire
rc  plymouth-theme-ubuntu-logo                                  0.9.5+git20211018-1ubuntu3                          amd64        boot animation, logger and I/O multiplexer - ubuntu theme
rc  python3.10-minimal                                          3.10.12-1~22.04.2                                   amd64        Minimal subset of the Python language (version 3.10)
rc  resolvconf                                                  1.84ubuntu1                                         all          name server information handler
rc  ureadahead                                                  0.100.0-21                                          amd64        Read required files in advance

edit: je m'apercois quand dans le sources.list après l'update 22.04 vers 23.04 les repo sont tjrs pas sur lunar... je cherche dans cette direction du coup

#3 Re : -1 »  [Résolu] Problème d'affichage avec une carte RX9 380 » Le 16/09/2023, à 13:38

phiibuntu
Réponses : 13
moi@monpc:/etc/apt$ sudo apt update
Atteint :1 http://fr.archive.ubuntu.com/ubuntu jammy-updates InRelease
Atteint :2 http://download.virtualbox.org/virtualbox/debian focal InRelease                                                                                                                  
Atteint :3 http://fr.archive.ubuntu.com/ubuntu jammy-backports InRelease                                                                                                                     
Atteint :4 https://updates.signal.org/desktop/apt xenial InRelease                                                                                                                           
Atteint :5 https://ppa.launchpadcontent.net/cappelikan/ppa/ubuntu lunar InRelease                                                                                                            
Atteint :6 http://archive.ubuntu.com/ubuntu lunar InRelease                                                                                           
Atteint :7 http://security.ubuntu.com/ubuntu jammy-security InRelease                                               
Atteint :8 https://repo.radeon.com/amdgpu/23.20/amdgpu/ubuntu focal InRelease     
Atteint :9 https://repo.radeon.com/amdgpu/23.20/rocm/apt/5.7 focal InRelease
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances... Fait
Lecture des informations d'état... Fait      
Tous les paquets sont à jour.
moi@monpc:

#4 Re : -1 »  [Résolu] Problème d'affichage avec une carte RX9 380 » Le 16/09/2023, à 13:54

phiibuntu
Réponses : 13

réinstallation? j'ai tenter d'installer une 23.04 sur un autre disque dur pour tester ça n'a rien changé au problème.

#5 Re : -1 »  [Résolu] Problème d'affichage avec une carte RX9 380 » Le 16/09/2023, à 18:00

phiibuntu
Réponses : 13

pour les noyaux :

/etc/apt/sources.list.d$ echo; dpkg -l | awk '!/^rc/ && / linux-(c|g|h|i|lo|m|si|t)/{print $1,$2,$3,$4 | "sort -k3V | column -t"}' ; echo -e "\nNoyau courant : $(uname -mr)"

ii  linux-headers-3.13.0-24               3.13.0-24.47               all
ii  linux-headers-3.13.0-24-generic       3.13.0-24.47               amd64
ii  linux-headers-3.13.0-74               3.13.0-74.118              all
ii  linux-headers-3.13.0-74-generic       3.13.0-74.118              amd64
ii  linux-headers-3.13.0-76               3.13.0-76.120              all
ii  linux-headers-3.13.0-76-generic       3.13.0-76.120              amd64
ii  linux-headers-3.13.0-77               3.13.0-77.121              all
ii  linux-headers-3.13.0-77-generic       3.13.0-77.121              amd64
ii  linux-headers-3.13.0-79               3.13.0-79.123              all
ii  linux-headers-3.13.0-79-generic       3.13.0-79.123              amd64
ii  linux-headers-3.13.0-83               3.13.0-83.127              all
ii  linux-headers-3.13.0-83-generic       3.13.0-83.127              amd64
ii  linux-headers-4.4.0-57                4.4.0-57.78                all
ii  linux-headers-4.4.0-57-generic        4.4.0-57.78                amd64
ii  linux-headers-6.2.0-20                6.2.0-20.20                all
ii  linux-headers-6.2.0-20-generic        6.2.0-20.20                amd64
ii  linux-image-6.2.0-20-generic          6.2.0-20.20                amd64
ii  linux-modules-6.2.0-20-generic        6.2.0-20.20                amd64
ii  linux-modules-extra-6.2.0-20-generic  6.2.0-20.20                amd64
ii  linux-headers-6.2.0-32                6.2.0-32.32                all
ii  linux-headers-6.2.0-32-generic        6.2.0-32.32                amd64
ii  linux-image-6.2.0-32-generic          6.2.0-32.32                amd64
ii  linux-modules-6.2.0-32-generic        6.2.0-32.32                amd64
ii  linux-modules-extra-6.2.0-32-generic  6.2.0-32.32                amd64
ii  linux-headers-generic                 6.2.0.32.32                amd64
ii  linux-image-generic                   6.2.0.32.32                amd64
ii  linux-headers-6.5.3-060503            6.5.3-060503.202309130834  all
ii  linux-modules-6.5.3-060503-generic    6.5.3-060503.202309130834  amd64

c'est la que je vois que ce UBUNTU je l'ai depuis pas mal d'année smile

#6 Re : -1 »  [Résolu] Problème d'affichage avec une carte RX9 380 » Le 17/09/2023, à 13:30

phiibuntu
Réponses : 13

J'ai trouvé (ça fonctionne alors je vais dire que pour moi ça suffira smile )

j'ai supprimé amdgpu.
j'ai modifié le fichier /etc/default/grub
GRUB_CMDLINE_LINUX_DEFAULT="amdgpu.dc=0"
Important amdgpu.dc=0 doit etre seul, j'avais plusieurs commande dans cette ligne, en laissant uniquement celle la cela fonctionne. Ubuntu démarre désormais normalement et le driver par defaut gère bien ma carte et l'accélération graphique.
Je n'ai pas ouvert le post alors je ne mets pas résolu, mais pour moi c'est le cas. Merci pour les réponses (j'aurai fait du propre dans mon système). smile

#7 -1 »  postfix courier mysql problème de compréhension de ma part.... » Le 06/12/2020, à 14:19

phiibuntu
Réponses : 5

Bonjour à tous. je viens de paramétrer un serveur web avec une appli web qui doit envoyer des mails via postfix. Tout fonctionne. Non ne partez pas smile

j'ai un peu galéré mais postfix +courier fonctionne : l'appli web envoi c'est ok.  SI j'écris un mail depuis gmail sur une adresse du domaine ça fonctionne aussi...

Le mail arrive bien dans /var/mail/nomdedomaine/user/new

Alors me direz vous tout va pour le mieux smile et bien non. Si j'essaye de me loguer depuis Thunderbird par exemple login mot de passe ok mais "unable to acces this mailbox" (je suis pourtant en maildir je pense....imap etc.)
et pire!
la command "mail" me renvoie : no mail for "user"
alors que ceux ci sont bien arrivés dans le répertoire.

Comment désigner le répertoire où arrive mes mails comme correspondant au user linux en quelque sorte
Les mdp et login fonctionnent (j'ai vérifié dans /var/log/mail.log) quand je me connecte depuis thunderbird

.... bref tout semble parfait (le homedir dans /etc/postfix/main.cf pointe vers le bon répertoire également)...

bref je ne sais plus où chercher.

#8 Re : -1 »  postfix courier mysql problème de compréhension de ma part.... » Le 06/12/2020, à 19:45

phiibuntu
Réponses : 5

non j'ai installé courier. Ce n'est pas l'un ou l'autre?
EN fait c'est comme si mon user imap qui se connecte sur la base mysql qui gère les vmail ne parvenait pas à "voir" les répertoires sur le serveur.
dans le mail.log j'ai ça par exemple :
authdaemond: password matches successfully
Authenticated: sysusername=<null>, sysuserid=5000, sysgroupid=5000, homedir=/var/mail/, address="lebonmail", fullname="domain/user"/, maildir=/var/mail/, quota=0, options=<null>
(entre " les valeurs modifiées)
le sysusername vide c'est bizarre je trouve non?

edit : si ça peut aider dans /etc/courier/authmysqlrc j'ai mis ces deux valeurs :

MYSQL_HOME_FIELD        "/var/mail"
MYSQL_MAILDIR_FIELD       "/var/mail"


j'ai un peu tout essayé je vois plus trop comment faire ...

#9 Re : -1 »  postfix courier mysql problème de compréhension de ma part.... » Le 06/12/2020, à 21:41

phiibuntu
Réponses : 5

oui je confirme smile je vais écouter la voix de la sagesse smile et tenter dovecot
je me suis entêté vu que ça marchais "presque" lol
je reviendrais faire le point smile

#10 -1 »  Permissions modifiées » Le 09/03/2020, à 20:31

phiibuntu
Réponses : 4

Bonjour à tous, il m'arrive un truc étrange sur Ubuntu (jamais vu en déjà quelques années...)
Beaucoup de répertoires et fichiers de mon home (mais pas tous...) se sont retrouvés avec des permissions sur nobody nogroup
je n'ai passé aucune ligne de commande en ce sens, je n'ai rien installé aujourd'hui je m'en suis apercu car je ne pouvais plus upload de fichier sur navigateurs.

A votre avis puis je retrouver dans les logs ce qui s'est passé et si oui où?
D'avance merci smile

(j'avoue que la ...j'ai remis les droits sur mon user et tout est ok.)
On ne rigole pas svp smile smile je dois rater un truc je sais ça smile

#11 Re : -1 »  Permissions modifiées » Le 10/03/2020, à 11:55

phiibuntu
Réponses : 4

merci pour le retour. Malheureusement aucune commande n'a été passé apparemment avec la ligne de commande

sudo journalctl -g 'nobody|nogroup'

je n'obtiens que des informations de ce type :

smbd[11038]: pam_unix(samba:session): session closed for user nobody

C'est vraiment étrange ce changement de permission sans passer de ligne de commande je n'avais jamais vu ça.
je continue de chercher si je trouvais quelque chose j'ajouterai ici les éléments.

sudo journalctl -g 'nobody|nogroup'

me renvoie :

history | grep -E 'nobody|nogroup'
 1573  sudo journalctl -g 'nobody|nogroup'
 1575  sudo journalctl -g 'nobody|nogroup'
 1576  history | grep -E 'nobody|nogroup'

#12 Re : -1 »  Permissions modifiées » Le 10/03/2020, à 15:01

phiibuntu
Réponses : 4

ok je vais regarder ça, et ça suffisait à changer les permissions, limite je vais désinstaller samba smile
si c'est bon je mettrai en résolu

#13 Re : -1 »  [RESOLU] arrêt du service Apache Aléatoire sans erreur. » Le 30/09/2018, à 13:27

phiibuntu
Réponses : 41

ok alors déjà la ligne n'était pas commenté ( # remis)

et sudo logrotate -f -v /etc/logrotate.d/apache2 avec apache actif et fonctionnel n'a pas d'impact.

service apache2 status après la commande ci-dessus donne :

service apache2 status
● apache2.service - LSB: Apache2 web server
   Loaded: loaded (/etc/init.d/apache2; bad; vendor preset: enabled)
  Drop-In: /lib/systemd/system/apache2.service.d
           └─apache2-systemd.conf
   Active: active (running) since dim. 2018-09-30 12:40:17 CEST; 45min ago
     Docs: man:systemd-sysv-generator(8)
  Process: 19510 ExecStop=/etc/init.d/apache2 stop (code=exited, status=0/SUCCES
  Process: 20272 ExecReload=/etc/init.d/apache2 reload (code=exited, status=0/SU
  Process: 19575 ExecStart=/etc/init.d/apache2 start (code=exited, status=0/SUCC
    Tasks: 7
   Memory: 56.0M
      CPU: 2.977s
   CGroup: /system.slice/apache2.service
           ├─19592 /usr/sbin/apache2 -k start
           ├─19717 /usr/sbin/apache2 -k start
           ├─20291 /usr/sbin/apache2 -k start
           ├─20292 /usr/sbin/apache2 -k start
           ├─20293 /usr/sbin/apache2 -k start
           ├─20294 /usr/sbin/apache2 -k start
           └─20295 /usr/sbin/apache2 -k start

#14 Re : -1 »  [RESOLU] arrêt du service Apache Aléatoire sans erreur. » Le 30/09/2018, à 19:29

phiibuntu
Réponses : 41

alors cela me retourne :

/etc/apache2/sites-enabled/domain.org.conf: line 1: syntax error near unexpected token `newline'
/etc/apache2/sites-enabled/domaine.org.conf: line 1: `<VirtualHost www.domaine.org:443>'

#15 Re : -1 »  [RESOLU] arrêt du service Apache Aléatoire sans erreur. » Le 30/09/2018, à 20:05

phiibuntu
Réponses : 41

ok merci smile :

 sudo apache2ctl -M
Loaded Modules:
 core_module (static)
 so_module (static)
 watchdog_module (static)
 http_module (static)
 log_config_module (static)
 logio_module (static)
 version_module (static)
 unixd_module (static)
 access_compat_module (shared)
 alias_module (shared)
 auth_basic_module (shared)
 authn_core_module (shared)
 authn_file_module (shared)
 authz_core_module (shared)
 authz_host_module (shared)
 authz_user_module (shared)
 autoindex_module (shared)
 deflate_module (shared)
 dir_module (shared)
 env_module (shared)
 filter_module (shared)
 mime_module (shared)
 mpm_prefork_module (shared)
 negotiation_module (shared)
 php7_module (shared)
 setenvif_module (shared)
 socache_shmcb_module (shared)
 ssl_module (shared)
 status_module (shared)

#16 Re : -1 »  [RESOLU] arrêt du service Apache Aléatoire sans erreur. » Le 01/10/2018, à 09:49

phiibuntu
Réponses : 41

bon alors cette nuit le serveur apache n'est pas tombé.
je vais surveiller encore un peu avant de mettre un résolu.

J'avoue que je suis surpris (j'héberge juste un blog basique wordpress avec un "audimat" de 5-6 lecteurs lol
donc très peu utilisé je n'aurai jamais pensé à augmenter les valeurs du mod prefork...

Je vous tiens au courant, quoi qu'il en soit merci vraiment pour le coup de main j'ai appris plein de trucs smile
Je mettrai un "résolu" demain (si ça tient deux jours je pense que ça devrait être bon signe).

#17 Re : -1 »  [RESOLU] arrêt du service Apache Aléatoire sans erreur. » Le 02/10/2018, à 15:07

phiibuntu
Réponses : 41

merci pour ces infos, je vais tester car ce matin 6h25 le site est tombé encore sans raison (enfin pas que je comprenne)...

bon j'ai rigoureusement la même chose avec la commande "cat /etc/crontab"
et il semblerait que ça plante à 6h25....
du coup j'imagine que c'est le cron.daily qui pose problème le voici pour apache2 :

#!/bin/sh

# run htcacheclean

set -e
set -u

type htcacheclean > /dev/null 2>&1 || exit 0
[ -e /etc/default/apache2 ]   || exit 0


# edit /etc/default/apache2 to change this
HTCACHECLEAN_MODE=daemon
HTCACHECLEAN_RUN=auto
HTCACHECLEAN_SIZE=300M
HTCACHECLEAN_PATH=/var/cache/apache2/mod_cache_disk
HTCACHECLEAN_OPTIONS=""

. /etc/default/apache2

[ "$HTCACHECLEAN_MODE" = "cron" ] || exit 0

[ "$HTCACHECLEAN_RUN" = "yes"	] || 
( [ "$HTCACHECLEAN_RUN" = "auto" ] && \
  [ -e /etc/apache2/mods-enabled/cache_disk.load ] )  || exit 0

htcacheclean ${HTCACHECLEAN_OPTIONS}	\
		-p${HTCACHECLEAN_PATH}	\
		-l${HTCACHECLEAN_SIZE}

et retour de la première commande :

 apache2ctl fullstatus
               Apache Server Status for localhost (via 127.0.0.1)

   Server Version: Apache/2.4.18 (Ubuntu) OpenSSL/1.0.2g
   Server MPM: prefork
   Server Built: 2018-06-07T19:43:03
     __________________________________________________________________

   Current Time: Tuesday, 02-Oct-2018 15:13:34 CEST
   Restart Time: Tuesday, 02-Oct-2018 15:13:24 CEST
   Parent Server Config. Generation: 1
   Parent Server MPM Generation: 0
   Server uptime: 10 seconds
   Server load: 0.00 0.00 0.00
   Total accesses: 0 - Total Traffic: 0 kB
   CPU Usage: u0 s0 cu0 cs0
   0 requests/sec - 0 B/second -
   1 requests currently being processed, 9 idle workers

W_________......................................................
................................................................
................................................................
................................................................

   Scoreboard Key:
   "_" Waiting for Connection, "S" Starting up, "R" Reading Request,
   "W" Sending Reply, "K" Keepalive (read), "D" DNS Lookup,
   "C" Closing connection, "L" Logging, "G" Gracefully finishing,
   "I" Idle cleanup of worker, "." Open slot with no current process

   Srv PID Acc M CPU SS Req Conn Child Slot Client VHost Request
   0-0 25641 0/0/0 W 0.00 0 0 0.0 0.00 0.00 127.0.0.1 vpsxxxxxx.ovh.net:80
   GET /server-status HTTP/1.0
     __________________________________________________________________

    Srv  Child Server number - generation
    PID  OS process ID
    Acc  Number of accesses this connection / this child / this slot
     M   Mode of operation
    CPU  CPU usage, number of seconds
    SS   Seconds since beginning of most recent request
    Req  Milliseconds required to process most recent request
   Conn  Kilobytes transferred this connection
   Child Megabytes transferred this child
   Slot  Total megabytes transferred this slot
     __________________________________________________________________

   SSL/TLS Session Cache Status:
   cache type: SHMCB, shared memory: 512000 bytes, current entries: 0
   subcaches: 32, indexes per subcache: 88
   index usage: 0%, cache usage: 0%
   total entries stored since starting: 0
   total entries replaced since starting: 0
   total entries expired since starting: 0
   total (pre-expiry) entries scrolled out of the cache: 0
   total retrieves since starting: 0 hit, 0 miss
   total removes since starting: 0 hit, 0 miss
     __________________________________________________________________


    Apache/2.4.18 (Ubuntu) Server at localhost Port 80

#18 Re : -1 »  [RESOLU] arrêt du service Apache Aléatoire sans erreur. » Le 02/10/2018, à 15:27

phiibuntu
Réponses : 41

j'ai regardé aussi sur le wordpress un plugin de sécurité qui scanne le blog pour éviter les problèmes, celui-ci "shedule" quand il veut j'ai laissé la sécurité active mais j'ai désactivé le scan aléatoire du site (je le ferai à la main)
pour tester si c'et pas lui qui me pose problème.

J'essaye d'éliminer par déduction toutes les tâches automatique de mon serveur, j'aimerai vraiment bien trouver le pourquoi du comment! grrr

#19 Re : -1 »  [RESOLU] arrêt du service Apache Aléatoire sans erreur. » Le 02/10/2018, à 19:38

phiibuntu
Réponses : 41

ok je vais creuser par là, mais le site est déjà tombé, apache est down bien avant 6h25...
je vais désactiver certains plugins wordpress ...peut être une mise à jour qui à posé problème car côté ubuntu j'ai l'impression d'avoir fait le tour ...:(

#20 Re : -1 »  [RESOLU] arrêt du service Apache Aléatoire sans erreur. » Le 04/10/2018, à 11:15

phiibuntu
Réponses : 41

j'ai désactivé toutes les tach planifié cron.daily etc.
j'ai désactivé lesp lugins avec taches planifié dans wordpress.

et ça plante toujours. Là j'avoue que je patauge complet smile incompréhensible!
les ressources n'explosent pas.

Après dans fail2ban les attaques sur le ssh sont bien flippantes pour un serveur qui contient rien sad
j'ai à peu pres 600 ip bannis...

Bref c'est des attaques peut être mais je devrait saturer les ressources mémoires et cpu avant que le serveur Apache tombe, et c'est pas le cas.

Un truc tout bête (vraiment bête attention) un serveur apache n'a pas de time out pour inactivité normalement?
(c'est idiot car vu mon blog peu lu, j'aurai eu le problème depuis bien longtemps...).

Bon merci en tout cas pour tous les coups de mains, si ça continue je vais carrément réinstallé mon vps ovh!

#21 Re : -1 »  [RESOLU] arrêt du service Apache Aléatoire sans erreur. » Le 04/10/2018, à 11:26

phiibuntu
Réponses : 41

je sais pas si ça peut aider... mais un truc assez dingue arrive: )
après les mise à jour de sécurité il fallait redemarrer le vps, je reboot, et la je m'aperçois que le serveur Apache démarre puis s'éteint au démarrage du serveur.
donc aucune raison pour ça rien dans le log d'erreur, juste il s'arrête apres avoir démarré sans erreur...

Y a un fantome dans mon serveur OVH? lol

#22 Re : -1 »  [RESOLU] arrêt du service Apache Aléatoire sans erreur. » Le 09/10/2018, à 09:33

phiibuntu
Réponses : 41

Bonjour, évidemment ça a continué à planté une à deux fois par jour.
Et depuis hier ça à l'air de tenir.
En fait après de longues recherches sur tous les forums possible j'ai trouvé une piste...aussi étonnant que cela puisse paraître j'ai sans doute merdouillé (et oui je me doutais bien d'ou venait l'erreur mais la trouver hum une autre paire de manche)
sur mon dernier renouvellement certbot (mal réalisé manuellement je pense).
J'ai tout refait hier en tout début d'après midi, j'ai rajouté le cron certbot renew et je n'ai plus de vautrage depuis. Je mettrai un résolu demain (je croise tous ce que je peux) si ça tiens.
En tout cas si ça peut aider un jour je le note ici donc...

Encore merci à tous pour le coup de main!

#23 Re : -1 »  [RESOLU] arrêt du service Apache Aléatoire sans erreur. » Le 09/10/2018, à 09:59

phiibuntu
Réponses : 41

et bien c’était peut être ça mon problème (mais toute les heures ca aurait planté encore plus) en tout cas le serveur tient encore et c'est la plus grande durée depuis le renew
d'ailleurs maintenant que j'y pense le problème est apparu  à peu prêt à ce moment là mais j'avais pas forcément fait le rapprochement).

#24 Re : -1 »  [RESOLU] arrêt du service Apache Aléatoire sans erreur. » Le 10/10/2018, à 10:17

phiibuntu
Réponses : 41

je mets donc un résolu, en ayant compris 40 du problème smile

Merci à tous comme d'hab heureux d'avoir posté sur ce forum, faut dire qu'en général je trouve la solution en cherchant un peu donc je poste peu lol!

En résumé problème lors du renouvellement du certificat certbot letsencrypt.

Solution, renouveler le certificat à la main, et refaire les commande ci dessous pour s'assurer que le cron certbot est bien en place!
je mets les commandes (histoire de me rendre utile si jamais ma petite aventure pouvait dépanner quelqu'un un de ces quatre...

sudo certbot renew --dry-run
sudo crontab -e

saisir ça dans le cron :

59 * * * * sudo certbot renew

redémarrer le service apache.

Je n'avais aucune erreur dans aucun log juste apache qui se fermait...avouez c'était bizarre même pour un amateur comme moi !