Skip to content

Latest commit

 

History

History
executable file
·
58 lines (44 loc) · 1.71 KB

TRICKS.md

File metadata and controls

executable file
·
58 lines (44 loc) · 1.71 KB

System wide queue

You can set the $TS_SOCKET variable to the same name path for all your ts processes, and then they'll use the same socket for intercommunication. This means - single queue. You should be certain that any 'ts' can read/write to that socket, using chmod.

A queue for each resource

You can use $TS_SOCKET and aliases/scripts for having different queues for different resources. For instance, using bash: alias tsdisk='TS_SOCKET=/tmp/socket.disk ts' alias tsram='TS_SOCKET=/tmp/socket.ram ts' alias tsnet='TS_SOCKET=/tmp/socket.net ts'

You can also create shell scripts like this:

<< FILE ts2
#!/bin/sh
export TS_SOCKET=/tmp/socket-ts2.$USER
ts "$@"
>> END OF FILE ts2

Be notified of a task finished

In X windows, inside bash, after submitting the task, I use: $ ( ts -w ; xmessage Finished! ) &

Killing process groups

ts creates a new session for the job, so the pid of the command run can be used as the process group id for the command and its childs. So, you can use something like:

$ kill -- -`ts -p`

in order to kill the job started and all its childs. I find it useful when killing 'make's.

Limiting the number of ts processes

Each queued job remains in the system as a waiting process. On environments where the number of processes is quite limited, the user can select the amount of the maximum number of ts server connections to ts clients. That will be read from the environment variable TS_MAXCONN at the server start, and cannot be set again once the server runs:

$ ts -K     # we assure we will start the server at the next ts call
$ TS_MAXCONN=5 ts

Internally there is a maximum of 1000 connexions that cannot be exceeded without modifying the source code (server.c).