SSE2310/CSSE7231 — Semester 2, 2022
Assignment 3 (version 1.4)
Marks: 75 (for CSSE2310), 85 (for CSSE7231)
Weighting: 15%
Due: 6:00pm Friday 7th October, 2022
Specification changes are shown in red - version 1.0 to 1.1, blue - version 1.1 to 1.2,
green – version 1.2 to 1.3, magenta – version 1.3 to 1.4. Changes are summarised at the end of the document.
Introduction 1
The goal of this assignment is to demonstrate your skills and ability in fundamental process management and 2
communication concepts, and to further develop your C programming skills with a moderately complex program. 3
You are to create a program called jobthing, which creates and manages processes according to a job 4
specification file, and must monitor and maintain the status and input/output requirements of those processes. 5
The assignment will also test your ability to code to a programming style guide and to use a revision control 6
system appropriately. 7
CSSE7231 students will write an additional program, mytee which emulates some basic functionality of 8
the Unix tee command, as a further demonstration of your C programming, file and commandline handling 9
capabilities. 10
Student Conduct 11
This is an individual assignment. You should feel free to discuss general aspects of C programming and 12
the assignment specification with fellow students, including on the discussion forum. In general, questions like 13
“How should the program behave if 〈this happens〉?” would be safe, if they are seeking clarification on the 14
specification. 15
You must not actively help (or seek help from) other students or other people with the actual design, structure 16
and/or coding of your assignment solution. It is cheating to look at another student’s assignment code 17
and it is cheating to allow your code to be seen or shared in printed or electronic form by others. 18
All submitted code will be subject to automated checks for plagiarism and collusion. If we detect plagiarism or 19
collusion, formal misconduct actions will be initiated against you, and those you cheated with. That’s right, if 20
you share your code with a friend, even inadvertently, then both of you are in trouble. Do not post your 21
code to a public place such as the course discussion forum or a public code repository, and do not allow others 22
to access your computer – you must keep your code secure. 23
You must follow the following code referencing rules for all code committed to your SVN repository (not 24
just the version that you submit): 25
Code Origin Usage/Referencing
Code provided to you in writing this semester by
CSSE2310/7231 teaching staff (e.g. code hosted on Black-
board, posted on the discussion forum, or shown in class).
May be used freely without reference. (You must be able
to point to the source if queried about it.)
Code you have personally written this semester for
CSSE2310/7231 (e.g. code written for A1 reused in A3)
May be used freely without reference. (This assumes
that no reference was required for the original use.)
Code examples found in man pages on moss. May be used provided the source of the code is
referenced in a comment adjacent to that code. (Code
you have taken inspiration from must not be directly
copied or just converted from one programming
language to another.)
Code you have personally written in a previous enrolment
in this course or in another ITEE course and where that
code has not been shared or published.
Code (in any programming language) that you have taken
inspiration from but have not copied.
Other code – includes: code provided by teaching staff only
in a previous offering of this course (e.g. previous A1 solu-
tion); code from websites; code from textbooks; any code
written by someone else, or partially written by someone
else; and any code you have written that is available to
other students.
May not be used. If the source of the code is referenced
adjacent to the code then this will be considered code
without academic merit (not misconduct) and will be
removed from your assignment prior to marking (which
may cause compilation to fail and zero marks to be
awarded). Copied code without adjacent referencing will
be considered misconduct and action will be taken.
26
6959462-30065-6649710 Version 1.4
Uploading or otherwise providing the assignment specification or part of it to a third party including online 27
tutorial and contract cheating websites is considered misconduct. The university is aware of these sites and 28
many cooperate with us in misconduct investigations. 29
The course coordinator reserves the right to conduct interviews with students about their submissions, for 30
the purposes of establishing genuine authorship. If you write your own code, you have nothing to fear from this 31
process. If you are not able to adequately explain your code or the design of your solution and/or be able to 32
make simple modifications to it as requested at the interview, then your assignment mark will be scaled down 33
based on the level of understanding you are able to demonstrate. 34
In short - Don’t risk it! If you’re having trouble, seek help early from a member of the teaching staff. 35
Don’t be tempted to copy another student’s code or to use an online cheating service. You should read and 36
understand the statements on student misconduct in the course profile and on the school web-site: https: 37
//www.itee.uq.edu.au/itee-student-misconduct-including-plagiarism 38
Specification – jobthing 39
jobthing reads a job configuration from a file whose name is provided as a command line argument. It creates 40
processes and runs programs according to that specification, optionally connecting those processes’ standard 41
input and output either to files, or jobthing itself via pipes. jobthing then reads input from stdin, interpreting 42
that input as commands that cause various actions to be taken, such as sending strings to the other processes, 43
reporting on statistics and so on. jobthing must handle certain signals and take specific action upon receiving 44
those signals. 45
Full details of the required behaviour are provided below. 46
Command Line Arguments 47
jobthing has one mandatory argument – the name of the job specification file, and also accepts several optional 48
arguments. These arguments may appear in any order. 49
./jobthing [-v] [-i inputfile] jobfile 50
The optional -v argument, if supplied, puts jobthing into verbose mode, causing it to emit additional 51
debug and status information. Precise requirements are documented below. 52
The optional -i inputfile argument is the name of a file which will be used to provide input to jobthing 53
and its managed processes. If no inputfile is specified (i.e. the -i argument is not given), then jobthing 54
is to take input from stdin. (Note that -i and -v are valid input file names – any string after -i is to be 55
treated as an input file name.) 56
The jobfile argument specifies the name of a file from which job information is to be read. This format 57
is documented below. This argument is mandatory. 58
If the user provides invalid options, too few or too many command line arguments, including repeated 59
arguments (e.g. -v -v), then jobthing shall emit the following usage information to stderr, and exit with 60
return code 1: 61
Usage: jobthing [-v] [-i inputfile] jobfile 62
If the inputfile specified with the -i argument is unable to be opened for reading, then the following message 63
should be emitted to stderr and jobthing should exit with return code 3: 64
Error: Unable to read input file 65
This should be checked prior to attempting to open the job file. 66
jobthing basic behaviour 67
jobthing reads the job specification file provided on the command line, spawning child processes and executing 68
programs as required. In general, jobthing is required to maintain a constant process state, regardless of what 69
happens to those child processes and programs. For example, if a child process is killed or terminates somehow, 70
then, unless otherwise specified, jobthing is required to notice this, and re-spawn the job as required, up to 71
the maximum number of retries specified for each job. 72
6959462-30065-6649710 Version 1.4
Depending on the contents of the jobfile, each job created by jobthing may have its stdin and stdout 73
connected to a pipe (back to jobthing), or to a file on the filesystem. 74
Once jobthing has created the initial set of jobs, it is to take input either from stdin, or from the file 75
specified with the -i inputfile commandline argument, one line at a time. By default each input line should 76
be sent to each job to which jobthing has a pipe connection, however a line starting with the asterisk character 77
‘*’ will be interpreted as a command. 78
After sending the input text to each job, jobthing will then attempt to read a line of input from each 79
job (again, only those to which jobthing is connected by a pipe). Output received from jobs is emitted to 80
jobthing’s standard output. 81
Upon reading EOF from the input (stdin or the input file), jobthing shall terminate. 82
jobthing job parsing 83
The job file provided to jobthing is a text file, with one line per job. 84
85
If jobthing is unable to open the job file for reading, it is to emit the following message to stderr, and 86
exit with return code 2: 87
Error: Unable to read job file 88
Lines beginning with the ‘#’ (hash) character are comments, and are to be ignored by jobthing. Similarly, 89
empty lines (i.e. with no characters before the newline) are to be ignored. 90
91
All other lines are to be interpreted as job specifications, split over 4 separate fields delimited by the colon (‘:’) 92
character as follows 93
94
numrestarts:input:output:cmd [arg1 arg2 ...] 95
96
where each field has the following meaning or intepretation (where “empty” means a zero length string): 97
? numrestarts – specifies how many times jobthing shall start or restart this job if it terminates. 0 98
(zero) or empty implies that jobthing shall restart the job every time it terminates, 1 (one) means that 99
jobthing should attempt to launch the job once only upon startup – if it terminates it is not restarted. 100
Other integers are interpreted similarly. 101
input – empty implies that this job shall receive its standard input from a pipe connected to jobthing. 102
Otherwise, the named file is to be opened for reading and connected to this job’s standard input stream. 103
output – empty implies that this job shall send its standard output to a pipe connected to jobthing. 104
Otherwise, the named file is to be opened for writing (with flags O_CREAT | O_TRUNC and permissions 105
S_IWUSR | S_IRUSR) and connected to this job’s standard output stream. 106
cmd [arg1 arg2 ...] – the name of the program to be run for this job, and optional arguments to be 107
provided on the commandline to that program. Arguments are separated by spaces. Program names and 108
arguments containing spaces may be specified by enclosing them in double quotes. A helper function is 109
provided to make this easer, see the split_space_not_quote() function described on page 11. 110
Note: Individual job specifications are independent, and you do not need to consider if jobs might interact with 111
each other (e.g. sharing input or output files etc). We will only test job specifications that have predictable 112
and deterministic behaviour. 113
Note: The colon character has special meaning and will only appear in job files as a separator. You do not 114
need to consider, nor will we test for jobfiles that contain the colon character as part of a command name or 115
argument. 116
Note: See the split_line() function described on page 11 for an easy way to split the colon-delimited job 117
specifications. 118
119
Following are several sample jobfiles with explanatory comments:
# A job, running cat, stdin/stdout connected to jobthing. Only start 'cat' once
1:::cat
6959462-30065-6649710 Version 1.4
# A job, running cat, stdin/stdout connected to jobthing. Start 'cat' a maximum of 5 times
5:::cat
# A job, running cat, stdin/stdout connected to jobthing.
# retries = 0 -> re-launch cat every time it terminates, no limit
0:::cat
# A job, running cat, take stdin from /etc/services, send stdout to foo.txt.
# Only run 'cat' once
1:/etc/services:foo.out:cat
# A job, running cat, take stdin from /etc/services, stdout connected back to jobthing
# Only run 'cat' once
1:/etc/services::cat
# two jobs, both running cat, stdin and stdout connected to jobthing.
# The first job runs cat only once, the second will restart it forever as required
1:::cat
0:::cat
If verbose mode is specified, for each valid job line read from the jobfile, jobthing should emit the following 120
output to its stdout 121
Registering worker N: cmd arg1 arg2 ... 122
where 123
N is the replaced with job number, incrementing from 1 (one) 124
cmd is the command to be run, and arg1, arg2, ... are any arguments provided to the command. Note 125
that there should be a single space between cmd and any arguments, and there should be no trailing space 126
on this line of output 127
The following is an example of such output: 128
Registering worker 1: cat
Registering worker 2: tee logfile.txt
A job line in the jobfile is invalid if any of the following conditions are met: 129
There are not precisely 4 fields separated by colons 130
The integer value first field (numrestarts) is not a proper, non-negative integer (if not empty) 131
The cmd field in the job line is empty or starts with a space 132
Invalid job lines are to be ignored and are not given job numbers. Further, if verbose mode is specifed on 133
the command line, then jobthing shall emit the following to its stderr: 134
Error: invalid job specification: 135
where is replaced by the offending job specification line, e.g. 136
Error: invalid job specification: -10:0:foobar baz 137
6959462-30065-6649710 Version 1.4
jobthing startup phase 138
Once the jobfile has been read, jobs are to be created in the order they were specified in the job file. 139
? If an input file is specified for the job, jobthing shall attempt to open that file in read mode and the 140
job is to have its stdin redirected from that file. Otherwise, jobthing shall create a pipe, connecting 141
that job’s stdin to the reading end of the pipe, with jobthing holding the write end of the pipe through 142
which it will later send information. 143
Similarly, if an output file is specified for the job, jobthing shall attempt to open that file in for writing and 144
the job is to have its stdout redirected to that file. Otherwise, jobthing shall create a pipe, connecting 145
that job’s stdout to the writing end of the pipe, with jobthing holding the read end of the pipe through 146
which it will later receive information. 147
If a job has an input file specified, and that file cannot be opened, jobthing shall emit the following message 148
to stderr. The job shall be considered invalid unrunnable and no further handling or respawn attempts shall 149
be made for that job. (If an output file is also specified, no attempt shall be made to open it.) 150
Error: unable to open "" for reading 151
where is the name of the file from the job specification. 152
Similarly, if an output file is specified and cannot be opened for writing, the job is considered invalid 153
unrunnable, no further processing or spawn attempts are made, and jobthing shall emit to stderr: 154
Error: unable to open "" for writing 155
Once any input and output files and pipes are opened/created, jobthing shall spawn a new process for 156
each runnable job, connect the stdin and stdout of the new job as required, and then exec the command line 157
specified for the job. 158
If verbose mode is specified, then jobthing should emit the following to its stdout: 159
Spawning worker N 160
where N is replaced by the job number. 161
162
Important: jobthing shall ensure that all un-used file handles are closed before executing the job process. 163
That is, the job shall have only its standard input, output and error file handles open. (Standard error is just 164
to be inherited from jobthing.) Test scripts will check to ensure that no other file handles leak from jobthing 165
to individual jobs. 166
If the child’s exec call fails, the child process is to call _exit() with the return code 99. jobthing is not 167
expected to detect a failure to exec (e.g. such jobs don’t become unrunnable) – this is treated exactly the same 168
as a successful child execution where the child immediately returned exit status 99. 169
jobthing operation and command format 170
Once jobthing has started the jobs, it should sleep for one second and then enter an infinite loop (terminated 171
only by reading EOF on its input stream (stdin or the supplied input file) or by running out of viable workers 172
– see descriptions below). 173
Each time through the loop jobthing shall perform the following operations, in the exact order specified 174
below. 175
Note: Any jobs that were marked invalid unrunnable during the startup phase (i.e. because their input or 176
output files could not be opened) are excluded from all handling during this main loop. 177
1. Check on the status of each job (in the order they were specified in the job file), report on any jobs that 178
have terminated, and restart those which need to be restarted. 179
? for any jobs that have terminated since the last check, jobthing shall generate a line of output to 180
stdout in the following format: 181
Job N has terminated with exit code M 182
or 183
Job N has terminated due to signal S 184
depending on the reason for the job terminating. N, M and S should be substituted by the job number, 185
exit code or signal number as appropriate. 186
6959462-30065-6649710 Version 1.4
close and clean up any pipes and file descriptors associated with communication to the terminated 187
job 188
for each job that has terminated, if the total number of times it has been (re-)started is less than the 189
maximum number specified in the job file, then the job shall be restarted in exactly the same way it 190
was started (including input/output file redirection/pipes as required). Note that it is possible that 191
a respawning might not be possible due to the inability to open an input or output file for reading 192
or writing (even though that succeeded for an earlier run). In this case, jobthing should print the 193
same error message as specified above (see “jobthing startup phase”) and make no further attempts 194
to respawn that job – i.e. the job becomes unrunnable. If the job is restarted and verbose mode is 195
specified, then jobthing shall emit the following to its stdout: 196
Restarting worker N 197
where N is replaced by the job number. 198
If a job has already been restarted the maximum number of times, then it should not be restarted – 199
the job is now unrunnable. 200
2. If jobthing determines that there are no jobs running and no further possible jobs left to (re)launch (all 201
jobs are unrunnable), then it shall emit the following message to stderr, and exit with exit code 0 (zero): 202
No more viable workers, exiting
Reasons for this are 203
No jobs remain with a non-zero restart count remaining 204
No jobs remain that have valid input or output redirection files 205
3. Read a line of input from stdin or the specific jobthing input file, and process it as a command according 206
to the following requirements: 207
If EOF is detected, then jobthing shall exit with exit status 0 (zero). 208
Lines beginning with the asterisk ‘*’ character are treated as commands – see below for details. After 209
processing the command, jobthing shall sleep for 1 second and then return to the top of the main 210
loop, checking job status again etc. (The same sleep/return applies to invalid commands also – in 211
this case the “processing” of the command means outputting an error message as described below.) 212
Any other lines are sent as-is to each job to which jobthing has a connection (i.e. a pipe exists 213
between jobthing and the job’s stdin). 214
Data sent to each job is to be echoed to jobthing’s stdout in the following format: 215
ID<-’text’ 216
where ID is the job ID (starting from one), and ’text’ is the line of input sent to the job, surrounded 217
by single quotes. 218
4. jobthing shall sleep for 1 second 219
5. jobthing shall attempt to read exactly one line of input from each job to which it has a pipe connected 220
to that job’s stdout. Each line of output received from each job shall be emitted to jobthing’s stdout 221
as follows: 222
ID->’text’ 223
where ID is the job ID (starting from one), and ’text’ is the line of output received from the job, 224
surrounded by single quotes. It is expected that jobs will have a line of output available. If a job fails to 225
send such a line it is acceptable for jobthing to block until such time as a line is returned (or EOF is 226
detected). If EOF is detected, no message is output unless verbose mode is enabled. If verbose mode is 227
enabled then jobthing should output the following to stderr: 228
Received EOF from job N 229
where N is replaced by the job number. 230
6. Otherwise, jobthing shall repeat the loop starting back at Step 1 above. 231
NOTE: it is critical that you do these actions in this order, otherwise your program will behave differently and 232
fail many tests. 233
6959462-30065-6649710 Version 1.4
jobthing signal handling requirements 234
Upon receiving SIGHUP, jobthing is to emit to its stderr statistics on the history and status of each valid job 235
that was specified in the jobfile. Each line of the statistics report is of the format 236
237
jobnum:numstarts:linesto 238
where each field has the following interpretation: 239
jobnum – the number of the job, starting from one which is the first valid job in the provided jobfile 240
numstarts – how many times jobthing has attempted to start or restart the job, including the initial 241
process creation upon startup 242
linesto – how many lines of input jobthing has sent to the job. Jobs whose stdin is read from a file 243
(rather than a pipe from jobthing) will report 0 (zero). 244
Note that the statistics for any given job accumulate over multiple restarts – if a job is terminated and 245
respawned multiple times, the total number of lines sent to it over the lifetime of jobthing is reported. 246
jobthing shall block or otherwise ignore SIGINT (Control-C). 247
248
jobthing must gracefully handle the possibility that it attempts to write information down a pipe to a job that 249
has terminated. If this occurs, jobthing shall silently ignore this fact, and the terminated job and associated 250
pipes should be cleaned up as per normal processing, with the job being restarted if appropriate. 251
We will not test whether system calls are restarted following a signal – e.g. a sleep resulting from a *sleep 252
command can be shorter than expected if interrupted by a signal or can be resumed – either is acceptable. 253
jobthing command handling 254
The following table describes the commands that must be implemented by jobthing, and their syntax. Addi- 255
tional notes on each command will follow. 256
Command Usage Comments
*signal *signal jobID signum Send the signal (signum – an integer) to the given job(jobID).
*sleep *sleep millisec Sleep for millisec (an integer) milliseconds.
257
Any invalid commands provided to jobthing (i.e. a command word starting with ‘*’ is invalid), shall 258
result in the following message to stdout: 259
Error: Bad command 'cmd'
where ’cmd’ is the offending command enclosed in single quotes. (cmd is the text after the ‘*’ up until 260
the first space or newline – and may be an empty string.) 261
if the command is not provided the correct number of arguments, the following is emitted to stdout 262
Error: Incorrect number of arguments
All numerical arguments, if present, must be complete and valid numbers. e.g. “15” is a valid integer, but 263
“15a” is not. Your program must correctly identify and report invalid numerical arguments (see details 264
below for each command). Leading whitespace characters are permitted, e.g. “ 10” is a valid number – 265
these whitespace characters are automatically skipped over by functions like strtol() and strtod(). 266
Any text arguments, including strings and program names, may contain spaces if the argument is surrounded 267
by double quotation marks, e.g. "text with spaces". A line with an odd number of double quotes will 268
be treated as though there is an additional double quote at the end of the line1. A helper function is 269
provided to assist you with quote-delimited parsing, see the “Provided Library” section on page 11 for 270
usage details. 271
1This will not be tested
6959462-30065-6649710 Version 1.4
*signal 272
The *signal command shall cause a signal to be sent to a job. Exactly two integer arguments must be specified 273
– the target job ID, and the signal number. 274
If the job ID is invalid, your program should emit the following to stdout: 275
Error: Invalid job
Reasons for a job number being invalid are: 276
an invalid integer, e.g. “23a” 277
an invalid job number (less than 1, greater than the total number of jobs) 278
the specified job is unrunnable has terminated or is otherwise invalid (reached maximum number of 279
restarts, input or output files could not be opened) 280
If the signal number is invalid (non-numeric, less than 1 or greater than 31) then your program should emit 281
the following to stdout: 282
Error: Invalid signal
If all arguments are valid, the signal shall be sent to the targetted job. (There is no need to check whether 283
the job is still running when the signal is actually sent.) 284
*sleep 285
The *sleep command shall cause jobthing to sleep for the specified number of milliseconds. Exactly one 286
non-negative integer argument must be provided. 287
If the sleep duration value is invalid (not a properly formed integer, or a negative value), your program 288
should emit the following to stdout: 289
Error: Invalid duration
If the arguments are valid, jobthing shall sleep for the required duration (in milliseconds). 290
Example jobthing Sessions 291
In this section we walk through a couple of increasingly more complex examples of jobthing’s behaviour. Note 292
however that these examples, like provided test-cases, are not exhaustive. You need to implement the program 293
specification as it is written, and not just code for these few examples. 294
Consider a config file once_cat.txt with following contents: 295
1 1:::cat
This defines a single job, running cat, to be launched once only, and stdin and stdout connected via pipes 296
to jobthing. We launch jobthing in verbose mode and interact with the job in some simple ways. Note that 297
text formatted in bold is entered and echoed on the terminal, it is not output of jobthing itself. 298
1 $./jobthing -v once_cat.txt
2 Registering worker 1:cat1: cat
3 Spawning worker 1
4 hello there
5 1<-'hello there'
6 1->'hello there'
7 this is some text
8 1<-'this is some text'
9 1->'this is some text'
Thus we see simple job startup, and text passing to and from the job. Next we can explore the *signal 299
command (continuing the same session): 300
6959462-30065-66497108 Version 1.4
10 *signal 0 11
11 Error: Invalid job
12 *signal 1 45
13 Error: Invalid signal
14 *signal 23a 45
15 Error: Invalid job
16 *signal 1 9
17 WorkerJob 1 has terminated due to signal 9
18 No more viable workers, exiting
Here after several invalid *signal command attempts, we finally send signal 9 to worker 1, which causes 301
its termination. jobthing then determined that this job should only be launched once, and that with no more 302
viable runnable jobs to run it terminates. 303
We next consider job input and output redirection, with the file cat_once_in_out.txt: 304
1 1:/etc/services:./foo.out:cat
This job file runs a single job, cat, but it takes its standard input from /etc/services, and redirects its 305
output to ./foo.out. It runs only once. 306
Launching this job, in verbose mode, we see the following: 307
1 Registering worker 1: cat
2 Spawning worker 1
3 WorkerJob 1 has terminated with exit code 0
4 No more viable workers, exiting
In this example, we see that the process was spawned, but because its input was redirected from a file, the 308
cat process ran to completion almost immediately. This was detected by jobthing, which identified that no 309
further restarts should be attempted, and that no runnable jobs remained, so the program exits without pausing 310
for any user input. 311
Let’s now consider a more complex example, with multiple processes and different run counts. The example 312
configuration file is mixed_multicat.txt: 313
1 0:::cat
2 1:::cat
3 2:::cat
Here we have three jobs, all to run cat with their stdin and stdout connected via pipes to jobthing, 314
however each has a different number of restarts: zero (i.e. re-start endlessly), 1, and 2. 315
1 $./jobthing -v mixed_multicat.txt
2 Registering worker 1: cat
3 Registering worker 2: cat
4 Registering worker 3: cat
5 Spawning worker 1
6 Spawning worker 2
7 Spawning worker 3
8 Hello
9 1<-'Hello'
10 2<-'Hello'
11 3<-'Hello'
12 1->'Hello'
13 2->'Hello'
14 3->'Hello'
Entering a single line of input (’Hello’) has it sent to each job in turn, then that same string is returned 316
from each job by the cat process. 317
We then kill job number 2, and send some more input: 318
15 *signal 2 9
16 WorkerJob 2 has terminated due to signal 9
6959462-30065-6649710 Version 1.4
17 Hello again
18 1<-'Hello again'
19 3<-'Hello again'
20 1->'Hello again'
21 3->'Hello again'
Here we see that job 2 was terminated and not restarted (its restart count was only 1), and that the 319
subsequent input (Hello again) was then only sent to remaining live jobs (1 and 3). Let’s send a signal to job 320
number 3, and send some more input: 321
22 *signal 3 11
23 WorkerJob 3 has terminated due to signal 11
24 Restarting worker 3
25 foobar
26 1<-'foobar'
27 3<-'foobar'
28 1->'foobar'
29 3->'foobar'
And again: 322
30 *signal 3 11
31 WorkerJob 3 has terminated due to signal 11
32 baz
33 1<-'baz'
34 1->'baz'
After the second signal, worker 3 has finally terminated and not restarted, and the input entered at the 323
console is sent only to worker 1. Since worker 1 has a restart count of zero (restart forever), we can send it as 324
many signals as we like, it will continue being restarted: 325
35 *signal 1 5
36 WorkerJob 1 has terminated due to signal 5
37 Restarting worker 1
38 *signal 1 6
39 WorkerJob 1 has terminated due to signal 6
40 Restarting worker 1
41 still there?
42 1<-'still there?'
43 1->'still there?'
Finally, let’s send SIGHUP to jobthing, and see the statistics reporting: 326
44 1:cat:2:4 1:3:5
45 2:cat:1:1 2:1:1
46 3:cat:2:3 3:2:3
Here we can see how many times each job was restarted (including expired ones like jobs 2 and 3), and how 327
many lines of input were sent to each. 328
Specification - mytee (CSSE7231 students only) 329
CSSE7231 students are to write an additional program, called mytee. mytee reads