Introduction

The goal of this assignment is to demonstrate your skills and ability in fundamental process management and

communication concepts, and to further develop your C programming skills with a moderately complex program.

You are to create a program called  jobthing,  which creates and manages processes according to a job specification file, and must monitor and maintain the status and input/output requirements of those processes.

The assignment will also test your ability to code to a programming style guide and to use a revision control

system appropriately.

CSSE7231 students will write an additional program, mytee which emulates some basic functionality of the Unix tee command, as a further demonstration of your C programming, file and commandline handling capabilities.

Student Conduct

This is an individual assignment. You should feel free to discuss general aspects of C programming and the assignment specification with fellow students, including on the discussion forum. In general, questions like “How should the program behave if (this happens)?”  would be safe, if they are seeking clarification on the specification.

You must not actively help (or seek help from) other students or other people with the actual design, structure and/or coding of your assignment solution. It is cheating to look at another student’s assignment code and it is cheating to allow your code to be seen or shared in printed or electronic form by others . All submitted code will be subject to automated checks for plagiarism and collusion. If we detect plagiarism or collusion, formal misconduct actions will be initiated against you, and those you cheated with. That’s right, if you share your code with a friend, even inadvertently, then both of you are in trouble.  Do not post your code to a public place such as the course discussion forum or a public code repository, and do not allow others to access your computer – you must keep your code secure.

You must follow the following code referencing rules for all code committed to your SVN repository (not just the version that you submit):

Uploading or otherwise providing the assignment specification or part of it to a third party including online tutorial and contract cheating websites is considered misconduct.  The university is aware of these sites and many cooperate with us in misconduct investigations.

The course coordinator reserves the right to conduct interviews with students about their submissions, for the purposes of establishing genuine authorship. If you write your own code, you have nothing to fear from this process.  If you are not able to adequately explain your code or the design of your solution and/or be able to make simple modifications to it as requested at the interview, then your assignment mark will be scaled down based on the level of understanding you are able to demonstrate.

In short -  Don’t  risk  it!  If you’re having trouble,  seek help early from a member of the teaching staff.

Don’t be tempted to copy another student’s code or to use an online cheating service.  You should read and

understand the statements on student misconduct in the course profile and on the school web-site: https: //www.itee.uq.edu.au/itee-student-misconduct-including-plagiarism

Specification – jobthing

jobthing reads a job configuration from a file whose name is provided as a command line argument. It creates processes and runs programs according to that specification, optionally connecting those processes’ standard input and output either to files, or jobthing itself via pipes. jobthing then reads input from stdin, interpreting that input as commands that cause various actions to be taken, such as sending strings to the other processes, reporting on statistics and so on. jobthing must handle certain signals and take specific action upon receiving those signals.

Full details of the required behaviour are provided below.

Command Line Arguments

jobthing has one mandatory argument – the name of the job specification file, and also accepts several optional arguments. These arguments may appear in any order.

./jobthing  [-v]  [-i  inputfile]  jobfile

●  The optional -v argument, if supplied, puts jobthing into verbose mode, causing it to emit additional debug and status information. Precise requirements are documented below.

●  The optional -i  inputfile argument is the name of a file which will be used to provide input to jobthing and its managed processes. If no inputfile is specified (i.e. the -i argument is not given), then jobthing is to take input from stdin

●  The jobfile argument specifies the name of a file from which job information is to be read. This format is documented below. This argument is mandatory.

If the user provides invalid options, too few or too many command line arguments, jobthing shall emit the following usage information to stderr, and exit with return code 1:

Usage:  jobthing  [-v]  [-i  inputfile]  jobfile

If the inputfile specified with the -i argument is unable to be opened for reading, then the following message should be emitted to stderr and jobthing should exit with return code 3:

Error:   Unable  to  read  input  file

This should be checked prior to attempting to open the job file.

jobthing basic behaviour

jobthing reads the job specification file provided on the command line, spawning child processes and executing programs as required. In general, jobthing is required to maintain a constant process state, regardless of what happens to those child processes and programs. For example, if a child process is killed or terminates somehow, then, unless otherwise specified, jobthing is required to notice this, and re-spawn the job as required, up to the maximum number of retries specified for each job.

Depending on the contents of the jobfile, each job created by jobthing may have its stdin and stdout connected to a pipe (back to jobthing), or to a file on the filesystem.

Once jobthing has created the initial set of jobs, it is to take input either from  stdin, or from the file

specified with the -i  inputfile commandline argument, one line at a time.  By default each input line should

be sent to each job to which jobthing has a pipe connection, however a line starting with the asterisk character

‘*’ will be interpreted as a command.

After  sending  the  input  text  to  each job,  jobthing  will  then  attempt  to  read  a  line  of input  from  each

job  (again,  only those to which  jobthing  is  connected by a pipe).   Output received  from jobs  is emitted to

jobthing’s standard output.

Upon reading EOF from the input (stdin or the input file), jobthing shall terminate.

jobthing job parsing

The job file provided to jobthing is a text file, with one line per job.

If jobthing is unable to open the job file for reading, it is to emit the following message to stderr, and

exit with return code 2:

Error: Unable  to  read  job  file

Lines beginning with the ‘#’  (hash) character are comments, and are to be ignored by jobthing.  Similarly,

empty lines (i.e. with no characters before the newline) are to be ignored.

All other lines are to be interpreted as job specifications, split over 4 separate fields delimited by the colon (‘ : ’)

character as follows

numrestarts:input:output:cmd  [arg1  arg2  . . .]

where each field has the following meaning or intepretation (where “empty” means a zero length string):

● numrestarts – specifies how  many times  jobthing  shall  start or restart this job  if it terminates.   0

(zero) or empty implies that jobthing shall restart the job every time it terminates, 1 (one) means that

jobthing should attempt to launch the job once only upon startup – if it terminates it is not restarted.

Other integers are interpreted similarly.

● input – empty implies that this job shall receive its standard input from a pipe connected to jobthing.

Otherwise, the named file is to be opened for reading and connected to this job’s standard input stream.

●  output – empty implies that this job shall send its standard output to a pipe connected to jobthing. Otherwise, the named file is to be opened for writing (with flags O_CREAT  |  O_TRUNC and permissions S_IWUSR  |  S_IRUSR) and connected to this job’s standard output stream.

●  cmd  [arg1  arg2  . . .] – the name of the program to be run for this job, and optional arguments to be    105 provided on the commandline to that program. Arguments are separated by spaces. Program names and    106 arguments containing spaces may be specified by enclosing them in double quotes.  A helper function is    107 provided to make this easer, see the split_space_not_quote() function described on page 11.

each other  (e.g.  sharing input or output files etc).  We will only test job specifications that have predictable

and deterministic behaviour.

Note:  The colon character has special meaning and will only appear in job files as a separator.  You do not

need to consider, nor will we test for jobfiles that contain the colon character as part of a command name or

argument.

Note:  See the  split_line() function described on page 11 for an easy way to split the colon-delimited job

specifications.