Search all pages
Professions, Sciences, Humanities, Business, ...
Text-based, GUI, Audio, Video, Keyboards, Mouse, Images,...
Conversions, tests, processing, manipulation,...
Integer, Floating point, Matrix, Statistics, Boolean, ...
Algorithms, Memory, Process control, Debugging, ...
Data storage, Integrity, Encryption, Compression, ...
Networks, protocols, Interprocess, Remote, Client Server, ...
Timing, Calendar and Clock, Audio, Video, Printer, Controls...
Management, Filtering, File & Directory access, Viewers, ...
RocketLink!--> Man page versions:
supfilesrv, supscan - sup server processes
supfilesrv [ -l ] [ -q ] [ -N ] [ -P ] [ -C MaxChildren ]
[ -O lockdir ]
supscan [ -v ] [ -s ] [ collection ] [ basedir ]
Supfilesrv is the server processes used to interact with
sup client processes via the IP/TCP network protocol.
This server normally is expected to be running on server
machines at all times. Each machine with files of inter-
est to users on other machines is expected to be a file
server and should run supfilesrv.
A file server machine will service requests for both "pri-
vate" and "system" file collections. No special action is
necessary to support private collections, as the client
user is expected to supply all necessary information. For
system collections, if the base directory is not the
default (see FILES below), an entry must be put into the
directory list file; this entry is a single text line con-
taining the name of the collection, one or more spaces,
and the name of the base directory for that collection.
Each collection should have an entry in the host list
file; this entry is a single text line containing the name
of the collection, one or more spaces, and the name of the
host machine acting as file server for that collection.
Details of setting up a file collection for the file
server are described in the manual entry for sup(1).
Supfilesrv generally runs as a network server process that
listens for connections, and for each connection (dou-
ble-)forks a process to handle the interaction with the
client. However, with the -l flag, no forking will take
place: the server will listen for a network connection,
handle it, and exit. This is useful for debugging the
servers in "live" mode rather than as daemons.
For debugging purposes, the -P "debugging ports" flag can
be used. It will cause the selection of an alternate,
non-privileged set of TCP ports instead of the usual
ports, which are reserved for the active server processes.
The -N "network debugging" flag can be used to produce
voluminous messages describing the network communication
progress and status. The more -N switches that you use the
more output you get. Use 3 (separated by spaces: -N -N -N)
to get a complete record of all network messages. Log mes-
sages are printed by syslog on daemon.log . To suppress
log messages, the -q "quiet" flag can be used.
Normally the supfilesrv will only respond to 3 requests
simultaneously, forking a child process for each client.
If it gets additional requests it will respond with the
error FSSETUPBUSY. The -C MaxChildren switch can be used
to increase (or decrease) this number.
The -O lockdir switch is used to make supfilesrv allow
only one active connection at a time from any client ip
address. This is accomplished by each serving process
obtaining exclusive lock, and writing it's process ID into
a file in "lockdir" where the filename is the dotted deci-
mal ip address of the connecting host. Any connections
from a client where a lock can not be obtained on such a
file will be rejected, limiting any client host to one
connection at a time to this sup server. This is useful
for preventing problems where clients running sup on a
regular basis manage to time requests so that a second
request comes in before the first one completes.
It is possible to pre-compile a list of the files in a
collection to make supfilesrv service that collection much
faster. This can be done by running supscan on the
desired collection on the repository machine. This pro-
duces a list of all the files in the collection at the
time of the supscan; subsequent upgrades will be based on
this list of files rather than actually scanning the disk
at the time of the upgrade. Of course, the upgrade will
consequently bring the client machine up to the status of
the repository machine as of the time of the supscan
rather than as of the time of the upgrade; hence, if sup-
scan is used, it should be run periodically on the collec-
tion. This facility is useful for extremely large file
collections that are upgraded many times per day, such as
the CMU UNIX system software. The "verbose" flag -v will
cause supscan to produce output messages as it scans the
files in the collection. The "system" flag -s will cause
supscan to scan all system collections residing on the
current host. The basedir parameter must be specified if
the collection is a private collection whose base direc-
tory is not the default.
/usr default base directory for a collection
directory list file for file server
host list file for system sups.
files used by file server (see sup(1))
list file used by supscan to create file list
file list created by supscan from list file
The SUP Software Upgrade Protocol, S. A. Shafer, CMU
Computer Science Dept., 1985.
The file server places log messages on the standard and
diagnostic output files. The process name and process id
number generally accompany each message for diagnostic
31-July-92 Mary Thompson (mrt) at Carnegie Mellon Univer-
Removed references to supnameserver which has not
existed for a long time. Update a few file names.
Added -C switch.
21-May-87 Glenn Marcy (gm0w) at Carnegie-Mellon Univer-
Updated documentation for 4.3; changed /usr/cmu to
15-Jan-86 Glenn Marcy (gm0w) at Carnegie-Mellon Univer-
Updated documentation; -s switch to supscan.
23-May-85 Steven Shafer (sas) at Carnegie-Mellon Univer-
Supscan created and documented; also -N flag.
04-Apr-85 Steven Shafer (sas) at Carnegie-Mellon Univer-
Source: OpenBSD 2.6 man pages. Copyright: Portions are copyrighted by BERKELEY
SOFTWARE DESIGN, INC., The Regents of the University of California, Massachusetts
Institute of Technology, Free Software Foundation, FreeBSD Inc., and others.
(Corrections, notes, and links courtesy of RocketAware.com)
Up to: File Transfer and Distribution - Protocols and Methods of transfering files and directories, distributing and installing software. (file collections and archives, FTP, cvsup, NFS, et al.)
RocketLink!--> Man page versions:
Search | About | Comments | Submit Path: RocketAware > man pages >
RocketAware.com is a service of Mib Software
Copyright 1999, Forrest J. Cavalier III. All Rights Reserved.
We welcome submissions and comments