"Thunderbird is already running" ? Ah mais non !

Tags: #<Tag:0x00007fb41a92a218>

Yo !
J’ai déplacé cette nuit mon répertoire ~/.icedove sur un mount sshfs réseau.
J’ai créé ensuite un lien symbolique ~/.icedove vers ce répertoire.

Depuis, quand je lance thunderbird, il m’annonce “Thunderbird is already running(…)” même aprés reboot.
J’ai donc regardé, et il y avait 2 fichiers verrou .parentlock dans l’arborescence: un dans ~/.icedove/toto.default, et un autre dans ~/.icedove/Profiles/tata.default.
J’ai essayé deles supprimer et de relancer thunderbird, mais même en faisant un reboot entre les deux, il recrée le verrou qui est dans le sous répertoire de .Profiles, et refuse de démarrer en m’indiquant que thunderbird tourne déjà. Et le verrou reste quand j’exite.
J’ai aussi essayé de démarrer avec thyunderbird -P et de créer un profil utilisant le même répertoire, mais pareil.
Idem, simplement le fait de créer un nouveau profil et de vouloir démarrer dessus, il me crée un verrou aussi dans le nouveau profil et rale que TB est démarré.

j’ai des configs de rangement un peu lourde et des mails d’un ancien compte imap qui n’existent plus qu’en cache local et je ne voudrais pas perdre tout ça…
La solution de ramener mon .icedove sur ma home n’est pas envisageable, je n’ai plus assez de place pour le reloger sur ma partition home.

Quelqu’un a une idée pour faire refonctionner TB ?

Je viens de faire un test: j’ai recopié ma config TB de nouveau, cette fois vers un disque amovible usb , sur une partition ext4, dans un répertoire ou je suis certain que tous les droits sont bons, et j’ai fait pointer .thunderbird et .icedove vers le répertoire.
=> même symptome: le fichier de verrou se crée mais TB refuse de démarrer, et le fichier de verrou reste à la fin.

Bon, je me répond:
j’ai déplacé des données pour refaire de la place sur ma partition home, et j’ai recopié le rep icedove à sa place d’origine et ça remarche…
Je ne comprends pas pourquoi ça ne marche pas quand c’est sur une autre partoche…
Si vous avez des idées de trucs à tester pour que je puisse déplacer cette foutue config, je suis preneur.

Salut
Visiblement pour les applis Mozilla, c’est pas prévu de fonctionner avec un profile ailleurs que dans /home
peut etre en mettant le chemin complet dans thunderbird/profiles.ini
IsRelative=0 indicates a custom (absolute) profile location
http://kb.mozillazine.org/Firefox_is_already_running_but_is_not_responding#Check_the_profile_folder_name_and_location

A mon avis laisser thunderbird/profiles.ini dans /home en modifiant son contenu pour indiquer le chemin en absolu du profil comme dans l’exemple
IsRelative=0
Path=D:\firefoxProf

C’est quand même bizarre, j’ai des liens symboliques qui rendent les données accessibles par le chemin habituel, je ne vois pas trop ce qui pourrait coincer.
J’ai aussi essayé d’ouvrir directement le profil en dehors de la home avec thunderbird --profile “chemin_absolu_du_profil” et ça ne marche pas mieux, mais bonne idée de tester le IsRelative=0

Bonjour,
Aurais-tu fait la manipulation alors que TB était en fonction ?

Non non. j’avais tout fermé avant.
D’ailleurs depuis que je l’ai remise en place, ça fonctionne, donc ça ne tient pas au contenu, mais bien à l’endroit ou je le met.

avais-tu suivi une procédure comme ça pour déplacer tes mails ?

https://www.it-connect.fr/thunderbird-changer-lemplacement-des-mails/

C’est peut-être du au changement récent car sur leur procédure ça reste à peu de choses près la même :

https://support.mozilla.org/fr/kb/profils-dans-thunderbird#w_daeplacer-un-profil

Alors ça, c’est une procédure pour déplacer juste un profil, ça explique où il faut aller configurer les bons chemins.

Ca pourrait être une solution, mais dans le cas dont je parle, je déplace toute la config et mes chemins de config ne changent pas:
j’accède à tous les fichiers par le même chemin qu’avant donc je n’ai théoriquement rien à changer.

Je vois pas
peut etre un problème de droits
tu as donc un .thunderbird qui pointe sur un lien .icedove qui qui pointe ailleurs?

J’aurais du mettre résolu, même si ça ne l’est pas…

Non en fait, j’ai déplacé une autre partie de mon arbo pour libérer mon SSD (c’était ça mon soucis initial), et je suis revenu à la situation qui marchait en remettant le .icedove à sa place.

Du coup je ne sais pas ce qui ne fonctionnait pas, et je manque de temps pour refaire la manip et débuguer.

J’ai soupçonné cafouillage dans la gestion des droits/le mappage des users sur le sshfs sur lequel j’avais stocké le répertoire, mais ça ne peut pas être ça, vu que j’ai aussi le problème quand je déplace sur mon disque ext4 usb.