Un poste bosse sur un fichier, il plante, laisse le fichier ouvert, et
ensuite ceux qui veulent l'ouvrir se prennent un erreur -54.
Evidemment en redémarrant le serveur les choses rentrent dans l'ordre.
Classique.
Comment je peux refermer le fichier sans redémarrer ?
Merci :-)
--
Nina
Un poste bosse sur un fichier, il plante, laisse le fichier ouvert, et ensuite ceux qui veulent l'ouvrir se prennent un erreur -54. Evidemment en redémarrant le serveur les choses rentrent dans l'ordre. Classique. Comment je peux refermer le fichier sans redémarrer ? Merci :-)
en AFP j'imagine... aucune idée. Normalement on tue le process qui maintient le fichier ouvert, mais dans le cas présent le process (client) est déjà mort, et le lock doit être dans le serveur.
désolé, j'ai pas de piste.
patpro
-- http://www.patpro.net/
In article <mcq2439ntboqddg5cpk5inu2r2ntij91jo@4ax.com>,
Nina Popravka <Nina@nospam.invalid> wrote:
Un poste bosse sur un fichier, il plante, laisse le fichier ouvert, et
ensuite ceux qui veulent l'ouvrir se prennent un erreur -54.
Evidemment en redémarrant le serveur les choses rentrent dans l'ordre.
Classique.
Comment je peux refermer le fichier sans redémarrer ?
Merci :-)
en AFP j'imagine... aucune idée. Normalement on tue le process qui
maintient le fichier ouvert, mais dans le cas présent le process
(client) est déjà mort, et le lock doit être dans le serveur.
Un poste bosse sur un fichier, il plante, laisse le fichier ouvert, et ensuite ceux qui veulent l'ouvrir se prennent un erreur -54. Evidemment en redémarrant le serveur les choses rentrent dans l'ordre. Classique. Comment je peux refermer le fichier sans redémarrer ? Merci :-)
en AFP j'imagine... aucune idée. Normalement on tue le process qui maintient le fichier ouvert, mais dans le cas présent le process (client) est déjà mort, et le lock doit être dans le serveur.
désolé, j'ai pas de piste.
patpro
-- http://www.patpro.net/
Nina Popravka
On Wed, 09 May 2007 08:42:22 +0200, patpro ~ Patrick Proniewski wrote:
et le lock doit être dans le serveur. Manifestement.
Ce qui est logique ; si on lui dit pas que le fichier a été refermé, il va pas le deviner...
désolé, j'ai pas de piste. Ouinnnnnnn :-(
Remarque, ASIP ne savait pas le faire non plus (à moins que Laurent n'infirme) ;-> -- Nina
On Wed, 09 May 2007 08:42:22 +0200, patpro ~ Patrick Proniewski
<patpro@boleskine.patpro.net> wrote:
et le lock doit être dans le serveur.
Manifestement.
Ce qui est logique ; si on lui dit pas que le fichier a été refermé,
il va pas le deviner...
désolé, j'ai pas de piste.
Ouinnnnnnn :-(
Remarque, ASIP ne savait pas le faire non plus (à moins que Laurent
n'infirme) ;->
--
Nina
On Wed, 09 May 2007 08:42:22 +0200, patpro ~ Patrick Proniewski wrote:
et le lock doit être dans le serveur. Manifestement.
Ce qui est logique ; si on lui dit pas que le fichier a été refermé, il va pas le deviner...
désolé, j'ai pas de piste. Ouinnnnnnn :-(
Remarque, ASIP ne savait pas le faire non plus (à moins que Laurent n'infirme) ;-> -- Nina
laurent.pertois
Nina Popravka wrote:
Comment je peux refermer le fichier sans redémarrer ?
Tu as essayé de relancer le service ?
Sinon, lsof avec un grep sur le nom du fichier pourrait te donner le nom du processus qui le verrouille, je pense.
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
Nina Popravka <Nina@nospam.invalid> wrote:
Comment je peux refermer le fichier sans redémarrer ?
Tu as essayé de relancer le service ?
Sinon, lsof avec un grep sur le nom du fichier pourrait te donner le nom
du processus qui le verrouille, je pense.
--
Politically Correct Unix - UTILITIES
The "touch" command has been removed from the standard distribution due
to its inappropriate use by high-level managers.
Comment je peux refermer le fichier sans redémarrer ?
Tu as essayé de relancer le service ?
Sinon, lsof avec un grep sur le nom du fichier pourrait te donner le nom du processus qui le verrouille, je pense.
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
Nina Popravka
On Wed, 9 May 2007 10:05:10 +0200, (Laurent Pertois) wrote:
Tu as essayé de relancer le service ? L'équivalent du service serveur, tu veux dire ? Ben non, parce que je
voudrais n'agir que sur le fichier problématique sans déconnecter tout le monde...
Sinon, lsof avec un grep sur le nom du fichier pourrait te donner le nom du processus qui le verrouille, je pense. Sûrement, mais grep ==> regexp, et Nina totalement incompatible avec
regexp. -- Nina
On Wed, 9 May 2007 10:05:10 +0200, laurent.pertois@alussinan.org
(Laurent Pertois) wrote:
Tu as essayé de relancer le service ?
L'équivalent du service serveur, tu veux dire ? Ben non, parce que je
voudrais n'agir que sur le fichier problématique sans déconnecter tout
le monde...
Sinon, lsof avec un grep sur le nom du fichier pourrait te donner le nom
du processus qui le verrouille, je pense.
Sûrement, mais grep ==> regexp, et Nina totalement incompatible avec
On Wed, 9 May 2007 10:05:10 +0200, (Laurent Pertois) wrote:
Tu as essayé de relancer le service ? L'équivalent du service serveur, tu veux dire ? Ben non, parce que je
voudrais n'agir que sur le fichier problématique sans déconnecter tout le monde...
Sinon, lsof avec un grep sur le nom du fichier pourrait te donner le nom du processus qui le verrouille, je pense. Sûrement, mais grep ==> regexp, et Nina totalement incompatible avec
regexp. -- Nina
laurent.pertois
Nina Popravka wrote:
Remarque, ASIP ne savait pas le faire non plus (à moins que Laurent n'infirme) ;->
Nan, je confirme, comme tu le dis, s'il ne sait qu'il a été refermé il ne va pas deviner seul :-D
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
Nina Popravka <Nina@nospam.invalid> wrote:
Remarque, ASIP ne savait pas le faire non plus (à moins que Laurent
n'infirme) ;->
Nan, je confirme, comme tu le dis, s'il ne sait qu'il a été refermé il
ne va pas deviner seul :-D
--
Politically Correct Unix - UTILITIES
The "touch" command has been removed from the standard distribution due
to its inappropriate use by high-level managers.
Remarque, ASIP ne savait pas le faire non plus (à moins que Laurent n'infirme) ;->
Nan, je confirme, comme tu le dis, s'il ne sait qu'il a été refermé il ne va pas deviner seul :-D
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
Nina Popravka
On Wed, 9 May 2007 10:42:37 +0200, (Laurent Pertois) wrote:
Nan, je confirme, comme tu le dis, s'il ne sait qu'il a été refermé il ne va pas deviner seul :-D
Je voulais dire qu'il n'y avait (et n'y a apparemment toujours pas) de dispositif permettant de fermer le fichier, contrairement à d'autres OS de ma connaissance ;-> -- Nina
On Wed, 9 May 2007 10:42:37 +0200, laurent.pertois@alussinan.org
(Laurent Pertois) wrote:
Nan, je confirme, comme tu le dis, s'il ne sait qu'il a été refermé il
ne va pas deviner seul :-D
Je voulais dire qu'il n'y avait (et n'y a apparemment toujours pas) de
dispositif permettant de fermer le fichier, contrairement à d'autres
OS de ma connaissance ;->
--
Nina
On Wed, 9 May 2007 10:42:37 +0200, (Laurent Pertois) wrote:
Nan, je confirme, comme tu le dis, s'il ne sait qu'il a été refermé il ne va pas deviner seul :-D
Je voulais dire qu'il n'y avait (et n'y a apparemment toujours pas) de dispositif permettant de fermer le fichier, contrairement à d'autres OS de ma connaissance ;-> -- Nina
laurent.pertois
Nina Popravka wrote:
Tu as essayé de relancer le service ? L'équivalent du service serveur, tu veux dire ? Ben non, parce que je
voudrais n'agir que sur le fichier problématique sans déconnecter tout le monde...
Voui.
Sinon, lsof avec un grep sur le nom du fichier pourrait te donner le nom du processus qui le verrouille, je pense. Sûrement, mais grep ==> regexp, et Nina totalement incompatible avec
regexp.
Meuh non, un truc du style :
# lsof | grep -i "nom du fichier"
est amplement suffisant et ne nécessite pas un regexp de la morkitu...
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
Nina Popravka <Nina@nospam.invalid> wrote:
Tu as essayé de relancer le service ?
L'équivalent du service serveur, tu veux dire ? Ben non, parce que je
voudrais n'agir que sur le fichier problématique sans déconnecter tout
le monde...
Voui.
Sinon, lsof avec un grep sur le nom du fichier pourrait te donner le nom
du processus qui le verrouille, je pense.
Sûrement, mais grep ==> regexp, et Nina totalement incompatible avec
regexp.
Meuh non, un truc du style :
# lsof | grep -i "nom du fichier"
est amplement suffisant et ne nécessite pas un regexp de la morkitu...
--
Politically Correct Unix - UTILITIES
The "touch" command has been removed from the standard distribution due
to its inappropriate use by high-level managers.
Tu as essayé de relancer le service ? L'équivalent du service serveur, tu veux dire ? Ben non, parce que je
voudrais n'agir que sur le fichier problématique sans déconnecter tout le monde...
Voui.
Sinon, lsof avec un grep sur le nom du fichier pourrait te donner le nom du processus qui le verrouille, je pense. Sûrement, mais grep ==> regexp, et Nina totalement incompatible avec
regexp.
Meuh non, un truc du style :
# lsof | grep -i "nom du fichier"
est amplement suffisant et ne nécessite pas un regexp de la morkitu...
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
laurent.pertois
Nina Popravka wrote:
Je voulais dire qu'il n'y avait (et n'y a apparemment toujours pas) de dispositif permettant de fermer le fichier, contrairement à d'autres OS de ma connaissance ;->
Je suis d'accord.
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
Nina Popravka <Nina@nospam.invalid> wrote:
Je voulais dire qu'il n'y avait (et n'y a apparemment toujours pas) de
dispositif permettant de fermer le fichier, contrairement à d'autres
OS de ma connaissance ;->
Je suis d'accord.
--
Politically Correct Unix - UTILITIES
The "touch" command has been removed from the standard distribution due
to its inappropriate use by high-level managers.
Je voulais dire qu'il n'y avait (et n'y a apparemment toujours pas) de dispositif permettant de fermer le fichier, contrairement à d'autres OS de ma connaissance ;->
Je suis d'accord.
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
Anonyme
patpro ~ Patrick Proniewski wrote:
en AFP j'imagine... aucune idée. Normalement on tue le process qui maintient le fichier ouvert, mais dans le cas présent le process (client) est déjà mort, et le lock doit être dans le serveur.
Le client est mort, mais le process du client peut-être pas.
en faisant un lsof rooté greppé (ça c'est du bon français), on devrait pouvoir trouver le process et le tuer...
sur le serveur sudo lsof |grep <Lefichier>
récupérer le pid (deuxième colonne)
tuer par un kill -9 <NumPID>
Ceci devrait marcher en une seule ligne (si il n'y a qu'un process sur le fichier) :
Pour <Lefichier>, juste le nom du fichier devrait suffir... (sans les <
)
-- Anonyme ( jayce <@> mosx.net ) ********* MosX.net <http://www.mosx.net/> ********* (avec un put§@#* de problème DNS sur le domaine mosx.net)
patpro ~ Patrick Proniewski <patpro@boleskine.patpro.net> wrote:
en AFP j'imagine... aucune idée. Normalement on tue le process qui
maintient le fichier ouvert, mais dans le cas présent le process
(client) est déjà mort, et le lock doit être dans le serveur.
Le client est mort, mais le process du client peut-être pas.
en faisant un lsof rooté greppé (ça c'est du bon français), on devrait
pouvoir trouver le process et le tuer...
sur le serveur
sudo lsof |grep <Lefichier>
récupérer le pid (deuxième colonne)
tuer par un kill -9 <NumPID>
Ceci devrait marcher en une seule ligne (si il n'y a qu'un process sur
le fichier) :
en AFP j'imagine... aucune idée. Normalement on tue le process qui maintient le fichier ouvert, mais dans le cas présent le process (client) est déjà mort, et le lock doit être dans le serveur.
Le client est mort, mais le process du client peut-être pas.
en faisant un lsof rooté greppé (ça c'est du bon français), on devrait pouvoir trouver le process et le tuer...
sur le serveur sudo lsof |grep <Lefichier>
récupérer le pid (deuxième colonne)
tuer par un kill -9 <NumPID>
Ceci devrait marcher en une seule ligne (si il n'y a qu'un process sur le fichier) :
Pour <Lefichier>, juste le nom du fichier devrait suffir... (sans les <
)
-- Anonyme ( jayce <@> mosx.net ) ********* MosX.net <http://www.mosx.net/> ********* (avec un put§@#* de problème DNS sur le domaine mosx.net)
Nina Popravka
On Wed, 9 May 2007 16:58:20 +0200, (Anonyme) wrote:
Le client est mort, mais le process du client peut-être pas. en faisant un lsof rooté greppé (ça c'est du bon français), on devrait pouvoir trouver le process et le tuer...
La notion de fichier ouvert sans que ça soit lié à un process, ça n'existe pas, pour MacOSX ? Un truc genre un flag "open" tout bête ? -- Nina
On Wed, 9 May 2007 16:58:20 +0200, jayce@mosx.net (Anonyme) wrote:
Le client est mort, mais le process du client peut-être pas.
en faisant un lsof rooté greppé (ça c'est du bon français), on devrait
pouvoir trouver le process et le tuer...
La notion de fichier ouvert sans que ça soit lié à un process, ça
n'existe pas, pour MacOSX ?
Un truc genre un flag "open" tout bête ?
--
Nina
On Wed, 9 May 2007 16:58:20 +0200, (Anonyme) wrote:
Le client est mort, mais le process du client peut-être pas. en faisant un lsof rooté greppé (ça c'est du bon français), on devrait pouvoir trouver le process et le tuer...
La notion de fichier ouvert sans que ça soit lié à un process, ça n'existe pas, pour MacOSX ? Un truc genre un flag "open" tout bête ? -- Nina
