Bug 496037 - the applet crashes when mounting/umounting LUKS encrypted volumes
the applet crashes when mounting/umounting LUKS encrypted volumes
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: gnome-applet-timer (Show other bugs)
11
x86_64 Linux
low Severity medium
: ---
: ---
Assigned To: Christoph Wickert
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-04-16 04:34 EDT by Piergiorgio Sartor
Modified: 2010-06-28 07:51 EDT (History)
1 user (show)

See Also:
Fixed In Version: 2.1.2-2.fc10
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-06-28 07:51:26 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Piergiorgio Sartor 2009-04-16 04:34:23 EDT
Description of problem:
This is a funny one.
I've an external firewire HDD, with encrypted partition using LUKS.
This HDD is almost always connected to the PC, so it is *not* automounted on hot plug (since it is not hot plugged).
In order to mount/umount it, I usually use nautilus.
Now and then, just during or after (difficult to time it) mounting/umounting, the gnome-applet-timer crashes, with a pop-up asking if the applet should be reloaded.

Version-Release number of selected component (if applicable):
gnome-applet-timer-2.0.1-9.fc10.x86_64

How reproducible:
Not always, but often

Steps to Reproduce:
1.
install the applet on one gnome-panel
2.
mount/umount this external HDD from nautilus
  
Actual results:
The applet crashes and a pop-up ask if it should be reloaded.

Expected results:
Well, nothing about the applet.

Additional info:
A "dmesg" just after the event, reports:
...
python[3154]: segfault at 1 ip 00007f2c14bb55c0 sp 00007fff2348b170 error 4 in libgobject-2.0.so.0.1800.4[7f2c14b8e000+41000]
...

So, this could be a python problem, which could be confirmed by the fact that, maybe, also other python applications crashed during the "gnome-mount" operation (but I cannot confirm exactly, sorry).

It would also interesting to understand which implications this could have.
Since we are dealing with an encrypted thing, with password, I wonder if there could be some leakage somewhere.
This could be, in the end, a security issue.
Comment 1 Christoph Wickert 2009-04-16 04:57:07 EDT
Indeed, this is really strange.

Please try to reproduce it with more debug info by performing the following steps:
1. remove all instances of the applet from your panel
2. run /usr/lib/timer-applet/timer-applet in a terminal
3. add the applet to your panel again
3. mount/unmount your external drive until the applet crashes
4. attach the output from the terminal to this bug.
Comment 2 Piergiorgio Sartor 2009-04-16 05:39:23 EDT
One thing I forgot, this is an x86_64 installation, maybe this could make the difference.
Anyway, here it is, not so much, to be honest:

$> /usr/lib64/timer-applet/timer-applet
Using these definitions:
GETTEXT_PACKAGE: timer-applet
LOCALE_DIR: /usr/share/locale
RESOURCES_DIR: /usr/share/timer-applet
IMAGES_DIR: /usr/share/pixmaps
Timer Manager D-Bus object path: /net/sourceforge/timerapplet/TimerApplet/TimerManager

At that point it crashed while mounting the LUKS volume 2 out of 3 times.
Of course, I also re-added the applet to the panel.

The D-Bus thing could have something to do.
I do not know how it works, but maybe a message is broadcasted from gnome-mount and the applet (or python) does not like it.

Hope this helps,

pg
Comment 3 Christoph Wickert 2009-04-16 06:08:10 EDT
Thanks, this helps a lot. I think that dbus is the culprit here, because we had some libnotify/dbus issues previously in bug # 471465. Looks like the patch in this release isn't working properly. Upstream pushed a new version, but I have updated it only in rawhide.

Please try if the updated package from http://koji.fedoraproject.org/koji/taskinfo?taskID=1301994 fixes your problem.
Comment 4 Piergiorgio Sartor 2009-04-16 06:23:55 EDT
Thanks for the update.
Unfortunately, this seems to have some issues, I cannot add it to the panel, an error is returned.
From command line, I get:

$> /usr/lib64/timer-applet/timer-applet 
Using these definitions:
GETTEXT_PACKAGE: timer-applet
LOCALE_DIR: /usr/share/locale
RESOURCES_DIR: /usr/share/timer-applet
IMAGES_DIR: /usr/share/pixmaps
Traceback (most recent call last):
  File "/usr/lib64/timer-applet/timer-applet", line 25, in <module>
    from timerapplet.controllers import GlobalController, TimerApplet, TimerService, TimerManagerService
  File "/usr/lib/python2.5/site-packages/timerapplet/controllers/__init__.py", line 18, in <module>
    from TimerApplet import TimerApplet
  File "/usr/lib/python2.5/site-packages/timerapplet/controllers/TimerApplet.py", line 26, in <module>
    import gst
ImportError: No module named gst

Maybe some dependencies is missing?
I hope "gst" does not refer to gstreamer...

pg
Comment 5 Christoph Wickert 2009-04-16 06:35:56 EDT
(In reply to comment #4)
> I hope "gst" does not refer to gstreamer...

Sorry to disappoint you, but actually it does. Upstream has switched to gstplay instead of the obsolete nome.sound_play function. Thanks for catching this, I will roll a new pakage with proper dependencies. Meanwhile, please install gstreamer-python and try again. TIA!
Comment 6 Piergiorgio Sartor 2009-04-16 08:32:26 EDT
(In reply to comment #5)

> Sorry to disappoint you, but actually it does. Upstream has switched to gstplay
> instead of the obsolete nome.sound_play function. Thanks for catching this, I

Ops...! :-)
Well, I was just surprised to see that a small gadget needs quite an infrastructure to work.
Nevermind, it is not a problem.

> will roll a new pakage with proper dependencies. Meanwhile, please install
> gstreamer-python and try again. TIA!  

OK, I installed the dependency and re-added the applet.

The very first "mount" led to a crash, but successive trial could not reproduce the problem.

I also tried to repeat the procedure with the command line, but I was not able to crash the applet again.
Even if, after some mount/umount, the command line part exited, without any error, but the applet was still working.

Nevertheless, I think this could be considered fixed.
If it happens again I'll put a note here.

Thanks again,

pg
Comment 7 Piergiorgio Sartor 2009-04-16 08:34:20 EDT
Sorry, I was too fast.

I tried a mount again and the applet crashed.

Maybe now is more robust, but not really fully fixed.

pg
Comment 8 Christoph Wickert 2009-04-16 08:44:36 EDT
Can you please try again after logging out and in again or even rebooting, just to make sure?
Comment 9 Piergiorgio Sartor 2009-04-16 09:33:51 EDT
(In reply to comment #8)
> Can you please try again after logging out and in again or even rebooting, just
> to make sure?  

It could be this made the trick, since after reboot (I guess logout/login would have been enough) I had 3 applet on the panel.

Anyway, after removing all 3 and re-adding the timer (and verifying there is only one), I tried several times to mount/umount the LUKS volume.
I did not get any crash so far, so maybe it is OK.

Thanks,

pg
Comment 10 Christoph Wickert 2009-04-16 09:44:52 EDT
Ok, then I assume that it is fixed with the update I'm going to push out. The bug will be ON_QA for a while, please report if the bug hits you again.

Thanks a lot for your bug report and your help to debug the problem!
Comment 11 Fedora Update System 2009-04-16 10:16:43 EDT
gnome-applet-timer-2.1.2-2.fc10 has been submitted as an update for Fedora 10.
http://admin.fedoraproject.org/updates/gnome-applet-timer-2.1.2-2.fc10
Comment 12 Fedora Update System 2009-04-17 14:02:08 EDT
gnome-applet-timer-2.1.2-2.fc10 has been pushed to the Fedora 10 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update gnome-applet-timer'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2009-3718
Comment 13 Piergiorgio Sartor 2009-04-19 05:38:20 EDT
In the last few days I was mounting/umountig the LUKS volume, without problems.
Just right now, while mounting, the applet crashed again.

So, maybe there is still something left to check.

Hope this helps,

pg
Comment 14 Christoph Wickert 2009-04-19 08:05:11 EDT
I'll need to talk about this with upstream. Stay tuned.
Comment 15 Fedora Update System 2009-05-06 19:22:47 EDT
gnome-applet-timer-2.1.2-2.fc10 has been pushed to the Fedora 10 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 16 Piergiorgio Sartor 2009-05-07 04:27:05 EDT
I guess this should not be closed, since the problem is still there, albeit it happens not so often as before.

Actually, I got the crash still 1/2~1/3 of the times I mount the LUKS disk.

pg
Comment 17 Piergiorgio Sartor 2009-07-07 07:27:16 EDT
Some news.

I'm now on F-11 and, while I did not see (yet) the problem with the external HDD I used before, I could get the crash (python segfault) with another external USB storage, which is connected/mounted, or umounted/disconnected, by scripts.

It seems some operation in the scripts causes a segfault.

The "start" scripts does:

mdadm -A ... &&
lvchange -ay ... &&
cryptsetup luksOpen ... &&
mount ...

The "stop" script does the reverse, i.e. umount, luksClose, -an, --stop...

One (or more) of the operations crashes the applet.

Hope this helps,

piergiorgio
Comment 18 Bug Zapper 2009-11-18 06:44:31 EST
This message is a reminder that Fedora 10 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 10.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '10'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 10's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 10 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 19 Piergiorgio Sartor 2009-11-20 10:20:22 EST
I "updated" this to f11, because, while the situation is much better, still sometimes I experienced the crash while mounting the luks disk.

I will see after f12, if no problems occur, then, I think, it would be possible to let this issue fall off.

bye,

pg
Comment 20 Christoph Wickert 2009-11-21 08:25:12 EST
Thanks for updateing the bug to F11. I'm not a friend of the bugzappers who just close down bugs, I prefer fixing them properly.

Please test in F12 again. With abrt, the automatic bug reporting tool, we should be able to get a nice traceback without too much hassle. TIA!
Comment 21 Piergiorgio Sartor 2010-04-07 05:02:45 EDT
Hi,

short update, with F12 I never saw the issue again, so it seems it is somehow gone.

bye,

pg
Comment 22 Bug Zapper 2010-04-27 09:42:09 EDT
This message is a reminder that Fedora 11 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 11.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '11'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 11's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 11 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 23 Bug Zapper 2010-06-28 07:51:26 EDT
Fedora 11 changed to end-of-life (EOL) status on 2010-06-25. Fedora 11 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

Note You need to log in before you can comment on or make changes to this bug.