Determine if process is running in the foreground

[tab1293]

Is there any way to determine if a process loaded with process.NewProcess(<pid>) is running in the foreground?

I am looking for similar functionality to what ps -O -p <pid> returns in the STAT column; if there is a + in that column then the process is running in the foreground.

[Lomanic]

This is not possible with gopsutil currently (python psutil doesn't seem to support that either).

If we implement a process.Background() function, we will probably return a ErrNotImplementedError (or a new errors.New("not implemented on Windows")) on Windows which doesn't have this concept at all.

[shirou]

gopsutil uses only a first chars on /proc/<pid>/status in linux. So other information like foreground/session leader is discarded.

This is because these status is very different on each platforms, like @Lomanic said. If you make a PR which can abstract these differences, we will merge it with many thanks.

[Lomanic]

From my research:

• getting foreground status with ps is as simple as checking if the result of ps -o stat= -p $PID has a + (useful for darwin and BSDs which don't have a procfs)
• GNU procps' ps (and in darwin's adv_cmds in ps/print.c) implements the + state by comparing tpgid and pgrp, which are available on Linux in /proc/$PID/stat at field 5 (pgrp/pgid) and 8 (tpgid ; see procfs' manpage).

I plan to implement this in the coming weeks if nobody does this in the mean time.

[shirou]

Thank you for researching @Lomanic .

I think adding a field to Process struct, something like string []substate is better. but if you have any other idea.

And, we can also define const instead of string.

const (
     SubStateSessionLeader = "session leader"
     SubStateForeground = "foreground"
)

[Lomanic]

I already implemented some process.Background functions, are you talking about instead adding a new process.SubState function that would return []string, err?

[shirou]

Oh, you already implemented! Great!

My idea was adding a new field to process struct and be return by using process.Status(). If so I think we can not change API just adding and we can handle more state such as process leader. But adding Background() method is good.

[Lomanic]

Indeed, the change you are suggesting (changing process.State() to return []string, err), that I agree with, will be a breaking change for the API (v3 then). I also find it better to use exported constants, for users to compare with, instead of just letters. It would reflect ps STAT column.

[shirou]

the change you are suggesting (changing process.State() to return []string, err)

Ah, you are right. forget about my previous comment. Then, process.Background() (bool, err) seems good for me.

I also find it better to use exported constants, ...(snip)

That's a good idea!

[Lomanic]

I added the API change to process.State to the v3 roadmap at #362, I think this should be implemented as it would reflect ps and would simplify the API (instead of having multiple functions, for each sub-state), plus it would read once the result of ps or /proc/$PID/stat(us) for better performance.