Bug 1183320 - nano occasionally does not clear file lock
Summary: nano occasionally does not clear file lock
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: nano
Version: 21
Hardware: x86_64
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: Kamil Dudka
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-01-18 15:47 UTC by Don Swaner
Modified: 2015-02-01 00:25 UTC (History)
3 users (show)

Fixed In Version: nano-2.3.4-6.fc21
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-02-01 00:25:57 UTC
Type: Bug


Attachments (Terms of Use)
My usual .nanorc file less comments (801 bytes, text/plain)
2015-01-26 11:59 UTC, Don Swaner
no flags Details


Links
System ID Private Priority Status Summary Last Updated
GNU Savannah 42373 0 None None None Never

Description Don Swaner 2015-01-18 15:47:51 UTC
Description of problem:
Intermittently, nano does not clear the "vim style file lock" when nano is exited.

Version-Release number of selected component (if applicable):
nano-2.3.4-4.fc21.x86_64

How reproducible:
Problem is intermittent.

Steps to Reproduce:
1.  Edit a file, with "set locking" in .nanorc
2.  Make some changes
3.  save file and exit nano
4.  try to edit same file again

Actual results:
Occasionally one gets the standard warning message that another process (nano) is editing the file when this is not the case.  Most of the time, the lock is properly cleared.

Expected results:
The lock is always properly cleared.

Additional info:
If one responds to the warning message by "Yes, continue anyway", the lock will be cleared.

Comment 1 Kamil Dudka 2015-01-20 11:09:25 UTC
I am not able to trigger the bug, neither I found anything obvious in the code that would cause it.

Comment 2 Don Swaner 2015-01-20 14:21:30 UTC
I have experienced the error about 3 times in the last week.  I'd guess it's occurring about 10% of the time (when nano is invoked in non-view mode).  I use nano a lot, but most often in view mode.  I'll start logging when nano is invoked in non-view mode, and when the error occurs and report back with a better estimate of how often it is occurring.

Comment 3 Don Swaner 2015-01-21 20:18:59 UTC
Got the bug again today. Revised rough estimate: bug occurs about 1% of the time.
Some details on an occurrence of nano failing to clear a lock:
Error message from PID 29230 ("nano BUG_nano_clear_lock.txt"):
	"File being edited (by nano 2.3., PID 28296, user dswaner), continue?"
"pgrep -a nano" shows only PID 29230 - it does not show PID 28296, which presumably already terminated (without clearing the lock).
"ps -f --pid 28296" shows a null (no such process).

The above appears to indicate that this is indeed a bug (in something or other) and not a user error.  I thought it might have been my error, facilitated by having "set suspend" in .nanorc (which I have since unset).  (Why would anyone want to suspend an edit session these days?)

Comment 4 Don Swaner 2015-01-22 14:44:50 UTC
Very intermittently, it appears that sometimes nano "gets the PID wrong".  Trying to update the same file from two different terminals, nano gives the appropriate warning that the file is being edited elsewhere, but it sometimes (*very* rarely) gives the wrong PID.  Doing a "pgrep -a nano" will show that the PID in the nano error message is not correct.

Comment 5 Don Swaner 2015-01-22 16:35:01 UTC
A few hours after the above comment, I was trying the same thing again.  Now, consistently, nano *always* gets the PID wrong, whereas a few hours ago, it almost always got the PID right???  To reproduce the problem:  1) open 3 terminals (or tabs); 2) in terminal #1, nano an existing file (temp.txt used in this example); 3) in terminal #2, "nano temp.txt" (same file) - result: warning message with PID of conflicting nano; 3) in terminal #3 do a "pgrep -a nano" showing the PID's of the running nano's.  Result: the PID's of the running nano's do not match the PID in the warning message.

Now, a few minutes later, the PID's are matching again.  I opened a 3rd nano briefly (in a 4th terminal), and this seems to have caused the PID's to sync again.  It appears that the error can be reproduced if you try it, then leave the PC idle for 10 minutes or so, and then try again?  The wrong PID displayed appears to be an old PID (smaller sequence number).

Presumably this second "wrong PID" problem is related to the first reported problem, "not clearing lock".

Comment 6 Kamil Dudka 2015-01-23 16:46:21 UTC
So far I have not been able to reproduce the bug.  Note I usually do not use nano unless I am debugging the editor itself.  Could you please exclude influence of the other options in your ~/.nanorc and /etc/nanorc?

Does the bug still occur with original /etc/nanorc and ~/.nanorc containing solely the "set locking" line?

Have you noticed any errors related to locking in the status bar of nano?

Comment 7 Don Swaner 2015-01-23 22:55:53 UTC
Invoking nano with the -I (ignore /etc/nanorc and ~/.nanorc) and with -G (set locking), I immediately got both errors at once (presumably the erroneous lockfile was previously created, before this nano session).  The errors I have been referring to show up in the status bar of nano.  In the example that just occurred, the nano status bar reads:

File being edited (by nano 2.3., PID 28296, user dswaner), continue?                            
 Y Yes
 N No           ^C Cancel

When I do a pgrep -a nano (in another terminal), the result is:

8887 nano BUG_nano_clear_lock.txt

So PID 8887 is the only nano running, but it is complaining that there is a nano with PID 28296 with a lock on the file.

It appears that there is a persistent lock file (somewhere) for PID 28296, which didn't get cleared.  If I respond "Yes (continue)", it will clear the lock.

I responded "Yes" and the old lock was cleared, even though I didn't modify or save the file, just exited.

When I tried to access the same file from two different terminal / nano sessions, I got the usual warning message:

File being edited (by nano 2.3., PID 8682, user dswaner), continue?                             
 Y Yes
 N No           ^C Cancel

As has happened previously, the PID 8682 in the error message is wrong.  "pgrep -a nano" gives the two running nanos as:

8938 nano -I -G BUG_nano_clear_lock.txt
8939 nano -I -G BUG_nano_clear_lock.txt

So, with only the "set locking" option, the second problem (wrong PIDs) reported above has been reproduced.  The first problem (lock file not cleared) has been partly reproduced.

To reproduce the lock file not cleared problem (which only happens about 1% of the time) with only "set locking" option would be a major inconvenience - I would have to edit for a *long* time with no syntax highlighting, no automatic file backup, no multi-buffer, etc.

Comment 8 Kamil Dudka 2015-01-26 10:41:02 UTC
(In reply to Don Swaner from comment #7)
> Invoking nano with the -I (ignore /etc/nanorc and ~/.nanorc) and with -G
> (set locking), I immediately got both errors at once (presumably the
> erroneous lockfile was previously created, before this nano session).

Did you clear all the stale lock files before trying it?

> The
> errors I have been referring to show up in the status bar of nano.  In the
> example that just occurred, the nano status bar reads:
> 
> File being edited (by nano 2.3., PID 28296, user dswaner), continue?        
> 
>  Y Yes
>  N No           ^C Cancel

This is more the locking feature itself.  By error I meant something like "Error deleting lock file ..." or ""Couldn't determine hostname for lock file ...".

> To reproduce the lock file not cleared problem (which only happens about 1%
> of the time) with only "set locking" option would be a major inconvenience -
> I would have to edit for a *long* time with no syntax highlighting, no
> automatic file backup, no multi-buffer, etc.

Good point.  The bug could be related to the "multi-buffer" feature of nano.

Do you also use the spell checking feature of nano?

Comment 9 Don Swaner 2015-01-26 11:56:42 UTC
> Did you clear all the stale lock files before trying it?

I don't know how to clear the stale lock files (since they are not kept in /var/lock).

> By error I meant something like "Error deleting lock file ..." or ""Couldn't determine hostname for lock file ...".

I have not gotten any error messages other than the locking feature info message.

> Do you also use the spell checking feature of nano?

I do use nano spell check and normally have that option turned on in .nanorc.

I have attached my usual .nanorc (minus comments).

Comment 10 Don Swaner 2015-01-26 11:59:42 UTC
Created attachment 984198 [details]
My usual .nanorc file less comments

Comment 11 Kamil Dudka 2015-01-26 12:08:00 UTC
(In reply to Don Swaner from comment #9)
> I don't know how to clear the stale lock files (since they are not kept in
> /var/lock).

They are created as hidden files (starting with dot) in the same directory as the file you are editing (assuming you have write permission for that directory).  For example, if you edit /tmp/file.txt, nano creates /tmp/.file.txt.swp as the corresponding lock file.

Comment 12 Kamil Dudka 2015-01-26 13:49:55 UTC
There seems to be an upstream fix available:

http://savannah.gnu.org/bugs/?42373

I will backport it for Fedora...

Comment 13 Kamil Dudka 2015-01-26 14:28:42 UTC
fixed in nano-2.3.6-5.fc22

Comment 14 Fedora Update System 2015-01-26 15:15:26 UTC
nano-2.3.4-5.fc21 has been submitted as an update for Fedora 21.
https://admin.fedoraproject.org/updates/nano-2.3.4-5.fc21

Comment 15 Fedora Update System 2015-01-27 03:05:05 UTC
Package nano-2.3.4-5.fc21:
* should fix your issue,
* was pushed to the Fedora 21 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing nano-2.3.4-5.fc21'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2015-1243/nano-2.3.4-5.fc21
then log in and leave karma (feedback).

Comment 16 Fedora Update System 2015-01-27 21:39:56 UTC
nano-2.3.4-6.fc21 has been submitted as an update for Fedora 21.
https://admin.fedoraproject.org/updates/nano-2.3.4-6.fc21

Comment 17 Fedora Update System 2015-02-01 00:25:57 UTC
nano-2.3.4-6.fc21 has been pushed to the Fedora 21 stable repository.  If problems still persist, please make note of it in this bug report.


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