suppression d'un fichier impossible bien que root

[yahnice]

Bonjour à Tous.

J'ai un serveur en Redhat 8 et RAID 5 sur 4 disques. J'ai eu récemment un disque qui a laché j'ai du reconstruire le RAID sur 3 disques, je n'ai pas encore pu changer le disque mort.
Depuis j'ai l'impression que mon serveur a quelques souci d'écriture.

Mais mon problème est le suivant, le fichier /var/run/crond.pid a des droits bizarre : ?--s--Sr-x
un propriétaire et un groupe non moins bizarre : 2849005888 1446148123 et une taille des plus délirante : 2038577425 octets.

Bien qu'étant connecté root sur la machine je ne peux rien faire avec ce fichier :
rm - cat - tail - head - chmod - chown - touch - mv - chattr -lsattr ... rien à faire
et le pire c'est que mon crond ne veut plus ce lancer à cause de ça.

Y a-t-il un moyen de forcer la suppression d'un fichier de ce genre ?

Surtout que ce n'est pas le seul fichier dans ce cas mais celui-là est le plus bloquant.

Merci.

[Jacques-]

Vu le répertoire, il n'y a pas grand chose de bloquant dedans, tu peux essayer de le renommer et d'en créer un nouveau contenant les pid de tes applis en cours. En redémarrant crond, il devrait pouvoir recréer son fichier dans le nouveau répertoire.
Mais visiblement ta table d'inodes doit avoir quelques soucis pour posséder des caractéristiques de ce genre.

Jacques

[yahnice]

Bonjour Jacques

C'est ce que j'ai fait vu que cron est assez vital pour un serveur.
J'ai renommé le répertoire /var/run, recopié de l'ancien ce qui était correct et tout est rentré dans l'ordre mais bon j'ai toujours ce fichier impossible a supprimer comme quelques autres d'ailleurs.

N'y a-t-il aucun moyen de supprimer ces fichiers ?

Yahnice

[Jacques-]

Pour corriger un problème de FS, je ne vois guère que fsck, mais le faire sur une machine en prod avec le FS monté, c'est risqué. Tu peux essayer de voir ce que cela ferait en mode interactif sans valider, mais je préfèrerais arrêter le système pour ça personnellement.
Autrement, créer un utilisateur bido ayant le même id et gid qu'indiqué par le ls pour tenter de modifier le fichier, mais c'est plutôt étrange que root se voit refuser l'accès en effacement. Vérifie les propriétés du ou des répertoires concernés dans l'arborescence au cas où. Un cat de /dev/null > LeFichier réduirait déjà sa taille, mais rien que les droits posent problème.
Et maintenant que le répertoire est recopié, un rm -rf de celui-ci ne marcherait pas ?

Jacques

[yahnice]

Alors : cat /dev/null > crond.pid ne marche pas plus que " > crond.pid" ou quelque autre commande de modification du fichier que j'avais déjà essayé ...

La commande rm -rf ne marche pas non plus. Voici le message : "rm: cannot chdir from `run_old//.' to `crond.pid': Not a directory"

La machine étant une machine de prod un fsck va être plutôt difficile à caser en plus vu que mon RAID 5 sur 4 disques tourne pour l'instant sur 3 disques j'attendrai en plus que le RAID soit correctement constitué.

J'ai créé un user toto avec comme uid celui du fichier et les commandes rm ou chmod donnent les même refus que lorsque je les fais sous root.

Donc pour l'instant status quo.

Yahnice

[Jacques-]

C'est ce qu'il y a de plus raisonnable à faire en effet. Wait and see, jusqu'à ce qu'une maintenance puisse être planifiée avec arrêt.
Bonnes fêtes de fin d'année

Jacques

[yahnice]

oui.

Merci pour ton aide et tes avis

Yahnice

[foobar47]

Salut,

et en modifiant le script de cron, en spécifiant un autre fichier PID ?

genre

start() {
echo -n $"Starting $prog: "
if [ -e /var/lock/subsys/crond ]; then
if [ -e /var/run/new_cron.pid ] && [ -e /proc/`cat /var/run/new_cron.pid` ]; then
echo -n $"cannot start crond: crond is already running.";
failure $"cannot start crond: crond already running.";
echo
return 1
fi
fi
daemon crond $CRONDARGS
RETVAL=$?
echo
[ $RETVAL -eq 0 ] && touch /var/lock/subsys/crond;
return $RETVAL
}

[yahnice]

Oui mai le problème n'es pas de démarrer crond, c'est déjà ok j'ai renommé le répertoire contenant crond.pid puis recréé et crond a démarré correctement en recréeant son fichier.