Hi list.

Which function to use in Linux (if any) to get the process ID of a running process which is not mine. GetProcessID retrieves my own process ID. I'm using OpenProcess in Win

Antonio.

you can can the the /proc/xxx directories to find the process with the process-ID = xxx.

-Michael

You can use the ps command to list process status. Many option so try man ps or info ps for further information.

To get process info for other users you need root privilege, sudo ps should do that.

Also top will tell you the running processes and how much memory / cpu each is using. Use q to exit.

Ian

"pidof" is much more effective for it.

If I understand your question correct, you are asking for a lazarus function.
I don't think that exists.
But you can use the TProcess to execute a linux command and grab the output. Pidof will give you the processed of a specific program. Ps is much more multipurpose, and it does *not* requires you to be root. At leat not in RedHat/Centos

You can use the following command to find all processes for a specific user (using kmi as an example):
ps aux | grep -w ^kmi

/Kaj

Please use the same quoting convention as the messages you are responding to. The thread was already growing downwards, and adding a message to the top is inappropriate.

In my experience, using ps etc. is wrong since apart from the efficiency aspect it makes several assumptions:

i) That the ps binary is available.

ii) That the command-line options you need are universally implemented.

iii) That (at least in the case of Linux) the /proc filesystem is available.

I think that it's probably more portable to go straight to the values available in /proc, if you can't read them then it's unlikely that ps would show you much more.

Hi guys.

Thanks to all anyway for answering.
I've found two nice solutions to solve my problem. To be honest I've to mention that what my function receives a paramater which is a PID and the function has to check if that process is still running returning a value. Sorry for any misunderstanding. I agree that my question was ambigous from that point of view.

1. Look at /proc/<PID> as /proc has dr-xr-xr-x permissions, like if DirectoryExistsUTF8(Format('/proc/%d', [wPID])) then MessageDlg('OK', 'process is running', mtInformation, [mbOK], 0) else

     MessageDlg('OK', 'process is NOT running', mtError, [mbOK], 0);

2. use kill with signal 0
uses BaseUnix;
   if FpKill(wPID, 0) = 0 then
     MessageDlg('OK', 'FpPid process is running', mtInformation, [mbOK], 0)
   else
     MessageDlg('OK', 'FpPid process is NOT running', mtError, [mbOK], 0);

I guess that solution 2 is the best as it asks immediately the kernel. Antonio.

Mark Morgan Lloyd wrote

i) That the ps binary is available.

So be fair, I don't think I have ever come across a Linux distro that doesn't include the ps binary as standard. And I have used Linux since
1996. Even *BSD and *Solaris include the ps binary as standard too.

So I think it is quite safe to assume the ps binary will be available on a Linux system.

Graeme.

Mark Morgan Lloyd wrote

Please use the same quoting convention as the messages you are responding

to. The thread was already growing downwards, and adding a message to the top is inappropriate.

In my experience, using ps etc. is wrong since apart from the efficiency

aspect it makes several assumptions:

available.

I think that it's probably more portable to go straight to the values

available in /proc, if you can't read them then it's unlikely that ps would show you much more.

I have never seen a Linux or Unix system that did not have ps installed. Unless we are talking embedded systems or similar. Unix systems (Solaris, AIX, SCO ) do not have the /proc file system, at least it is not usable.
So living in a heterogeneous world I would prefer the ps, although I know the options (aux in this case) varies from system to system. Whatever works for the user and he/she finds easiest to use is the correct way ;-)

/Kaj

IMHO its easier and more straight forward to do the functionality of "pidof" directly in pascal code:

- do a loop with a findnext() to handle all directories within "/proc"
- in each of them test if a file "cmdline" exists
- read cmdline in a staring
- if this denotes the process you mean to access the directory name is the PID

-Michael

Michael Schnell wrote

IMHO its easier and more straight forward to do the functionality of

"pidof" directly in pascal code:

- do a loop with a findnext() to handle all directories within "/proc" - in each of them test if a file "cmdline" exists - read cmdline in a staring - if this denotes the process you mean to access the directory name is

the PID

All depending on what was the purpose.
I thought the goal was to find all processes owned by a specific user, but have now leaned this was not the case.
Using the /proc file system eliminate the need for a call to the underlying OS which is good.

/Kaj

Agreed.

The fact that these pesky command line arguments do differ may be an *ahem* argument to wrap up this functionality in an FPC library function so the user does not need to remember/fiddle with/update his code for the various differences and the code will run on e.g. OSX, Linux, Solaris, AIX without modifications.

... and if, for some reason, ps functionality is implemented in another way (e.g. no ps but /proc filesystem is available), obviously this library function could be extended...

Of course, this all depends on reliable OS detection etc, which, looking at earlier discussions here and going from experience, is not that easy either.

This way of solving the problem seems to be the best when the goal is to retrieve the PID of a given program. As the /proc directory is tidy coupled to the kernel it's probably the fastest
This is what I gonna implement for the second part of my development.

Antonio.

Graeme Geldenhuys hat am 13. September 2012 um 10:09 geschrieben:

Yes, but its parameters vary.

Mattias
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120913/682d5ee0/attachment.html>

Kaj Mikkelsen wrote

I have never seen a Linux or Unix system that did not have ps installed.

No, but I've seen it not working because /proc wasn't available- which gives you absolutely no advantage attempting to use ps compared with going to /proc directly (i.e. you get an unparseable error message from ps compared with a clear indication that there's nothing mounted on /proc).

Unless we are talking embedded systems or similar. Unix systems (Solaris, AIX, SCO ) do not have the /proc file system, at least it is not usable.

Wrong. I've got a terminal session connected to a Solaris 10 system on my desk at the moment (because I'm trying to debug some LOM issues), and /proc is fine. However, it's worth remembering that non-Linux implementations tend to have less in the /proc tree than Linux, and that the Linux kernel developers are trying to move towards this model.

I would say that Solaris appears not to have /proc/nnn/cmdline, I think the equivalent is in /proc/nnn/psinfo. Irrespective of which, I still think it's better practice to either go directly to /proc or to look for a portable library- I don't know whether there's a POSIX API for this in the same way that there's a POSIX-compliant capabilities library on top of the Linux/Solaris/etc. kernel.

Yes, but the ps parameters vary. I'm using this stuff in my FPC build script on Linux and Solaris.

Can anybody say what the xBSD situation is? What's in /proc/nnn ?

This time it is not a question but a solution to a problem which was quite boring.

Using the TProcess component to launch antother task, I ran in trouble when dealing with piped commands like 'ps -s | grep something' Got the solution:

   with TProcess.Create(nil) do try
     CommandLine := CmdLine.Text;
     Options := Options + [poWaitOnExit, poUsePipes, poStderrToOutPut];
     Execute;
     Memo1.Lines.LoadFromStream(Output);
   Finally
     Free
   End
CmdLine.Text := '/bin/sh -c ''ps -s | grep something'' '
THis works fine whatever the sh could be (I use bash)

Antonio.

This is also a fairly common requirement when a program leaves lock files in a directory or a unix-domain socket etc. in /tmp or ~

# ls -l /var/run/*ttyS*
-rw-r--r-- 1 root root 4 Sep 6 13:46 /var/run/mgetty.pid.ttyS11 -rw-r--r-- 1 root root 6 Sep 8 18:46 /var/run/mgetty.pid.ttyS6

I agree.

2012/9/13 Antonio Fortuny :

CmdLine.Text := '/bin/sh -c ''ps -s | grep something'' '

Now you additionally asume that:
* there exists /bin/sh (recent linux distros begin to move all that into /usr/bin/)
* there exists ps and grep in your path

Mattias Gaertner wrote

Yes, but its parameters vary.

Between Linux distros? I know they vary between FreeBSD, Solaris and Linux. But I think they are all the same on various Linux distros. The original poster specifically mentioned usage under Linux, so again I think he can safely use ps without problems in his environment.

Graeme.

Mark Morgan Lloyd wrote

Yes, but the ps parameters vary. I'm using this stuff in my FPC build script on Linux and Solaris.

Yes, they vary between Linux, Solaris and FreeBSD, but as far as I know, the do not vary between Linux distros. The original poster specifically mentioned his usage under Linux only.

Graeme.

They /definitely/ vary, although I'm not sure it's directly relevant to the OP's problem.

As an example, ps's --ppid option was introduced at v3 and I still have live systems around here running v2.

Graeme Geldenhuys hat am 13. September 2012 um 11:19 geschrieben:

Yes.
For examples some embedded Linux and chroot jails.

I know they vary between FreeBSD, Solaris and Linux. But I think they are all the same on various Linux distros. The original poster specifically mentioned usage under Linux, so again I think he can safely use ps without problems in his environment.

He might safely use them, if he knows his target platforms.

Mattias
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120913/fd0f0b65/attachment.html>

Antonio Fortuny wrote

This way of solving the problem seems to be the best when the goal is to retrieve the PID of a given program. As the /proc directory is tidy coupled to the kernel it's probably the fastest

Yep

This is what I gonna implement for the second part of my development.

You additionally might want to take a look at the C source code of "pidof". Happy open-sourcing :)

-Michael

Le 13/09/2012 11:19, Bernd a ?crit :

Well, yes. To be more precise, the library into which I'm currently working is always running into a classic Linux server like Ubuntu, OpenSuse, Debian, etc.
No embbedded linux at all (and it is not a target for my programs and libraries)
So yes, we assume that the programs are always facing a full Linux server. BTW, we have the same approach where the Windows servers are concerned.

In the above exmple ther is what it is; just an example. In the real world we are working in a less trivial way.

Antonio.

Mark Morgan Lloyd wrote

>Wrong. I've got a terminal session connected to a Solaris 10 system on my

desk at the moment (because I'm trying to debug some LOM issues), and /proc is fine. However, it's worth remembering that non-Linux implementations tend to have less in the /proc tree than Linux, and that the Linux kernel developers are trying to move towards this model.

I maintain SunOS 4, Solaris 7,8 and 9.
I am pretty sure /proc is very invalidated if it exists on the SunOS platform.
On newer version it requires root privileges.

/Kaj

Oh my god!
Yet another approach of ransacking the whole disk. This time just to get a process ID.
Is that state of the art software developement?
There is no other way doing it on Linux?

[Sigh] /proc is a special filesystem which the kernel uses to expose information about each process. Apart from the fact that it is mounted into the standard filesystem namespace, it has absolutely nothing to do with a physical disc.

Mark Morgan Lloyd wrote

[Sigh] /proc is a special filesystem which the kernel uses to expose information about each process. Apart from the fact that it is mounted into the standard filesystem namespace, it has absolutely nothing to do with a physical disc.

Okay.
Didn't know that.
If it's completely in memory then it makes sense.

And I've just fired up a Solaris 10 system:

-bash-3.00$ uname -a
SunOS pye-dev-09 5.10 Generic_118833-17 sun4u sparc SUNW,Sun-Fire-280R Solaris
-bash-3.00$ ls -l /proc/$PPID/fd
total 0
c--------- 1 root sys 13, 2 Sep 13 15:31 0
c--------- 1 root sys 13, 2 Sep 13 15:31 1
c--------- 0 root root 23, 1 Sep 13 15:38 10
p--------- 0 markMLl staff 0 Sep 13 15:33 11
c--------- 0 root root 23, 1 Sep 13 15:38 12
c--------- 1 root sys 13, 2 Sep 13 15:31 2
D--------- 1 root root 0 Sep 13 15:30 3
s--------- 0 root root 0 Sep 13 15:38 4
p--------- 0 markMLl staff 0 Sep 13 15:33 5
p--------- 0 markMLl staff 0 Sep 13 15:33 6
p--------- 0 markMLl staff 0 Sep 13 15:33 7
s--------- 0 root root 0 Sep 13 15:33 8
c--------- 0 root root 23, 1 Sep 13 15:38 9
-bash-3.00$ ls -l /proc/$PPID/path 2>/dev/null |grep a.out lrwxrwxrwx 1 markMLl staff 0 Sep 13 15:33 a.out -> /usr/lib/ssh/sshd

Now you'll obviously need elevated privileges to look at properties of processes that you're not related to, but in other cases /proc (or directly comparable resources) is available- otherwise where do you think things like ps get their info?

So if you want to trump that I suggest getting hold of a copy of Solaris 11 (or OpenIndiana or whatever it calls itself these days) and seeing what restrictions it adds (and then check out Lazarus on it and update any bits of http://wiki.lazarus.freepascal.org/Lazarus_on_Solaris that merit attention :-)

J?rgen Hestermann wrote

Okay. Didn't know that.

Everything in Linux can be access via "what looks like a file system". eg: com ports, printer ports, usb, sound card etc.

Graeme.

Afaik many haven't. They usually symlink 'ps' it to busybox, which implements basic info only.

In BSD /proc/<a pid> contains

[marcov at dragon ~]$ ls /proc/44539
cmdline ctl etype file map rlimit status [marcov at dragon ~]$

but afaik BSDs can turn /proc off, and this is commonly done so on servers.

/proc is only a SysV compatibility feature there,
most BSD-own tools work via other interfaces (like sysctl(3))

Turning it off is getting rarer though (probably linux converging).

There are even more borderline cases: things like unix-domain sockets (named pipes) exist as a named entity on disc, but once opened are simply a handle in memory.

It's also possible to do this on linux with sysctl (I've got some c source somewhere), but use of sysctl is strongly discouraged now (in favour of /proc).

Henry

Graeme Geldenhuys wrote

On 13/09/12 16:48, J?rgen Hestermann wrote:>> Okay.> Didn't know that. Everything in Linux can be access via "what looks like a file system". eg: com ports, printer ports, usb, sound card etc.

Not quite: network (e.g. Ethernet) interfaces and SCSI/USB devices that don't fit a known class have their own namespaces, and despite being shown by e.g. lsof sockets don't have names at all (but information about them might be exposed in /proc). I think that Plan-9 tries to associate absolutely everything with a name, and working from memory the same /might/ apply to curiosities like Helios.

Still it is at least one syscall to enumerate the dir and then 2-3 syscalls (open/read/close) to get a value. Not counting fileexists() which is probably another syscall.

Thanks Marco, very much worth knowing.

And on Windows NT based systems everything is an object :) [Note: I'm talking about the API exposed by the NT kernel here, not the WinAPI]

Regards,
Sven

Henry Vermaak wrote

On 13/09/12 17:04, Marco van de Voort wrote: but use of sysctl is strongly discouraged now (in favour of /proc).

There not even is a wrapper in glibc for sysctl, so you will need to call it directly via the Kernel interface.

Not really recommended ;-) ,

-Michael

J?rgen Hestermann wrote

Yet another approach of ransacking the whole disk.

/proc is not on a disk. It's a virtual file system that generates it's content only on request.

In Linux, "everything" is (accessible as if it were) a file (or a directory). This is a _good_thing_.

-Michael

J?rgen Hestermann wrote

If it's completely in memory then it makes sense.

In fact it does not even exist. It's just a standard (straight forward, well structured, programmer-friendly) way to access information.

-Michael

Though I don't want to suggest that syscall I have to state that by default FPC (at least on Linux) always uses the Kernel interface. :)

Regards,
Sven

Sven Barth wrote

Though I don't want to suggest that syscall I have to state that by default FPC (at least on Linux) always uses the Kernel interface. :)

I do know this, but this (RTL/LCL) is a "standard library" (like glib, though not dynamic). Doing direct syscalls in user code is not that nice.

-Michael

Yet another argument to create (a) function(s) in the RTL that encapsulates the entire sorry mess then, and supports Linux, OSX, Solaris, AIX...

and Windows. (Maybe using psxdll.dll?)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120914/116b1067/attachment.html>

Reinier Olislagers wrote

t encapsulates the entire sorry mess then, and supports Linux, OSX, Solaris, AIX...

This very obviously is impossible. But FPC-RTL and LCL always are an open source work in progress and at any time can easily be enhanced by any sensible function.

-Michael

Sorry, no idea what you're talking about there, especially the relationship between your first and second sentence.

Reinier Olislagers wrote

Sorry, no idea what you're talking about there, especially the relationship between your first and second sentence

Maybe I (not an English native speaker) misunderstood your wording. I understood your "entire" in a way that you wanted _all_possible_ system calls to be encapsulated in the RTL and LCL. But maybe you meant just the one functionality in question.

-Michael

Yes, you're right, I meant just the functionality in question.

Thanks,
Reinier

Yeah. Everybody doing his own parsing of system textfiles is *such* a good principle to build durable applications on *g*

Yeah. Everybody doing his own parsing of system textfiles is *such* a good principle to build durable applications on *g*

as far as the text files maintain their structure, well, indeed it is.

*g*

I think it was you who made the point earlier that doing this "the Linux way" takes multiple syscalls to enumerate the content of directories in the /proc or /sys tree. That's obviously valid criticism, but at the same time I'm not sure there's a better way to handle a complex structure with version- and system-specific elements (example: /proc/cpuinfo is grossly architecture-specific, even for basic things like counting the number of CPUs).

It might, I suppose, be possible to build something like the inifiles unit which could parse either the registry (in the case of Windows) or etc+proc+sys+sysctl in the case of unix, but this would be difficult on account of /proc and /sys being an unstructured mix of stuff defined by the architecture and stuff changing every nSec. I'm no registry fan, but at least it tries to keep things separate.

I wonder whether POSIX has anything instructive to say about this sort of thing?

You miss the point. The /proc structure for the most doesn't even address that since it often packs more than one value into one file.

In such it is worse than its direct competitor on Windows, the registry.

but this would be difficult on account of /proc and /sys being an unstructured mix of stuff defined by the architecture and stuff changing every nSec.

That was exactly the point of my reply to a msg that tried to glorify /proc.

I'm no registry fan, but at least it tries to keep things separate.

Indeed.

I wonder whether POSIX has anything instructive to say about this sort of thing?

No. Afaik only the per process part of /proc is standarized, and even then in an optional part.

Posix is rarely a solution into anything *nix. It is merely the rock bottom most common denomitor.

Marco van de Voort wrote

Yeah. Everybody doing his own parsing of system textfiles is *such* a good principle to build durable applications on *g* --

Haha,

Of course it is good that script file programmers can use standard text parsing methods to access system information. But Of course dedicated binary Kernel api calls for all this do exist for more sophisticated purposes.

Now any programmer can decide what to use when.

- Michael