[up] Comment déplacer /var/log

[Kronick]

Bonjour,
sur un serveur en production, le /tmp est sur la première partition qui est pleine.
Ma question est simple, puis-je créer un dossier dans le /home, tmp
éditer le fstab pour un truc du genre
[cpp]
/home/tmp /tmp bind 0 0 0
[/cpp]

ensuite un mount /tmp.
J'imagine que je dois copier avant tout ce qui se trouve dans /tmp vers /home/tmp

Enfin, comment faire pour les autres dossiers qui se trouvent dans / (je pense aux dossiers cruciaux type /usr /var, etc..)
merki

[Zedoune]

Salut

Je pense que si tu remontes /home/tmp par dessus /tmp sans redémarrer, tu vas avoir des problèmes. Les fichiers utilisés dans /tmp le seront encore après le montage, il faudrait donc relancer les différents services pour qu'ils se mettent à utiliser le nouveau /tmp

A chaud comme ça je sais pas :/

[Kronick]

bon résolu :
j'ai pu passer de 100% à 53% :

suppression des logs archivés
déplacement de mes backup sur une autre partition
apt-get clean
vidage du fichier des mails envoyés .sent
vidage du /tmp
vidage du fichiers d'accès Apache

et rulez
comme c'est sur un serveur en production, pas trop de reboot et manip risquées possibles

[nicodache]

fstab ne prend en compter que des devices physiques (ou associés, genre lvm, md) et des partitions.

ce que tu peux faire par contre, c'est un lien de /tmp vers /home/tmp, par exemple.
sinon, encore mieux, un petit script qui recherche les fichiers dont l'atime est plus ancien que 15 jours (les fichiers qui n'ont plus été accédés depuis 15 jours) ou dont le mtime (date de dernière modification) est aussi assez vieux.
en effaçant comme ca (et en virant les répertoires vides), tu libéreras pas mal de place si c'est un serveur qui ne redémarre pas souvent

suppression des logs archivés
déplacement de mes backup sur une autre partition
apt-get clean
vidage du fichier des mails envoyés .sent
vidage du /tmp
vidage du fichiers d'accès Apache

mmmh.
tu confonds pas /tmp et /var/tmp ?

[Kronick]

non je ne pense pas ?
j'avais deux trois fichier qui trainaient sur le /tmp mais c'était rien de bien gros

[nicodache]

bein pourquoi tu causes de /tmp dans ton premier post si c'est /var/tmp qui est plein ?

[Kronick]

parce que je me suis trompé
en fait c'était pas que le /var/tmp, yen avait un peu partout [:kronick:6]

[Kronick]

up !
toujours dans cette optique de déplacement
peut-on déplacer le dossier /var/log ?

j'ai pensé à ça :

Code : Tout sélectionner

$mkdir /home/log
$rsync -a /var/log /home/log
$mount --bind /home/log /var/log
$/etc/init.d/rsyslog restart

c'est jouable à chaud, sans redémarrer le serveur ?

[Zedoune]

ça peut marcher, mais le problème c'est que si une application utilise un fichier dans /var/log et que tu fais ta commande, il continuera d'utiliser l'ancien dossier qui sera pour toi invisible (puisque tu as remonté /home/log dessus), donc faut bien faire gaffe que tous les serveurs soient coupés.

Ce n'est qu'une supposition, mais c'est comme ça que ça doit fonctionner normalement, comme les descripteurs de fichiers sont ouverts, même si tu changes le dossier il continuera d'utiliser le même fichier qu'avant, même si sont emplacement n'est même plus visible en ligne de commande, il tape directement dans le numéro d'inode donc il se fou pas mal des dossiers

[Kronick]

ah oui j'avais oublié les descripteurs de fichiers.
ça veut dire relancer au moins :
open-ssh
apache
mysql
zabbix
postfix
mailman
etc...

galère...

[Zedoune]

tu peux vraiment pas rebooter ? Parce que là ça va vraiment être la galère ...

Ou tu te mets en init 1, tu fais le montage et tu retournes en init 3 ou 4 je sais pas dans lequel est ton serveur, mais normalement en 1 ça va arrêter tous les serveurs (single user mode), et 3 ou 4 c'est multi-users donc les serveurs sont relancés.

Ca marcherait sur une slackware, pour une debian ou une red hat faut voir si l'init ça marche pareil

[Kronick]

je viens de poser la question sur un autre site
(serverfault.com )
voici la réponse :

I assume you are unable to simply extend the filesystem in question (using lvextend && ext2online), because you do not use LVM or use wrong filesystem type.

First of all, I would suggest to forget about "mount -o bind" idea, create a new LV/partition and mount it properly over either /var or /var/log.

The easy way is to take down the server to maintenance mode (single-user mode), and use the actual console (not ssh) for the operation.

What you've proposed might work if you signal the daemons with SIGHUP (kill -1 pid). Obviously you would need to later on "mount -o bind / /somewhere" and clean up what has been left underneath mounted /var/log. But it has a bad smell for me, especially for production.

If you want to do it hard way, but without downtime:

lsof | grep /var/log # lists open files in /var/log
For each daemon that has any open file (I would expect at least syslog, inetd, sshd):

reconfigure daemon no to log to /var/log
refresh the daemon (kill -1 or /etc/init.d/script reload)
confirm with lsof | grep /var/log that daemon has closed his files
Mount over /var/log. Restore old configurations, SIGHUP/reload daemons again.

[sumfvm]

Pourquoi ne pas déplacer ton /tmp dans /home/tmp et faire un lien symbolique entre les deux ?

[Zedoune]

Ca ne change rien au problème de le faire sans rebooter non ? Que ce soit un mount --bind ou un lien symbolique ça revient pas au même ? (à part quelques détails techniques ça ne change rien)

[Kronick]

oui tout le problème est là
est-ce qu'à chaud le déplacement est dangereux et fonctionnel ?

que pensez vous d'un :

Code : Tout sélectionner

$/etc/init.d/ksyslog stop
$mv /var/log/ /var/log.old
$ln -s /var/log /home/log
$/etc/init.d/ksyslog start

?

[Zedoune]

le ln -s est à l'envers si je me trompe pas, il faudrait faire

Code : Tout sélectionner

ln -s /home/log /var/log

et avec ce que tu fais, ça va juste remettre le log de ksyslog dans le nouveau répertoire, mais tout ce qui log (apache, mysql, ssh ou je ne sais quoi, ça va continuer à le faire dans le même repertoire qu'avant)

[Kronick]

ok ok
donc le plus jouable serait la proposition de la personne à savoir : voir quels sont les process qui utilisent le dossier à l'instant T et killer chaque process pour le relancer ensuite.

OU ALORS
mettre en place un script de nettoyage pour cleaner tous les jours par exemple. Ca me semble être le moins risqué

Enfin, si j'ai l'occasion de passer ce serveur en maintenance je peux faire quoi (kimsufi ovh) ?
je peux rebooter en single user ? avec le level qui va bien .?
du coup quelle solution selon vous serait la plus propre pour mapper /var/log/ ailleur ?

[Zedoune]

faire une autre partition dédiée pour /var/log ou alors faire un mount --bind

Une fois que t'as choisis entre les deux, tu ajoutes l'entrée au fstab ce qui va bien et tu reboot, comme ça les logs iront au bon endroit au démarrage.

Après faut nettoyer le répertoire /var/log de la partition système, pour ça tu remontes ta partition système sur un dossier quelquonque et tu retournes dans var/log pour effacer le contenu (qui ne sert plus vu qu'il est remplacé par un nouveau hemin)

[Kronick]

oki merci
comment je peux effacer le /var/log si un point de montage est dessus ?

[Zedoune]

pour effacer var/log alors qu'il est monté, faut monter ailleurs la partition où il se trouve, et tu le retrouveras là dedans

par exemple, si /var/log est sur ta partition système / qui est le disque /dev/sda

tu fais un truc genre:
mkdir /media/temp
mount.ext3 /dev/sda /media/temp

normalement dans /media/temp/var/ tu retrouves ton dossier log, vérifies le contenu et efface le

et puis cd && umount /media/temp && rm -fr /media/temp