Bug 1183320

I am not able to trigger the bug, neither I found anything obvious in the code that would cause it.

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.

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?)

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.

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".

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?

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.

(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?

> 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).

Created attachment 984198 [details]
My usual .nanorc file less comments

(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.

There seems to be an upstream fix available:

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

I will backport it for Fedora...

fixed in nano-2.3.6-5.fc22

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

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).

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

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.