Timekpr-nExT

Custom kill action for some playtime activities

Asked by Alexis R

Hello,

I would like to know if there is a way to have a special action to kill some playtime activities, or if there is anything I can do to help to implement this feature.

The context: The game "0 A.D." in a flatpak is not killed at the end of the playtime. The game seems to launch 3 processes. One of them is ``bwrap --args <fd-number> 0ad`` and ``kill <PID>`` does not kill the process. You need to send ``kill -9 <PID>``. However, the good solution here is ``flatpak kill com.play0ad.zeroad``. This will properly kill the three processes and clean up their (flatpak managed) containers.

So... I would like to have a way to specify the command to run to kill a particular activity at the end of playtime.

Any suggestions?

Thanks a lot!

Question information

Language:
English Edit question
Status:
Solved
For:
Timekpr-nExT Edit question
Assignee:
Eduards Bezverhijs Edit question
Solved by:
Eduards Bezverhijs
Solved:
Last query:
Last reply:
Revision history for this message
Eduards Bezverhijs (mjasnik) said (last edit ): 		#1

I rechecked the code and it is already using SIGKILL (-9) for 4th time trying to kill the process.

Terminate and kill events are written to logfile, so please send me the logfile or if you are technical user, please check whether the processes which are being terminated actually include the one you need.

Another thing is that timekpr only kills processes for that particular user, if that flatpack app has different user, it may not even pick up that process for kill.
If your user runs that game, do the accounted process count increases or stays at 0? This can be seen under timekpr “icon”, administration app or you can get matched process count using CLI.

Revision history for this message
Eduards Bezverhijs (mjasnik) said (last edit ): 		#2

In essence timekpr does not care or distinguish flatpak, snap or any other process origins, it just checks whether commandline matches the mask and then tries to terminate / kill that pid when the time is due.
Timekpr politely asks process to terminate 3 times with a pause of 3 sec in between, if process is rather stubborn and does not give up, 4th time is the killing time.

Providing custom command is not straightforward, some apps are native, some are flatpak, some are snap and so on, there is no common native kill command for all types of different process origins except the universal and standard OS kill.
So that’s what timekpr uses.

Revision history for this message
Alexis R (alexisreyn) said : 		#3

I looked at the log file and indeed the process ``bwrap --args 40 0ad`` does not appear. My “process mask” is ``0ad`` and I have “Enhanced activity monitor” enabled. Is there anything I haven't understood? Should the beginning of the process mask match start at the beginning of the executable name?
Thank you

Revision history for this message
Best Eduards Bezverhijs (mjasnik) said (last edit ): 		#4

You need to put in regexp for this, based on what you provided the correct one will be ``.*0ad.*``, then everything that contains 0ad will be killed.

Standard PT mode will search just for executable name, like if you enter ``0ad`` it will look for executable `` 0ad``, enhanced looks for regexp in FULL commandline.

In your case for ``bwrap --args 40 0ad`` , executable is ``bwrap`` so it will never match ``0ad``, on the other hand regexp ``0ad`` will not match anything either, because it is the name without a pattern and you do not have a process commandline exactly like that.
``.* 0ad.*`` will help, because it means any characters before 0ad, then 0ad and then any characters after it.

Revision history for this message
Alexis R (alexisreyn) said (last edit ): 		#5

Is it because the regex has to match the entire command?

Revision history for this message
Eduards Bezverhijs (mjasnik) said : 		#6

I edited previous comment and added an explanation.

Revision history for this message
Alexis R (alexisreyn) said : 		#7

Thanks Eduards Bezverhijs, that solved my question.

Revision history for this message
Alexis R (alexisreyn) said : 		#8

Many thanks!