Description of problem: On occasion, a stale lock file ~/.liferea/lock may be left behind; this can occur after a power outage, for instance. When this happens, starting liferea gives this dialog box: 'Another copy of Liferea was found to be running. Please use it instead. If there is no other copy of Liferea running, please delete the "~/.liferea/lock" lock file.' [OK] There ought to be a button to do that for you: to remove the lock file, and continue. (For example, GnuCash does this.) Version-Release number of selected component (if applicable): liferea-1.0-0.1.rc4.fc4 How reproducible: 100% Steps to Reproduce: 1. Start liferea 2. killall liferea-bin 3. Start liferea Actual results: Can't without opening a terminal or a file manager.
The current versions should automatically remove the stale lock files if the process that created it isn't running anymore. To allow this the lock file contains the PID of the creating process. So if the dialog pops up the program found the original process to be running and continuing is not advisable. If you are still experiencing this problem, please re-open this bug.
liferea-1.0.14-2.fc5 still shows this behaviour. What's more, it now seems to be crashing every time I log out, and so each time I log in I am told to remove the lock file. :-/
I've been experiencing a variation on this issue for the last few releases. When I quit liferea by selecting Program -> Quit using the toolbar menu, I'm ok. When I quit using the X button on the top, right hand side of the window, I am prompted to remove a lock file when I try to relauch liferea. Also, if I just log out of Gnome and do not close any of my open applications before hand, I will be prompted to remove a lock file when I log back in and restart liferea. This behavior is still present in liferea-1.0.18-2.fc5, which I just installed today.
Sorry, forgot to mention that when the lockfile error dialog pops up, the liferea-bin process is still running and when I use strace -p to attach to the process, I see something output like this scrolling by very quickly: gettimeofday({1154562561, 258812}, NULL) = 0 poll([{fd=4, events=POLLIN}, {fd=3, events=POLLIN}, {fd=8, events=POLLIN|POLLPRI}, {fd=10, events=POLLIN|POLLPRI}, {fd=11, events=POLLIN|POLLPRI}, {fd=12, events=POLLIN|POLLPRI}, {fd=16, events=POLLIN}], 7, 99) = 0 gettimeofday({1154562561, 358047}, NULL) = 0 ioctl(3, FIONREAD, [0]) = 0 gettimeofday({1154562561, 358326}, NULL) = 0 poll([{fd=4, events=POLLIN}, {fd=3, events=POLLIN}, {fd=8, events=POLLIN|POLLPRI}, {fd=10, events=POLLIN|POLLPRI}, {fd=11, events=POLLIN|POLLPRI}, {fd=12, events=POLLIN|POLLPRI}, {fd=16, events=POLLIN}], 7, 0) = 0 ioctl(3, FIONREAD, [0]) = 0 gettimeofday({1154562561, 358756}, NULL) = 0
Tom's issue is clearly different from the original bug where Liferea were unable to remove obviously stale log upon restart. He has a situation where old Liferea continus to run (erroneously, after getting WM_DELETE or such). This needs a clone bug or a new bug. Regarding Tim's problem, it's very curious. I used to have it too, with his original version (from FC-4). I communicated with Lars and he seems to have fixed this. I tested liferea-1.0.11-2.fc5 to fix the stale lock removal. I'm on rawhide currently, and it works fine (e.g. I can kill it with -9 and it restarts fine. However it will prompt for the lock removal if other process hogs the PID, thus proving that the "kill with zero signal" trick works). Tim, when it prompts, can you check if other process sits at the old PID? PID is in the symlink name, so: [root@lembas zaitcev]# ls -l .liferea/lock lrwxrwxrwx 1 zaitcev zaitcev 48 Sep 7 17:10 .liferea/lock -> /q/zaitcev/.liferea/lock-lembas.zaitcev.lan.4583 [root@lembas zaitcev]# ps -p 4583 u USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND zaitcev 4583 0.0 3.9 113184 20292 ? Sl Sep07 6:21 /usr/bin/lifere [root@lembas zaitcev]#
Er... I didn't mean to close this.
Tim, are you still seeing this bug? I believe all the version in FC6 and above don't use the lock file anymore.
No, I'm not.
I'm going to close this then, since liferea isn't using a lock file anymore.