0

I accidently seemed to close nano editor, and when I reopened against the file I was working on, I got a message the file was already being edited by my user and nano with a process ID.

I used ps and sure enough nano was still running in the background on the process ID cited as that which was locking the file.

Rusty on linux, I found kill but didn't read into it enough and used -9, which seemed remove the process buy left the file locked by nano with the same process ID as reported previously. It seems you are to stay away from -9 and use -15 DOH!

I had used ps again after the kill -9, and ps did not list nano and therefore did not list a process against nano. This seemed to suggest the kill -9 removed nano.

However, ps aux | grep nano seemed to report nano with a process ID different to the original and not related to the process ID that locked the file!?

I tried killing that new process ID, but kill -15 kept reporting the process ID did not exist. Each time I ran ps aux | grep nano it seemed the process ID for nano was incrementing by 2 that was not associated with the original process ID that was locking the file!?

I have tried rebooting my machine, but the file comes up locked by nano against its original process ID!? But ps again seems to report incrementally changing process ID not related to the process ID that is locking the file!?

How to I kill this zombie please? Or is it a zombie, as it does not appear to be marked Defunct?

The process ID still turns up using ps -o ppid= <Child PID> but just seems a child of bash (going by process ID)?

killall -15 nano can't find nano either!?

Is this as simple as fixing a file lock somewhere? I installed and ran lsof but it did not seem to pick of a file locked by the errant process ID!? Tried also find -inum from /home and /mnt etc to try to search for a file lock associated with the inode for the file, but found naught.

Running on a Raspberry Pi 3 by the way.

Asterion Daedalus
  • 3

1 Answers1

1

First, you can't kill a zombie process, it is already dead. Generally, you can ignore zombie processes. See Should I kill zombie process in my system? for details on why.

Second, you are probably not reading the output correctly. ps aux | grep nano will likely return the process id of the grep command in addition to any "nano" process running. If you only get one result, it will probably be just the grep, which you should ignore.

And when you try to kill it and it says it doesn't exist, that pretty much confirms you just tried to kill the grep that already finished. The process id is incrementing because you keep running new grep commands that show up. READ what you are finding, don't just kill it blindly.

Rebooting the machine doesn't clear the lock file, although it would clear any nano that might have been running along with any zombie processes. If you try to re-edit the file, nano should ask you if you want to edit the file anyway, so you should be able to clear the lock file with nano itself.

user10489
  • 2,081