Manpage of alfred

alfred

Section: User Commands (1)
Version: 3.1
Package: RenderMan Artist Tools
Index

NAME

alfred - distributed execution/rendering dispatcher (also monitor, maitre_d, and nimby)

SYNOPSIS

alfred [options] [ worklist | RIBfiles... ]

DESCRIPTION

alfred is a distributed task management tool, primarily intended for use with Pixar's RenderMan Artists Tools to launch and track renderings.

The optional file argument specifies either a list of RIB files to be rendered, or an alfred worklist or control script (these are typically generated by an application such as mtor, see the accompanying detailed documentation).

The alfred executable can run in several modes, these are typically transparent to the user, although their distinctions may be of interest to administrators or developers. Typically the program is launched as


    alfred scriptfile

(e.g. from the command line or from the MTOR plug-in to Maya). This invocation calls fork(2) and becomes two independent (communicating) processes, one of which is the graphical user-interface, or task monitor. The other fork becomes the dispatcher which is the background process that actually launches and tracks the specified tasks in the script. The dispatcher process only exits when its queue of spooled jobs has been successfully processed. The monitor (UI) can be closed down at any time, and restarted later without affecting the dispatcher (launching alfred with no arguments just starts a UI). The dispatcher fork also resets its process group ID [see intro(2)] and therefore will continue executing after logout.

If a dispatcher is already running, then newly launched alfreds will only spool any specified scripts and then simply connect as monitors. If both a monitor and dispatcher are already running, then additional alfreds just spool their specified files to the running dispatcher and exit (they also send a signal to the running monitor indicating that it should raise to the front of the window stack). It is also possible to connect an alfred monitor to a dispatcher running on a remote machine, to check on the status of jobs there.

If alfred is launched in -maitre_d mode, it becomes a network-wide daemon that arbitrates remote server requests and enforces a priority scheme.

Finally, alfred can be launched in -nimby mode (not-in-my-back-yard), in which case it contacts the system maitre_d and requests a temporary block on the use of the invoking workstation as a remote server (i.e. other alfred users on the network are blocked from sending jobs to the system running nimby). In this mode alfred produces a small desktop UI which indicates, and controls, its server status.

OPTIONS

-help: print a brief summary of invocation options.
-version: print version information (and exit).
-paused: start up in paused mode, to allow preference changes, etc. If there are also job filename arguments specified later on the command line, then only the newly spooled jobs will be paused, otherwise all current jobs are paused.
-unpause: if dispatcher is currently paused, resume dispatching.
-dispatch: explicitly start the dispatcher, rather than implicitly starting a dispatcher (fork) when the first job is spooled or first UI is started.
-immortal: dispatcher won't exit, even when there are no jobs on its queue (used with the -dispatch option to keep a dispatcher running at all times).
-nimby: start the not-in-my-back-yard monitor, an interface to the maitre_d which keeps jobs off the local host when it is idle.
-maitre_d: start the (optional) network-wide server arbitration daemon
-spool: send the named files to the dispatcher for processing, but do not start a monitor (i.e. spooling with no user-interface).
-nofork: keep the alfred process in the foreground, usually it forks and immediately returns control to the calling shell.
-after date: delays the start of job processing until the given time; the job is spooled and placed on the queue, but no processing occurs until after the date specified; dates are of the form 'month day hour:minute' or for times later on the same day 'hour:minute' (up until midnight). Note that the date contains spaces and so must be quoted to appear as a single argument to the shell. Hours should be given as for a 24-hour clock. For example to delay a job until June 23 at 1:45PM, use: alfred -after '6 23 13:45' files...
-log file: redirect log messages to the named file instead of the console.
-geom xgeom: initial window placement geometry, in the form WxH+X+Y.
-nbg xcolor: NIMBY-mode window background color, as #rrggbb or showrgb(1) name.
-nrv xcolor: NIMBY-mode window reverse color, when jobs exist.
-tags taglist: additional global/local limit tags which will be appended to the tag list associated with each Cmd in the worklist.
-service expr: additional remote server selection keys (as a logical expression) which will be ANDed with the service expression associated with each Cmd in the worklist.
-pbias bias: specifies a positive or negative offset value, bias, which will be applied to the default per-Crew server priority defined in the alfred.schedule file. The resulting value is used by the maitre-d when deciding how to assign servers to competing jobs from different users. Each dispatcher will tend to get remote servers in proportion to their priority, relative to that of other users. Note that this priority value only affects remote server assignments in active jobs; the order in which jobs are processed is determined by their position in their dispatcher's job queue. See the Job Priorities discussion in the documentation for more details.
-crews crewlist: specifies the list of Crews to be used when determining remote server access; applies to users who are members of multiple crews but who want a particular job to execute with a restricted set of server access permissions. Crews listed here but which don't apply to the user are ignored. If the list is empty, then the default list is derived from the schedule.
-power: explicitly attempt to acquire the unlimited-fanout dispatch license.
-h [user@]host: connect as a monitor (only) to the dispatcher running for user at host. This allows a local user-interface to a remote job queue. Authentication is similar to rlogin(1) and hence local users must have login privileges on the remote system. Access will be view-only unless the local user is listed in the remote user's .rhosts file. If user is not specified, the local userid is used. Note: this option specifies the identity (owner) of the dispatcher to locate on the remote system.
-l login: (in conjunction with -h above) connect to remote system as the user login instead of using the local user name (the default).
-n maxservers: attempt to bind at most maxservers remote servers to each command which requests them (e.g. netrender). The default is one server per command. This option is primarily intended for use with RIB files named on the command line (e.g. bucket-parallel previews).
-n min,max: bind at least min and at most max remote servers to each command.
-nametree: use prefixes of input filenames to construct a processing hierarchy, for *.rib arguments
-rm: remove successfully rendered RIB files. Note: this applies only to RIB files whose names are given as additional arguments to the same invocation of alfred (e.g. alfred -rm *.rib).
-wpasswd: prompts for the new wrangler-mode password.

NOTES

Automatic Window Placement

The alfred UI windows tend to remember their placements from one invocation to the next, which is generally considered a feature. In most cases the window geometries are part of the information stored in the ~/.pixarPrefs/alfred.prefs file; removing this file will effectively reset all the preferences, including window placement. It is often desirable to make the nimby user-interface (a small window containing a single push-button), a part of a user's standard login desktop; if alfred receives a save-yourself message from the window manager (as often happens during a standard X11 logout), it arranges for its current location to become part of the desktop re-invocation parameters; i.e. it'll start in the same place when the user logs in next. Also, for aesthetic reasons, it can be nice to have the nimby button displayed without the usual window manager titlebars etc; to achieve this in the typical X11 environment, place the following line in ~/.Xresources


   *nimby*clientDecoration: none

(and remember, on default SGI systems you can bring up the window manager control menu (move/resize/etc) by using Alt-Spacebar).

Automatic Hierarchies

When alfred is invoked as


   alfred -nametree *.rib

the RIB file names are analyzed to generate a hierarchy of processing dependencies. For example, shadow map files might need to be rendered before the final frame file which requires them. The scheme uses a convention in which shared prefixes on filename imply a depth in the hierarchy. Files whose names occur as the leading portion of another (longer) filename are considered to be above the longer-named file in the processing hierarchy. In addition, alphabetical sorting is used to determine sibling orders. Before name comparisons begin, any trailing ".rib" suffix is removed. For example, the files: frame07.rib, frame07.shd.A.rib, frame07.shd.B.rib would be placed into a worklist script such that shd.A and shd.B would render (in parallel) before frame07.rib is rendered. This is because the string "frame07" is the first part of each of the other two file names.

FILES

The alfred configuration and startup files are located in $RATTREE/lib/alfred (if the environment variable RATTREE isn't defined, the default value is /usr/local/rat, or for some files, $RMANTREE or /usr/local/prman).

alfred.ini: the system-wide default settings for preferences and tunable parameters.
alfred.schedule: the system-wide definition of which remote servers are available to client applications launched by alfred. This file also defines any user or time-of-day access restrictions to the remote servers. Typically this file is writable only by a production coordinator or whoever is organizing resources.
resources: this directory contains icons and data used by the program.
resources/alfred.help: the text of balloon help messages, and the names used by the UI to display tasks states (e.g. Blocked, Ready, Active, etc). Some sites might want to modify this file to reflect the local environment (or language).
/usr/tmp/alfredSpool: the default location of the spooling directory, holds spooled scripts, checkpoint versions of executing scripts, and other temporary files.
~/.pixarPrefs/alfred.prefs: user-specific preference settings (in each home directory). These are overrides for a subset of the parameters set in the system-wide alfred.ini file.
/tmp/.alfdp.userid: each dispatcher records its process-id and UI communications port number in this file; it serves as both a lock to prevent multiple dispatchers from being started for each new job (per user), and as a place to record the port used for spooling and UI updates.
/tmp/.alfui.login.remoteID: each running UI records its process-id, this acts as a lock to prevent multiple UI windows from being started for a single user (per local machine per remote dispatcher).
/tmp/.alfui.nimby.userid: recorded process-id of any alfred running in nimby mode.

BUGS

Some diagnostic messages (from daemonized dispatchers or maitre_d's) go to /dev/console, which is often not the same as the shell window from which alfred was started.

DATE

Dec 1995

AUTHOR

David Laur & Dana Batali