How to natively get process ID of an external program? lazarus / 32-Linux ---------------------------------------------------------------------- edvard · 2022-12-20 19:52 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 · 2022-12-20 20:26 You need to iterate through the process directories in /proc and check the name against either /proc//cmdline or /proc//exe. Once you have a match you also have the corresponding process ID. ---------------------------------------------------------------------- MarkMLl · 2022-12-20 20:29 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 · 2022-12-20 20:32 Quote from: PascalDragon on December 20, 2022, 09:26:24 pmYou need to iterate through the process directories in /proc and check the name against either /proc//cmdline or /proc//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. Quote from: MarkMLl on December 20, 2022, 09:29:00 pmYou 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 · 2022-12-20 20:47 Quote from: PascalDragon on December 20, 2022, 09:26:24 pmYou need to iterate through the process directories in /proc and check the name against either /proc//cmdline or /proc//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 · 2022-12-20 20:52 Quote from: MarkMLl on December 20, 2022, 09:29:00 pmYou 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 · 2022-12-20 20:59 You can use UniqueInstance (Windows/Linux). ---------------------------------------------------------------------- PascalDragon · 2022-12-20 21:01 Quote from: KodeZwerg on December 20, 2022, 09:59:03 pmYou 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 · 2022-12-20 21:15 Quote from: KodeZwerg on December 20, 2022, 09:59:03 pmYou 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 · 2022-12-21 08:02 Quote from: edvard on December 20, 2022, 09:52:55 pm*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. QuoteI'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 · 2022-12-21 10:29 Quote from: MarkMLl on December 21, 2022, 09:02:42 amSo 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. QuoteGenerally 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 · 2022-12-21 12:06 Quote from: edvard on December 21, 2022, 11:29:57 amAh, 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 · 2022-12-21 17:41 Quote from: edvard on December 20, 2022, 08:52:16 pm[…] 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 · 2022-12-21 18:55 Quote from: Kays on December 21, 2022, 06:41:26 pmDo 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 · 2022-12-22 08:23 Quote from: MarkMLl on December 21, 2022, 01:06:51 pm... 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. ---------------------------------------------------------------------- edvard · 2022-12-22 08:45 Quote from: Kays on December 21, 2022, 06:41:26 pmQuote from: edvard on December 20, 2022, 08:52:16 pm[…] 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). If by "control" you mean 'I started it running', then yes.  If you mean 'I am the super-user monitoring and controlling all functions of this particular piece of kit', then no, that's why I wrote a GUI to interface with it.  Either way, I must apologize for my naïve assumption that when a file shows up via 'ps -A' with a certain PID, that PID is stuck with it for life.  By "life" I mean "since the last time it was started".  Some folks apparently think it means something different.  Reading around the interwebs, it would seem that PID associations are as ephemeral as mayflies.  In common practice though, I have found 'ps' proven itself reliable enough that a 'kill' command to take down a wayward bit of software via its reported PID will do exactly what it says on the tin, fringe cases be damned. And with that, I must get back to my previously scheduled programming...