#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 )
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
#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 )
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).
#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
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 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 je vais écouter la voix de la sagesse et tenter dovecot
je me suis entêté vu que ça marchais "presque" lol
je reviendrais faire le point
#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
(j'avoue que la ...j'ai remis les droits sur mon user et tout est ok.)
On ne rigole pas svp je dois rater un truc je sais ça
#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
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 :
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
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 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
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
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 !