Continue reading, if you want to create a .task-file for Linproman to run scripts on process- or systemevents on Linux:
Loading happens...⚓
- On programstartup (every file with extention .task in the directory you specified in Options»General will be loaded - not recursive)
- After clicking in Taskform's contextmenuentry "reload tasks"
Format⚓
It's just like other configfiles on your distribution or good 'ol inifiles:[section]
key=value
[processcondition[UID]]
key=value
If a key is missing, default values will be used, so you only need to write non-default values to the file.
Checkcycle⚓
The tasks will be linked (to processes with matching PID or Name) and checked on the regular program-update you defined in Options»General, so the ticks may or may not be seconds.
The program will check processconditions first, then system ones, then tasks ones (process- and system- and tasksconditions can be mixed in a task, but tasksconnections are intended to be used to connect tasks and not be mixed. Don't you dare to report a bug if you mixed all that stuff and got in a kind of a kerfuffle!
Main - [main]⚓
| Key | Type | Default | Explanation |
|---|---|---|---|
| name= | string | Error | Name for your task |
| description= | string | (empty) | Put a description here, if you need more informations to remember what it does |
| scriptpathname= | string | Error | Full path + filename to the script which should be executed when the conditions met |
| id= | int64 | -1 | If you want to connect this tasks with others give it a unique number to identify |
| enabled= | int(bool) | false | 1=task enabled; 2=task disabled (only value which can also be set in the GUI) |
| conditionconnection= | int | 0 | 0=and(all conditions must be true);1=or(one condition must be true) – value will always be set to 0 for taskconditions (because it would not make sense to or-connect tasks) |
| disableafterfiring= | int(bool) | false | 1=automatically disables the task after firing; 0=it won't do that |
| fired= | int(bool) | false | Will be set to 1 after firing by the program and written back to the taskfile |
| showintraymenu= | int(bool) | false | Show this task in trayicon's task-menu (for fast en/disable) |
[main]
name=example
description=I wonder if I will ever again read this...
scriptpathname=/script/path.name
enabled=1
Processconditions - [processcondition[UID]]⚓
UID = something unique (string or number). 2 or more sections with the same name would lead to kerfuffle (like destroying your fully armed and operational battle station).
It is possible to identify processes by ByPID or ByName+ByPath or ByWindowName.
| Key | Type | Default | Explanation |
|---|---|---|---|
| ByPID= | int(list of integers) | (empty) | Process will be identified by the PID; You can define multiple PID, separated by | |
| ByName= | string | (empty) | Processes will be identified by their name you can see in the treeview (case sensitive!) All processes with that name will be linked to that processcondition, but the condition itself will be matched against one of them (See HandleAll to alter this). |
| ByNameStrict= | int(bool) | false | If false: ByName must match a part of a processes' name, if true ByName must match exactly (like down to each character). |
| ByPath= | string | (empty) | If the name is not unique, you can add the path you can see in Processform (case sensitive!) |
| ByWindowName= | string | (empty) | Same as name, but for process' windowname (because it is slow only the following processes get their windowname allocated: java) (case sensitive!) |
| ByWindowNameStrict= | int(bool) | false | Same behaivior as the parameter for name. |
| ByCommandLine= | string | (empty) | Same as ByName/ByPath, but for process' commandline (for wine or some such) - The matching is done for the substring, so passing an "exe-name" would be enough (case sensitive!) |
| HandleAll= | int(bool) | false | Under normal circurstances (=false) conditions are checked against any of the matching id or name parameters. For example: If any of the processes killjimmy is using cpu above X, XTicks going up and the condition may become true. If this parameter is set to true, all processes must be using cpu above X, before Xticks going up and the condition will become true. |
| ignore_if_parent_same_named= | int(bool) | 1 | If the process has a parent with the exact same name it won't be linked - Use this for processes which spawn a lot of childs you don't want to handle (e.g. firefox, upscayl) |
| XTicks= | int32 | 1 | How many ticks (in a row) the value has to be met before the condition becomes true - Value cannot be less than 1 |
| condition= | string | (empty) | See in the conditions-section |
| value= | string(parsed to uint64) | 0 | You can enter integers or floats (Decimal separator depends on your systemconfiguration) You can add k, m,g or t to create bigger, readable values. Like "1,5g" which will be converted to 1,5 GiB (1024!) |
| script_parameters= | string | (empty) | Pass additional parameters to your script (PID will be passed automatically as 1st parameter) |
| resettrueticksafterwards= | int(bool) | 0 | If set to 1, the Xticks will be reset, if the condition gets true (to stop a continues row) |
example:
[processcondition0]
ByName=gnome-calculator
XTicks=10
condition=alive
Systemconditions - [systemcondition[UID]]⚓
(See about the UID up at processonditionpart)
Systemconditions can have the following same keys: XTicks=, resettrueticksafterwards=, condition=, value= and script_parameters= as processconditions, see documentation there for details. Of course the checkvalue and conditions are not against a process, but the whole system.
But it can also have specified keys:
| Key | Type | Default | Explanation |
|---|---|---|---|
| condition_IDparam= | int | -1 | If theres a specified (for example) battery you want to check put the ID here. If parameters missing in some cases all batteries or just one will be checked. |
example:
[systemcondition0]
XTicks=10
condition=cpu>
value=50
Conditions⚓
Processconditions check the condition against the process (for example how much CPU-percent the process uses), while the same action in a systemcondition would check how many CPU-percent the whole system uses.| Action | Explanation |
|---|---|
| Processconditions only: | |
| alive | true if process exists |
| js | true if process just started (Xticks will be ignored because it makes no sense here) - This only fires, if Linproman witness the creation of a process (so processes created before the applicationstart won't be handled as just created) |
| true if the process was brutally murdered (must have been alive for this to become true) | |
| Both: | |
| true | always true |
| false | always false |
| cpu> | true if cpu-use is above X percent |
| cpu< | true if cpu-use is below X percent |
| hddr> | true if devicereaddelta is above X bytes per tick |
| hddr< | true if devicereaddelta is below X bytes per tick |
| hddw> | true if devicewrittendelta is above X bytes per tick |
| hddw< | true if devicewrittendelta is below X bytes per tick |
| netr> | true if networkreceiceddelta is above X bytes per tick |
| netr< | true if networkreceiveddelta is below X bytes per tick |
| nets> | true if networkwrittendelta is above X bytes per tick |
| nets< | true if networkwrittendelta is below X bytes per tick |
| ram> | true if ramuse above X bytes |
| ram%> | true if ramuse above X percent |
| swap> | true if swapuse above X bytes |
| swap%> | true if swapuse above X percent |
| Systemconditions only: | |
| cput | true if CPU is below throttle-speed (Options»General) |
| batc | true if one of the bats is charging (or BATID) |
| batd | true if one of the bats is discharging (or BATID) |
| batf | true if one all the bats are full (or BATID) |
| bat%> | true if average level of all the bats are above X percent (or BATID) |
| bat%< | true if average level of all the bats are below X percent (or BATID) |
| batmode | true if your device is running on battery |
Taskconnections - [taskconnections]⚓
No numbers in the section, because only one should exists in a taskfile!
With the section taskconnection you can specify a list of task-ids which should be all true (or connection wouldn't make sense) before this task becomes true itself. It's for connecting tasks.
Linproman wont stop you combining this with process- and systemconditions, but that wasn't even tested once in development.
| Key | Explanation |
|---|---|
| idlist= | The list of the connected tasks separated by "|" |
example:
[taskconnections]
idlist=1|2|3|4
Full examples⚓
Move mediainfo-gui and g-earth (which spawning always on monitor 1 to monitor 2):[main]
name=Move wrong spawning windows
description=because they're programmed by Pakled
scriptpathname=/home/lilstinky/scripts/linproman/move_pid_2_mainmonitor.sh
enabled=1
conditionconnection=1
[processcondition0]
ByName=mediainfo-gui
condition=js
[processcondition1]
ByName=googleearth-bin
condition=js
script_parameters=googleearth
Kill Thunar if it is using to much cpu:
[main]
name=Stuck thunar
description=Thunar using all cpu: https://gitlab.xfce.org/xfce/thunar/-/issues/510
scriptpathname=/home/lilstinky/scripts/linproman/warn_n_kill.sh
enabled=1
[processcondition0]
ByName=thunar
condition=cpu>
XTicks=120
resettrueticksafterwards=1
value=10
script_parameters=thunar
Shut down or stand-by a system when CPU and network-traffic is below a value:
[main]
name=Stand-by lazy system
description=Sleep now!
scriptpathname=/home/lilstinky/scripts/linproman/standby.sh
enabled=1
disableafterfiring=1
[systemcondition0]
XTicks=300
condition=cpu<
value=10
[systemcondition1]
XTicks=300
condition=netr<
value=10k
[systemcondition2]
XTicks=300
condition=nets<
value=10k
End the "helper-apps" Evolution leaves in RAM on exit (*-source-registry, *-calendar-factory and *-addressbook-factory):
[main]
name=Cleanup after Evolution
description=End the nasty helper-apps Evolution leaves in RAM after it has ended
scriptpathname=/home/lilstinky/scripts/linproman/cleanup_evolutionstuff.sh
enabled=1
fired=0
[processcondition0]
ByName=evolution
ByNameStrict=1
HandleAll=1
resettrueticksafterwards=1
condition=dead
XTicks=10