[LINUX][init.d]spamassasin ne se lance plus après un update

Salut,

J’utilise un serveur dédié chez OVH, qui tourne sur une distrib gentoo modifiée par OVH.

J’ai essayé de mettre jour spamassassin, et j’ai du bidouiller un peu pour l’installer (le make install remplaçait tous les fichiers, sauf celui sous /usr/sbin qui était justement celui lancé par le script dans init.d, et que j’ai remplacé à la main.) Bref, le serveur spamd se lance désormais en ligne de commande, mais plus avec le script sous init.d…

un petit /etc/init.d/spamd start prétend que spamd est lancé, mais rien du coté des processus.

Bref, mon problème est surtout que je ne comprends pas comment fonctionnent ces scripts dans init.d, et je ne sais pas comment faire pour avoir une trace qui me permettrait de savoir ce qui se passe et pourquoi spamd ne se lance pas… Un bon tuto serait le bienvenu, j’ai du mal à en trouver sur google…

Merci

T’aurais pas un PID file qui est resté, dans /var/run/ ?

Bon, d’après ce que j’ai compris, les scripts n’ont rien de spécial, c’est juste que spamassassin n’est pas lancé directement, mais via start-stop-daemon ( http://www.annodex.net/cgi-bin/man/man2htm…t-stop-daemon+8 ) , et celui ci ne me renvoie pas de messages d’erreur, alors qu’un ./var/lib/init.d/started/spamd est créé…

Non, il manque justement ce fichier pid quand j’essaie /etc/init.d/spamd stop (ce qui semble normal, vu qu’il n’arrive pas à lancer spamd), par contre il crée un fichier ./var/lib/init.d/started/spamd…

bon, mon fichier /etc/conf.d/spamd contient:

SPAMD_OPTS="-m 5 -H -u qscand -v -x --siteconfigpath=/etc/spamassassin/local.cf" PIDFILE="/var/run/spamd/spamd.pid"

/etc/spamassassin/local.cf existe et est lisible par tous les utilisateurs

Le script /etc/init.d/spamd contient:

[code]# Provide a default location if they haven’t in /etc/conf.d/spamd
PIDFILE=${PIDFILE:-/var/run/spamd.pid}

depend() {
need net
before mta
use logger
}

start() {
ebegin "Starting spamd"
start-stop-daemon --start
–exec /usr/sbin/spamd – -d -r ${PIDFILE}
${SPAMD_OPTS}
eend $? “Failed to start spamd”
}

stop() {
ebegin "Stopping spamd"
start-stop-daemon --stop --pidfile ${PIDFILE}
eend $? “Failed to stop spamd”
}[/code]

J’ai créé /var/run/spamd/ qui curieusement n’existait plus, je l’ai attribué à l’utilisateur qscand.
Au cas ou j’ai créé /var/run/spamd/spamd.pid, attribué aussi à qscand avec les droits qu’il faut…
mais toujours rien…

edit: ah oui, et /usr/sbin/spamd est executable par tous les utilisateurs…

Et tu n’avais pas d’indication dans /var/log/messages?

non, que dalle… Il se comporte vraiment comme s’il avait réussi à le lancer. Il n’y écrit quelque chose que lorsqu’il croit qu’il est déja lancé:

Jun 12 20:35:53 ns23188 rc-scripts: WARNING: “spamd” has already been started.

Il y a un autre fichier succeptible de contenir des traces?

[quote=“gring, post:7, topic: 45215”]non, que dalle… Il se comporte vraiment comme s’il avait réussi à le lancer. Il n’y écrit quelque chose que lorsqu’il croit qu’il est déja lancé:

Jun 12 20:35:53 ns23188 rc-scripts: WARNING: “spamd” has already been started.

Il y a un autre fichier succeptible de contenir des traces?[/quote]

Essaye de lancer ton daemon à la main :

$ cd /la où il est planqué
$ ./spamd -D
(d’après http://www.die.net/doc/linux/man/man1/spamd.1.html ça active le débug, au pire vérifie)

Si jamais il forke vérifie qu’il n’est pas mort avec
$ ps

[quote=“JDaM, post:8, topic: 45215”]Essaye de lancer ton daemon à la main :

$ cd /la où il est planqué
$ ./spamd -D
(d’après http://www.die.net/doc/linux/man/man1/spamd.1.html ça active le débug, au pire vérifie)

Si jamais il forke vérifie qu’il n’est pas mort avec
$ ps[/quote]

A la main, il se lance et il fonctionne. C’est le script dans init.d qui ne veut pas marcher, et qui ne laisse pas de traces…

Rajoute l’option -v à start-stop-daemon et redirige le flux vers un fichier

start() { ebegin "Starting spamd" start-stop-daemon -v --start \ --exec /usr/sbin/spamd -- -d -r ${PIDFILE} \ ${SPAMD_OPTS} 2> /tmp/ssd.log 1> /tmp/ssd.log eend $? "Failed to start spamd" }

Histoire de voir si ssd râle.

Sinon PIDFILE=${PIDFILE:-/var/run/spamd.pid} me parait étrange vu que le pidfile est dans /var/run/spamd/ (pas /var/run/).

Ah on me fait signe que c’est normal et que le devrait potasser man bash(1).

argh, /tmp/ssd.log reste désespérément vide…

maintenant, il me sort le commentaire suivant lorsque je tente le start:

  • Re-caching dependency info (mtimes differ)…

  • Could not get dependency info for “spamd”!

  • Please run:

  • /sbin/depscan.sh

  • to try and fix this.

c’est probablement dû à mes bidouilles précédentes.