How to natively get process ID of an external program?

[edvard]

I have a Lazarus GUI program that is controlling an external command-line program. It's a bit messy, because basically I'm using Lazarus/FPC to write a new config file for the external program, then kill and re-start it so it picks up the new config.  Right now, the kill procedure looks like this:

Code: [Select]

procedure KillIt;

var
  s: ansistring;
  pid: integer;

begin
  RunCommand('pidof',['PROGRAM'],s);
  if s='' then exit;
  pid:= (StrToInt(trim(s)));
  fpkill(pid,2);
end.

I was previously running Kill with RunCommand instead of the FpKill bit because I didn't know any better, but found FpKill in the BaseUnix unit and to my delight, it actually works better.
My problem (maybe unwarranted?) is I find it awkward to constantly RunCommand external commands to do basic functions instead of using native methods (hence my preference for FpKill over RunCommand-ing the 'Kill' command), but I couldn't find any equivalent to 'pidof', or even 'ps -A | grep PROGRAM'.  I realize this may be just a personal annoyance, and doing things like this with RunCommand is completely acceptable, but I just wanted to make sure I wasn't missing anything.

Any suggestions?  Anything I missed in the BaseUnix documentation, or an equivalent somewhere else?

[PascalDragon]

You need to iterate through the process directories in /proc and check the name against either /proc/<pid>/cmdline or /proc/<pid>/exe. Once you have a match you also have the corresponding process ID.

[MarkMLl]

You should state your OS etc. in the body of your message, since as soon as you change your sig your question's context will be lost.

Noting that you've using Debian... in practice, I'd suggest looking up what you need in /proc since it is what ps etc. uses anyway, and if that pseudo-fs isn't mounted you've got Big Trouble :-) Generally speaking I think you can rely on the numbered entries in there, it's really things like network status which are candidates for being moved into /sys

MarkMLl

[Bogen85]

You need to iterate through the process directories in /proc and check the name against either /proc/<pid>/cmdline or /proc/<pid>/exe. Once you have a match you also have the corresponding process ID.

That is assuming Linux (where /proc is always mounted).

On the BSDs /proc is not mounted by default.

You should state your OS etc. in the body of your message, since as soon as you change your sig your question's context will be lost.

Agreed

Also, some change their preferences to not see signatures....

[edvard]

You need to iterate through the process directories in /proc and check the name against either /proc/<pid>/cmdline or /proc/<pid>/exe. Once you have a match you also have the corresponding process ID.

My first thought was that it was a bit roundabout, but at least can be done natively, then noticed @MarkMLi's point "it is what ps etc. uses anyway" so, not so roundabout then. Thanks!

[edvard]

You should state your OS etc. in the body of your message, since as soon as you change your sig your question's context will be lost.

Noting that you've using Debian... in practice, I'd suggest looking up what you need in /proc since it is what ps etc. uses anyway, and if that pseudo-fs isn't mounted you've got Big Trouble :-) Generally speaking I think you can rely on the numbered entries in there, it's really things like network status which are candidates for being moved into /sys

MarkMLl

*ahem*  This was posted in the "Linux" section of the forum.  Your suggestion would be entirely appropriate if I were posting in "General" or "Other", but eh, I'll take it either way and update my sig.  Also, I'm on Arch these days (it's been awhile since I've last posted here...) though it's annoying me and I just might go back to Debian soon, but I digress. 

I'm not aware of any Linux distro that doesn't mount /proc.  One would think that would break an awful lot of things...

[KodeZwerg]

You can use UniqueInstance (Windows/Linux).

[PascalDragon]

You can use UniqueInstance (Windows/Linux).

That only works if you control the source of the application as well, but edvard didn't say anything about that.

[edvard]

You can use UniqueInstance (Windows/Linux).

Hmmm... seems to only work on the program that is running, not to spin off a unique process of an external program.
Useful nevertheless; on another project I used SimpleIPC to probe for other instances of the same program and exit if one was found.  I'll check this out as perhaps a simpler solution.

[MarkMLl]

*ahem*  This was posted in the "Linux" section of the forum.  Your suggestion would be entirely appropriate if I were posting in "General" or "Other", but eh, I'll take it either way and update my sig.  Also, I'm on Arch these days (it's been awhile since I've last posted here...) though it's annoying me and I just might go back to Debian soon, but I digress. 

So in six months time you change your sig to Suse and the question's context is lost.

I'm not aware of any Linux distro that doesn't mount /proc.  One would think that would break an awful lot of things...

Generally speaking you can rely on its being mounted if the system is fully-initialised and running properly. In other cases, for example if you've done a single-user startup for recovery purposes, you can't rely on that.

MarkMLl

[edvard]

So in six months time you change your sig to Suse and the question's context is lost.

What context would be lost?  I posted in the "Linux" section of the forum.  Suse is Linux.  Arch is Linux.  Debian is Linux.  The program I'm coding and the external program I'm calling are exclusive to Linux, and I had hoped for solutions specific to Linux, particularly anything I may have missed from the "BaseUnix" unit.  Therefore, I did not think it necessary to state what operating system I was using when I'm asking a question specifically related to a Linux use case in the "Linux" section of the forum.  As I said before, it would have been entirely appropriate to identify my use case OS if I had posted the same question in the "General" section.  I would feel the same way if I were running Windows and was looking for an answer specific to Windows functionality, and had posted in the "Windows" section.  Please forgive me if my tone seems adversarial, I simply am not understanding the insistence that I make a statement that is entirely unnecessary and redundant in the context of posting my question in the very section of the forum set aside for questions specific to it.
Again, I digress... you and PascalDragon gave me the answer I needed and I am currently following that track. Thank you.

Generally speaking you can rely on its being mounted if the system is fully-initialised and running properly. In other cases, for example if you've done a single-user startup for recovery purposes, you can't rely on that.

MarkMLl

Ah, good point.  Back in the fuzzy reaches of my memory, I think I remember being aware of that, and in fact experienced it on one occasion where all I had was BusyBox and a Grub config accident.  No need for process IDs when your entire world is a single executable...

[MarkMLl]

Ah, good point.  Back in the fuzzy reaches of my memory, I think I remember being aware of that, and in fact experienced it on one occasion where all I had was BusyBox and a Grub config accident.  No need for process IDs when your entire world is a single executable...

Yes, and the extent to which you're likely to do that and the extent to which /proc is auto-mounted depends on the distro etc. Now /please/ look at this in the context of a question you've posted in public, which is now likely to be indexed by Google. However if somebody with the same question in a few years time follows the Google link to this forum what they'll see is not the sig that you used at the time, but the most recent that you've set.

However leaving that aside and still wanting- for some reason that eludes me- to be helpful :-) I'd suggest that a bad /proc mount has effects far wider than looking up a PID: as a specific example even if your network (as a kernel component) was running you'd be unable to use netstat since it relies heavily on /proc... I've not checked but suspect that the same would apply to a whole lot of routing etc. utilities.

The good side however is that the major per-process content of /proc (i.e. cmdline etc.) has a fair amount of consistency across different flavours on unix. So broadly speaking "refer to /proc" for that stuff is a fairly safe answer, provided that the less-experienced reader ** appreciates that this isn't implemented as a "real" directory full of "real" files but is a relatively efficient backdoor for extracting kernel information.

** By which I mean the admitted beginner getting here via Google in a year or so time.

MarkMLl

[Kays]

[…] an external command-line program. […]

Do you have control over this program? Because some applications use the pidfile pattern, i.e. the program (usually some kind of daemon) writes its PID to a known location (and later deletes the pidfile).

[MarkMLl]

Do you have control over this program? Because some applications use the pidfile pattern, i.e. the program (usually some kind of daemon) writes its PID to a known location (and later deletes the pidfile).

But even if you can locate the file, you typically have to check /proc to ensure that that PID is still associated with a plausible binary.

MarkMLl

[edvard]

...
Now /please/ look at this in the context of a question you've posted in public, which is now likely to be indexed by Google. However if somebody with the same question in a few years time follows the Google link to this forum what they'll see is not the sig that you used at the time, but the most recent that you've set.
...
MarkMLl

Oh dear me, I believe I've struck the problem.  I came here selfishly seeking answers for myself, not thinking of the poor hapless Googlers of the future.  *tsk tsk* My apologies, though my opinion still stands.
At least I didn't simply answer "Never mind, figured it out.  Thanks all!" with no supporting details.