Dear Maintainer,

after some security updates I encounter a problem with Thunderbird, that I'm no
longer able to open since. Error message states, that Thunderbird is already
running. Thus, it declines to open.

I even try removing my profile to allow a "fresh start" but it dosen't help
either.

When running from gnome-terminal, I get these errors on console upon starting:
(thunderbird:12521): Gtk-WARNING **: Theme parsing error: <data>:1:34: Expected
')' in color definition

(thunderbird:12521): Gtk-WARNING **: Theme parsing error: <data>:1:77: Expected
')' in color definition

I doubt they are connected to the problem however.

Interestingly, my other installation of Thunderbird works without problem.

Hello Peter,

Am 29.12.18 um 11:02 schrieb Peter Tuharsky:

this problem has nothing to do with your profile.
Thunderbird is doing some magical forking of itself if Thunderbird get
started. Sometimes it happen that some thread in that chain gets broken
so no chain from the first event to the last forked process is available
any more.

Starting Thunderbird for a second time is detecting that already a
process thunderbird is running and is printing out that message you see.

This all is an upstream issue, we can do quite nothing against this in
Debian and I guess there is at least one more existing bug report in the
BTS about this.

You can work around this if you kill any remaining processes of thunderbird.

  $ killall -9 thunderbird

No, these are all messages from GTK, you probably using Gnome3 ad DM.

Well, I see this problem from time to time to. No matter what system I
use. A chance to see this more often is after package updates if you
haven't restarted a running thunderbird after a version update.

Hello Peter,

please use 'Reply All' so the BTS gets your answer too.

Am 30.12.18 um 10:53 schrieb Mgr. Peter Tuhársky:

This can normally not be, at least I've not seen such a behavior in the
past years. The Thunderbird binary must detect at something that it is
already running. So the key than would be to know what Thunderbird is
detecting.
And if you have restarted the machine the only thing that than possible
remains is some file stamp, but Thunderbird doesn't use such things
except while working on your user profile. So I guess simply you have a
lock file in your profile.

http://kb.mozillazine.org/Profile_in_use#Remove_the_profile_lock_file

Finally I found the culprit. It was apparmor!

I have never intentionally done anything with it, but upgrading kernel
version from 4.9 to 4.18 (due to some kernel 4.9 security upgrade
problem that freezes my computer), it must have enabled apparmor by
default or so.

And since I have my home folder symlinked to other drive, and apparmor
does not support symlinks, it denied Thunderbird the access to its lock
file (and other files as well).

After I manually added the real drive path of my profile in
/etc/apparmor.d/usr.bin.thunderbird, it now works.

Should I encounter more problems with other apps, I may as well
completely disable apparmor in grub config.


Dňa 29. 12. 2018 o 14:55 Carsten Schoenert napísal(a):

Hello Peter,

Am 01.01.19 um 16:13 schrieb Peter Tuharsky:

the default of the Thunderbird package is to *not* enable the Apparmor
profile on first time installation and also on updating.
On exception on updates, if the user had activate the AA profile in the
past the package update does not deactivate it.

So I can just think of an active setting to use the AA profile of
Thunderbird which got really active again with the re-installation of
AppArmor.

This makes your report a duplicate of #882218 [1].

This will get overriden by the next update of the Thunderbird package,
head down to the bottom of the profile, you well see the following:

So this is the right place for needed modifications. Have a look at
/etc/apparmor.d/local/README for further information. If ypu have some
useful additions for the file
/usr/share//doc/thunderbird/README.apparmor then please try to write it
down and let us know, the READMEs can always get improvements.

Hmm, if you want to disable AppArmor completely why not remove the
package then?

I know it's not the answer you probably want to hear but reporting the
problems would be better. :)
The AppArmor people in Debian are a really responsive team.

[1] https://bugs.debian.org/882218

Hi, Carsten

Thank You for Your valuable input.

The only things I don't understand, how was AppArmor enabled, and how
was it working for years until the last update of kernel/TB/whatever; I
have symlinked home dir for long time now... Could be that only the last
TB update enabled it?

Well, I could also try to report this to apparmor (and the freezing
problem to kernel team); as You can see, I am ready to report bugs. I
only doubt this could get anywhere, because I'm not so sawwy so to debug
kernel, and Apparmor's inability to process symlinks is a known
"wontfix" bug.

Anyway, thank You again.

Hi Peter,

Am 02.01.19 um 09:12 schrieb Peter Tuharsky:

very very unlikely. We are in the middle of an ESR release and thus the
packaging typically itself isn't changing much.
The code responsible for this wasn't touched for over year now. But we
won't get new information on this what really did happen on your system.
Only if it is reproducible we would see if and were something is maybe
broken and not correctly working.

No need for (in this special case), the problem that AppArmor isn't
following symlinks here is a known fact and the AppArmor people did know
this. More info on this can be found on the other report I've linked to.

Well, the difficult and time consuming debugging work is more the
exception than the normal way and happily the Debian package maintainers
are mostly can do this more effective than the package users. On the
other hand documentation is mostly lacking or out of time (and for
maintainers probably some boring work :P ).

AppArmor is a suite with a lot aspects and corner cases. And
unfortunately some things are impossible with the current used version.

I'm always happy if users are coming up with improvements for
descriptions, readmes etc. Especially for the AppArmor.
So I want to say, it's not always the complicated things that need to be
done, with a POV on the classical users it's mostly a lack of
information and how to organize them. I like the Debian wiki and so we
have a page for Thunderbird there too and we can easily link this from
the readme files.

https://wiki.debian.org/Thunderbird

If you are interested to do any improvements at any thing please feel
free to do so.

Am 02.01.19 um 09:39 schrieb Carsten Schoenert:

After updating from stretch to buster, I did have exactly that problem. After longer testing I found
it's apparmor. I never used apparmor at all or activated anything, so I don't know how this happened.

Switching off the profile as described here (https://help.ubuntu.com/community/AppArmor) made it
work again. Is this the way to go or is there anything else I have to take care of?


Thank you very much,
Philipp

It seems that AppArmor may activate during kernel (linux-image) update
because it is one of dependencies.

Dňa 11. 9. 2019 o 9:18 Philipp Pilhofer napísal(a):

Hi there,

same problem here: After upgrading from Debian 9 (Stretch) to 10
(Buster) Thunderbird stopped working.
Thanks to this bugreport I disabled the apparmor-profile "thunderbird"
and thunderbird was running again as before.
When I tried to set the apparmor-profile to "complain", aa-complain gave
the following error:

ERROR: /etc/apparmor.d/usr.bin.thunderbird doesn't contain a valid
profile for /usr/bin/thunderbird (syntax error?)

Disabling the profile (see Philipp's post) worked without problems.

Regards
   Hansjörg

Hi,

Am 25.11.19 um 00:19 schrieb H. Buchberger:

the question is why the AA profile for Thunderbird was active?

The default is that Thunderbird hasn't an activated AA profile.
In difference to buster it might be that same data within the profile
are not compatible with apparmor version in stretch.

Hi Carsten,


as my Thunderbird mail profile (not Thunderbird AA profile) was working
well before the upgrade stretch -> buster and did not work any more
after the upgrade, the upgrade must have got something to do with it.

(The mail profile is symlinked, that should be the reason why
Thunderbird was not able to use it with the AA profile active.)

Unfortunately I don't have a complete back of my system before the
upgrade. But from the history in this bug report I guess that the AA
profile was already defined in stretch - probably disabled.

So the upgrade might have removed the "disabled" setting.


BTW: During my upgrade stretch -> buster Thunderbird (and Firefox) was
also updated (from version 60.9.0 to now 68.2.2) and after that I had to
"downgrade" my Thunderbird mail profile. Also a bit weird.

Hello Hansjoerg,

Am 25.11.19 um 23:16 schrieb H. Buchberger:

no, we don't touch or modify any data within the /home folders without
interacting by the user.
The only automatic controlled instance that can make changes to the
users profile is the Thunderbird application itself.

Also here my answer is no, the postinst script for the thunderbird
package has some magic to not enable the AA profile within new
installations. But it will keep an AA profile as active it it was active
before the update.

You can't 'downgrade' your mail profile. The only possible and
reasonable action would be to replace the existing profile with an backup.

But we are going in circles, the truth can be found in the (sys)log. And
the root for issue here will be apparmor.

See also https://wiki.debian.org/AppArmor/Debug

Good morning,

Am 26.11.19 um 08:14 schrieb Carsten Schoenert:
I certainly did never touch AA, as I did not even know what it is. And after my stretch to buster
upgrade, I had to deactivate it manually as tb was not working any more (because of my symlinked tb
mail profile, which I of course did not change during the upgrade).

I do not know the cause, but it seems obvious that the tb AA profile under some circumstances
becomes activated during upgrade process. Everyone posting in this bug issue seems to experience it
... I guess the "magic not to enable the AA profile" does not work always ...?


Best wishes,
Philipp

Hello Phillip,

Am 26.11.19 um 09:40 schrieb Philipp Pilhofer:
...

the magic is quite simple, if the installation is a new installation and
the version is greater than 1:52.5.0-1~ don't modify the installation
and leave the TB AA profile disabled.
If the above is not given than disable the AA profile. And further that
means that a user is doing an update and the profiles was active it will
also be activated after the installation of the newer version.

It was added / modified by this commit
https://salsa.debian.org/mozilla-team/thunderbird/commit/81a8c00dc530c7dedf83c9857b227c3c3c164e22

It helps nothing if we all do some some wild guessing, someone has to
proof if something is broken in case the user is doing a dist-upgrade
from stretch to buster. It's also possible that AppArmor is doing some
special in case of a dist-upgrade. The versions are different between
the releases.

Am 26.11.19 um 19:51 schrieb Carsten Schoenert:

I do not understand that code completely, but if it does what you say it
should be all fine.

Yap, sorry for my wild guessing ... it definitely is weird, as I
upgraded two (or three?) machines with more or less the same
configuration (tb profile "somewhere else") and it happened only in one
case IIRC.


Best wishes,
Philipp

Hello Carsten,


sorry, I have to add some more guessing ...


Am 26.11.19 um 08:14 schrieb Carsten Schoenert:

No doubt about that. No data within /home (or wherever my mail profile
is) was touched.

It's just apparmor that behaved different after the upgrade. But as I
don't have a full backup of the system, it's not reproducible.

Maybe apparmor was completely disabled in my installation of stretch and
was enabled during the upgrade? We'll never know. ;-)
Well, thunderbird and firefox refused to start after the upgrade. Both
have an command line option "--allow-downgrade  Allows downgrading a
profile.".

After starting up with his option, both worked fine with my "old"
profiles. (But also here I have no idea what this option does, just
observing and guessing.)


Regards

    Hansjörg

We believe that the bug you reported is fixed in the latest version of
thunderbird, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 917613@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Carsten Schoenert <c.schoenert@t-online.de> (supplier of updated thunderbird package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)
Format: 1.8
Date: Mon, 22 Jun 2026 21:41:06 +0200
Source: thunderbird
Architecture: source
Version: 1:152.0-1
Distribution: experimental
Urgency: medium
Maintainer: Carsten Schoenert <c.schoenert@t-online.de>
Changed-By: Carsten Schoenert <c.schoenert@t-online.de>
Closes: 880424 882218 883245 900210 909281 914403 917613 928178 949450 949649 955380 961269 1127710 1128672 1128876 1138513
Changes:
 thunderbird (1:152.0-1) experimental; urgency=medium
 .
   [ Carsten Schoenert ]
   * [5097e09] d/control: Bump B-D for libnss3-dev
   * [5350030] New upstream version 152.0
     (Closes: #1138513)
   * [92962df] Rebuild patch queue from patch-queue branch
     Removed patch (included upstream):
     fixes/Fix-conflicting-types-for-once_flag-and-call_once-with-gl.patch
     fixes/Fix-math_private.h-for-i386-FTBFS.patch
     fixes/Fix-sandbox-to-build-with-glibc-2.43.patch
   * [46de392] d/mozconfig.default: Remove option --enable-av1
 .
   [ Christoph Goehre ]
   * [5308430] rebuild patch queue from patch-queue branch (Closes: #1128876)
 .
   [ intrigeri ]
   * [77d16c3] Don't install AppArmor policy anymore
     (Closes: #1128672, #1127710, #928178, #909281, #955380, #882218, #900210,
      #914403, #917613, #949450, #880424, #883245, #961269, #949649)
Checksums-Sha1:
 1e9bca601d3dab684f2c1e34bbd107712eb17f8e 8402 thunderbird_152.0-1.dsc
 5ed145d0f72ee7e539f3f0d40cea83ed62b1499f 12403192 thunderbird_152.0.orig-thunderbird-l10n.tar.xz
 dbef2f6a94cec7b667931b222bdd6f0aaf9a4810 931861244 thunderbird_152.0.orig.tar.xz
 6fc9531bd0e3c27e7908228227a542966eb827f8 537512 thunderbird_152.0-1.debian.tar.xz
 41476b21bed4090bcf2c148b0178ef52d0e2f2e7 40158 thunderbird_152.0-1_amd64.buildinfo
Checksums-Sha256:
 8d348b506605fc73d56722d5a55ed9dae8af623989312e5c039786edfbe4f0f2 8402 thunderbird_152.0-1.dsc
 f4afa9846377239357e485da027035fe53762cc8100ced5cf5abca87fca7a1f8 12403192 thunderbird_152.0.orig-thunderbird-l10n.tar.xz
 64f02562f1f4a18e39c67b07255feb5828acde86327f55b1ebe45e3ac63963ea 931861244 thunderbird_152.0.orig.tar.xz
 52abff98afbeb3859791f46e5602bbbf6982f38876f7e223d0ff1ac7bb77c778 537512 thunderbird_152.0-1.debian.tar.xz
 38ab10bf14449c38f7233f8d883b1a6ffbe412606232763f9bcaa5dcda320c03 40158 thunderbird_152.0-1_amd64.buildinfo
Files:
 cddc168c5e8bdb4c051a11b4e56831b8 8402 mail optional thunderbird_152.0-1.dsc
 27c69983d0063061996fc52794377743 12403192 mail optional thunderbird_152.0.orig-thunderbird-l10n.tar.xz
 f49e9b967f1a1fdceec316060aef4959 931861244 mail optional thunderbird_152.0.orig.tar.xz
 d435a5b441fa39456dfa21b01881fdf3 537512 mail optional thunderbird_152.0-1.debian.tar.xz
 20c10b422095bf9f1d461c01e152c30e 40158 mail optional thunderbird_152.0-1_amd64.buildinfo
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEtw38bxNP7PwBHmKqgwFgFCUdHbAFAmo5mL4ACgkQgwFgFCUd
HbCPqw/+LEBi5TrBqIfSUOoosSHHufs3R4FzJrZ6vNsK4ur6EVNNhR1u0Gc4VtEG
JIaiGg7fCDf3mgAowEIKSQpVHnqMPKpqZemfIWHNT0exdKp1RXlh9OuwGdOqg0Og
5MWrhKzrDVr7p9LmB7ilQ2V0I+xHx1zh/cG58Ar2Pp9Wn8YDlpIQmO0vp6sX2ex5
GTUYHvVrssW4L/hOAsbMu9YUnGPRiHPvj94JF7XT2JFC6mndXtiqvEOH5Oo1UluK
FcM8Xz1GsANmwB4gR7/g0f06RWEjAsOMXPU98ESaY85kRTJ4VlVvGWOknGa0Sptv
frrEG893xRFXFmnrDR7dLH8Ux1cnsGy5wpNCZeLVViuT6Pv4OIm83jijKqaGHvp3
jdD8OWx7YGbYdm+INBBnff5Y/IEEni7EIuX17/S3ZNqlLYJGPbL6OWG+pMK52+xZ
0dMFXCrSMc+xMMUHBQ/aUw3up5t4B5de51tX9kWTFv3W/qIiLdA+PpH2EGiJJJIF
Jgm9q0sAlXLC2GZW55MTbk2/jhewQOcShIRrEKFJUPzpPgeXZAAN/I47uKAzoUAW
0x/Hb0+b72NKBlK8jurZfKYBDPyxLnHSUcCbVCPj8SyzxcCHBZ12jsVhIEjUwMEH
cyFP/Ep5MDC7yo9XX+Xt4na47jktwLRJ5jRpySaIV9RfhvBHPNQ=
=jjF1
-----END PGP SIGNATURE-----