Your suggestion to simply delete the *.pid file is reasonable. Since the process number in that .pid file stems from a session before the computer was turned off/restarted, that information is not valid anymore anyhow. After reboot of the computer, an entirely different process using the very same PID might run on your machine. Killing a process by PID without actually verifying and knowing what process you are killing (which the middle part of your answer suggests) is a bad advice.

Seconding the previous comment -- use ps to check the PID first, grepping for something distinctive in the name (like qpixel).

Monica Cellio‭ I had edited my post after he commented. more /home/istiak/ruby/qpixel/tmp/pids/server.pid (This will return that number then, I said to use that.) Otherwise, there's another equivalent code kill -9 $(more /home/istiak/ruby/qpixel/tmp/pids/server.pid)

@Istiak you misunderstand. My comment is NOT about knowing the number, it is knowing what the actual process is that is currently associated with that particular PID.

You seem to believe the PID must be associated with an already running instance of your server, because it is from a file with the file path /home/istiak/ruby/qpixel/tmp/pids/server.pid? But is it, though? When has the file been created/updated the last time? Is the information in that file still up-to-date? Is the process with the PID fom the server.pid file really the process you believe it to be? Instead of verifying and knowing, you seem to be content in following an unverified belief.

If in reality you actually checked the veracity of the PID in the server.pid file being associated with a currently running instance of the server, then your answer here unfortunately is missing this important step in your suggestion of killing a process solely based on a number that comes from some file...

elgonzo‭ I think you misunderstood something or, I misunderstood. I had said in my question that A server is already running. So, how can you say that is it, though? The problem occurred cause, the server is running (which I can't access). So, I have to kill that process/server otherwise, I can't start a new server (where I will have access). If a server is running in background than, I can't start new one. So, that will be up-to-date

You just quoted an error message that said "A server is already running". Error msg's uttered by some program are not infallible truth. Error messages can mislead, whether it is due to a mistakes/bugs in code or simply due to poor wording chosen for the msg by the developer. Note the point of my argument is to verify first before jumping to action and kill a process by some number. That would also include verifying the truthfulness and/or validity of the (intepreted) meaning of the error message

Does the error message ""A server is already running" really want to say that another server is already running, or is it rather a poor choice of words by the developer for conveying that it found some process running with this PID? Who knows... (i don't. Do you?)

To give you an illustrative example: .NET has an (in)famous exception error message that sometimes misleads inexperienced developers: "The process cannot access the file <filePath> because it is being used by another process." Sounds straightforward and absolutely clear, right? Except it isn't. As it happens from time to time, when confronted with this error, the inexperienced developer/user is unable to find another process accessing that file. Because there isn't in those cases. (1/2)

(2/2) So, why was that error message produced by .NET then, if there was no other process using that file? Because the wording of that error message was chosen poorly. What that error tries to convey is "There exist an open file handle on the file , preventing the file from being opened again". Now, that existing file handle might be from another process, but it might also be from the very same program/process that causes this error. Uh-oh...

What i am trying to say with my tangential story about .NET error messages: Don't trust error messages like they are God's words, especially if the actions decided based solely on the wording of some error messages could be ...um.. inconviencing ;-) (I mean, sure, if you feel like you can trust the error message, then trust the error message. But, still, that risk you take on your own shoulders and doesn't make the advice of killing a process just based on an unverified PID any better...)

Don't trust error messages like they are God's words Your sounds like, if compiler says that syntax error. Than, you say that Oh! the compiler is kidding. I am sure that there's no syntax error actually. Terminal works as a compiler also. A server is already running that's why I can't start new one. If that's not true than, compiler is broken or, rails is broken.

What? Terminal working as a compiler? Syntax errors? Compiler broken? Nothing of this relates to what i said nor the question or answer. At all. I don't really know what you are trying to tell. My apologies, but i can't make any sense of what you just said/wrote. Anyway, you do you. I don't want to tell you what you do on and with your machines. My first comment is more aimed at readers of your answer to not blindly following this specific advice without verifying their intended actions first.