Bug 484846

I agree the lock file handling can be improved. I have brought up the issue with upstream. 

However, you shouldn't always be seeing a lock file... twinkle should exit and remove it's lock when it does. How are you logging out? Is this gnome or kde? Or something else?

When you logout, can you login via ssh or a vty and see if twinkle is still running for some reason?

When I log out of Gnome and then log in on a VT, I see that the twinkle lock file is still there, and twinkle is not running.  On the other hand, if I quit twinkle explicitly by using File/Quit, or if I send twinkle a standard kill signal (15), then twinkle deletes the lock file.

In any case, it's not that important whether twinkle cleans up the lock file or not.  The use of the lock file is just an optimization to speed up startup.  Far more important is correct behavior (not assuming from the existence of the lock file that another copy of twinkle is running, unless it verifies that the lock file PID actually corresponds to another _twinkle_ instance).  The issue of not deleting the lock file shouldn't even be looked at until after the correctness issue is fixed.

Another reason for not dealing with the lock file cleanup until later is that the broken startup lock file logic only manifests when a lock file is left behind.  If it was cleaned up consistently, then the present bug would only be seen in the rare event that a lock file was left behind due to something like an unclean shutdown, and hence would probably never get fixed.  Please tell upstream to fix the startup logic (this bug, which is an actual bug) first, and the shutdown logic (which is just an optimization failure, not even really a bug) later.

I should also mention that correctness requires that the startup logic needs to check whether the PID in the lock file corresponds to an instance of twinkle owned _by the same user_.

Well, I agree both issues need to be fixed. 

I don't think you are likely to get too far telling people what bugs they should look at and in what order. I have raised the issue upstream, hopefully they can come up with some fixes, or I can find the time to take a look further. 

Feel free also to chime in on the upstream devel list: 
http://tech.groups.yahoo.com/group/twinklephone/

I responded on the upstream devel list, but my message hasn't appeared yet.  I indicated that I log out of Gnome in the usual way, by logging out.  It's consistent for me so you should be able to reproduce it.  But I hope the startup bug gets fixed first, since if the lock file gets deleted consistently on clean shutdowns, then it would only exist on unclean shutdowns, so this bug would still exist, but would be much harder to reproduce.

It looks like your reply went to just me. Can you resend to the list?

I was not previously a member of the twinklephone group, so it's possible that I was not allowed to post to the whole group, even though I have a Yahoo account.  I joined the group and then posted again, verifying that it was posted to the group.  I still don't see the new message, but hopefully it will show up.  In case it doesn't, I expressed a concern about whether unclean shutdowns would prevent the lock file from getting deleted.

Same behavior in Rawhide with twinkle-1.4.1-1.fc11.x86_64 (although I'm sure Michel de Boer knows that already).  Should this bug be cloned?

No need. It sounds like Michael has a fix upstream that will be in the next release. I will build it for both rawhide and F-10.

twinkle-1.4.2-1.fc10 has been submitted as an update for Fedora 10.
http://admin.fedoraproject.org/updates/twinkle-1.4.2-1.fc10

Would you care to try the above update? Hopefully it fixes the issue.

I noticed that you successfully built this for both F10 and rawhide.  I'll start running it on login on both of these, but since the problem only manifested about 5-10% of the time before, it will take a while to be sure if it's fixed.

No problem. Test as you are able. 

I have been running the rawhide version here for a bit, it just wouldn't offically build due to some kde libs issues until today. Let me know if you spot any problems with them.

Running twinkle-1.4.2-1.fc10.x86_64 on F10, today when I booted up and logged in, I was told that my sound Ring tone device was wrong.  I'm used to having to manually change the sound devices when logging in, though it's usually the Speaker and Microphone devices, not the Ring tone device.  Also, when I look, the Ring tone device  (ALSA: default: Default device) is correct, but the other two are wrong.  Anyway, I make the changes, then try quitting and restarting Twinkle as usual, to make sure the changes stick.  This time they didn't, so I tried fixing the sound devices, quitting and restarting several time without success.  Then I tried logging out and back in, without success.  Finally, after quitting and restarting Twinkle, I got the changes to stick.

I also noticed that there is now a 0-byte lock file in ~/.twinkle which is still not deleted when I log out.  In addition, it's no longer deleted when I explicitly quit Twinkle, either.  Don't know whether this is supposed to be normal behavior.  In the struggle described in the previous paragraph, I might only have succeeded after manually deleting the lock file, but am not sure.

twinkle-1.4.2-1.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 twinkle'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2009-2346

I think the lock file is no longer used at all. You should be able to delete it yourself or just ignore it. 

Strange on the settings issue. If you see it again, please file a new bug on it. 

Does the locking issue appear fixed at least?

I haven't seen the lock file error yet, but it hasn't been long enough to tell.  The problem I've experienced is a minor nuisance so I have no objection to this going to updates-released if no one else does.  The lock file reappears after deleting it and restarting twinkle, so it seems to be getting used for something.

I'm guessing that the need to keep resetting the sound devices is due to Alsa devices being named using numbers, as opposed to their real names - as mentioned in

http://alsa.opensrc.org/index.php/MultipleCards

Ekiga doesn't seem to have the problem.  Do you think this is the cause?  If so, I'll file a separate bug for this issue.

I have not seen the problem described in comment #15 again, or the lock file error, either.  Karma +1

Regarding the sound settings, I posted to the twinklephone list, am still waiting for additional replies.

Excellent. I will leave this open for now, and let it be closed when this update goes into stable in a little bit. 

Yes, I saw your post. Thanks for the report. :)

twinkle-1.4.2-1.fc10 has been pushed to the Fedora 10 stable repository.  If problems still persist, please make note of it in this bug report.