spshed - spool scheduler
spshed [ options ]
spshed is the spool scheduler process for the GNUspool spooler and document management system.
To start GNUspool, spshed should be started. This should normally be done using spstart(1), which restarts it and passes the appropriate options. This may be put within the Operating System startup scripts.
Likewise to halt it, sstop(1)
should be invoked. This should be put,
using the -y option, in any system shutdown
routines.
If you do need to kill spshed for any reason, first try kill(1)
without any -9 option. This will give spshed the opportunity
to attempt to tidy up any IPC facilities before shutting down.
Information, either in respect of other machines to connect to, or pre-existing jobs and printers on the current machine, are read from the files /etc/gnuspool.hosts and the directory /var/spool/gnuspool respectively.
If a networked version of GNUspool is being run, then a ``slave'' spshed process is spawned to monitor and process incoming network messages. Incoming remotely-submitted jobs and API interfaces are handled via a separate process xtnetserv(8), which is also invoked as appropriate by spstart(1).
Appropriate log messages are written by spshed and other system processes to a log file, spshed_reps. Be sure to check this file for any error messages relevant to any problems you encounter.
/etc/gnuspool.hosts host names and descriptions
/etc/gnuspool.conf master configuration file
int-config message file
/var/spool/gnuspool spool directory
spshed_jfile job file
spshed_pfile printer file
spshed_reps error log file
spufile0 user data
charges0 user charges data
spmm_jobi job memory-mapped hash file
spmm_jobd job memory-mapped data file
spmm_ptrs printers memory-mapped file
spmm_xfer communication buffer memory-mapped file
alternative location for spool directory.
alternative location for help file directory.
alternative location for internal programs directory.
An IPC message queue, with key 0x58691000
and owned by spooler
,
is created by spshed and used to receive messages from user
processes, pass instructions to spd(8), and to pass internal messages
from the slave spshed process to the master.
Two shared memory segments are created to hold details of jobs and printers. As the shared memory facility provides no facilities for growth, then additional shared memory segments may be created if the job and printer lists expand sufficiently and the original ones deallocated.
The keys given to the shared memory segments start at 0x58691002
and ascend upwards to 0x58691064
before wrapping around.
A further shared memory segment, with key 0x58692002
is created to
hold details of pending jobs before transfer to the main shared memory
segment.
Versions of spshed may use memory-mapped files rather than shared memory. The files are held in the spool directory, by default /var/spool/gnuspool, and have the names spmm_jobi, spmm_jobd, spmm_ptrs and spmm_xfer.
A set of 5 semaphores, with the key 0x58691001
is created to
interlock access to the shared memory segments.
The presence or absence of these IPC facilities is used by spshed and other programs to determine whether a previous copy of itself is running. If spshed is abnormally terminated, it will probably be necessary to delete these IPC facilities before spshed can be restarted.
When printers are set running, spshed invokes an instance of spd(8)
to control each printer. Mail and attention messages are passed to
spmdisp(8)
for processing.
spshed accepts and sends interconnections from other machines on TCP port, passes the contents of spool files on a further TCP port, and undertakes ``probes'' on a UDP port.
The port numbers are set up in the /etc/services file when GNUspool is first installed.
spr(1), spq(1), spuser(1), sqdel(1), sqchange(1), sqlist(1), splist(1), spcharge(1), spstart(1), sstop(1), gnuspool.conf(5), gnuspool.hosts(5), cjlist(8), cplist(8), dosspwrite(8), ripc(8), spd(8), spdinit(8), spmdisp(8), spwrite(8), spuconv(8), xtnetserv(8).
spshed is invoked from system startup procedures or other programs such as spstart(1). Thereafter it runs as a ``daemon process'' and diagnostics are not written to any terminal but to the file spshed_reps.
In the event of any problems this file should be examined.
John M Collins, Xi Software Ltd.