MULTICS TECHNICAL BULLETIN MTB-665
To: MTB Distribution
To: Distribution
From: Bonnie Braun
Date: 05-18-84
Subject: Implement a deadproc request for analyze_multics.
Comments can be directed to the author via:
Phone: HVN 357-6638, 602-862-6638
Forum: >udd>m>blb>mtgs>azm on System M.
Mail: Braun.Multics on System M in Phoenix.
ABSTRACT
Analyzing dead processes has never been supported in the
past. The tool ol_dump didn't support them. One private
tool, interpret_fdump (ifd), handled them. This was
dependent on the grab_pdir exec_com to extract the
process information. This MTB describes the
analyze_multics request to interpret dead processes and
proposes a tool copy_deadproc to be used to appropriately
set up a dead process directory.
________________________________________
Multics Project internal working documentation. Not to be
reproduced or distributed outside the Multics Project.
MTB-665 AZM deadproc
I. INTRODUCTION
First, a little background on how things currently work. For a
process to be saved upon termination, the save_pdir attribute has
to be on for the project/user. Assuming this is true, the
program dpg_ is invoked at termination time, to save the process
directory. This is done by renaming the dead process directory
from its unique_chars name to person.project.f.tty_name. It is
not moved to another, more permanent directory, but left in the
>process_dir_dir.
II. PROPOSAL
For azm to deal with dead processes, several assumptions will be
made. They are:
1) The save_pdir attribute must be on.
2) The dead process directory is in a permanent location. This
means it must be moved out of the >pdd so a system crash or a
re-boot won't effect it.
3) The owner of a dead process does not automatically have access
to his dead process directory. This will be an option left up to
the system administrator, or whoever is doing the copying.
4) Access to other dead processes will not be automatically
given.
No form of automatic copying of dead processes to another
directory will be implemented at this time. Copying will be done
by a person with system privileges such as a system
administrator. The program dpg_ will continue to rename fatal
processes as it currently does. In addition, it will set sma
access for *.SysMaint.* and *.SysAdmin.*. Setting this access
requires a change to dpg_. A subroutine called copy_pdir_, will
require system privileges to copy the dead process directory. A
tool, copy_deadproc, will interface to the subroutine. This
command is documented below.
A directory >dumps>save_pdirs will be created. The deadprocess
directories will be placed in this directory. The name of the
dead process directory will be renamed from what dpg_ named it,
person.project.f.tty_name, to person.project.N, where N is a
numeric number. If directories already exist with the name
person.project.N, these will be renamed to person.project.N+1 and
the most recent directory will always have the name
person.project.1.
Access required:
AZM deadproc MTB-665
The SysMaint and SysAdmin projects will have sma access on both
directories >dumps>save_pdirs and
>dumps>save_pdirs>person.project.1.
The user of the dead process directory will not be given access
automatically. This will be an option for the administrator via
the copy_deadproc tool. The access for an owner, when requested,
will be status on >dumps>save_pdirs and and status-modify for the
owner's pdir.
Site Responsibility: The site is responsible for creating
>dumps>save_pdirs at installation time. Access on the save_pdirs
directory will be set to sma for *.SysMaint and *.SysAdmin and
status for *.*.*. This information will be included in the
installation instructions for MR11.
The dead process directory:
The contents of the process directory will contain everything in
the user's process directory at the time of the fatal error, a
copy of its stack_0 and some hardcore segments that
analyze_multics needs. These are the slt, definitions_,
name_table and a uid_hash_table. These data segments add on the
average of 173 pages to the size of a dead process directory.
With the inclusion of these data segments, a deadproc directory
uses quota in the range of 400-560 pages.
These data segments are required for each deadproc directory
because a deadproc directory can be kept over bootloads. If
there are dead process directories from different bootloads, the
data segments could be different, thus, requiring each directory
to have a copy of its own.
Space for deadprocs will be managed dynamically bysiphoning off
needed quota from >dumps.
Deletion of deadproc directories will be handled like fdumps are
currently done on System-M. That is, someone manually deletes
them. A future consideration is to have a cleanup_pdirs command,
similar to the clean_card_pool command. This may be in
conjuction with a delete_deadproc request within azm. These will
not be developed at this time.
It is important to remember that for the dead process to be
valid, the copying must be done during the same boot of the
system as when the fatal error occured.
III. COPY_DEADPROC COMMAND
Name: copy_deadproc
MTB-665 AZM deadproc
Syntax: copy_deadproc {deadproc_name} {-ctls_args}
Function: This tool sets up a dead process directory in
preparation for use by analyze_multics. It copies a dead process
directory specified by deadproc_name into the directory under the
>dumps>save_pdirs directory. Several hardcore segments needed by
analyze_multics are also copied into the directory. Two segments
are created by the copy_deadproc tool, pdir_info and
uid_hash_table. These are used by analyze_multics when examining
a dead process. The dead process directory is renamed to
person.project.N where N is the number 1. If person.project.1
already exists, it is remained to person.project.N+1 before the
copy of the new directory. Access is set to sma for the SysMaint
and SysAdmin projects.
Arguments:
deadproc_name
is the name of the dead process directory to be copied. If
deadproc_name is not an absolute pathname, the default path is
>process_dir_dir>deadproc_name. The names of dead process
directories in the >process_dir_dir are of the form
person.project.f.tty_name.
Control Arguments:
-delete, -dl
specifies that after the dead process is copied, the original
one is to be deleted.
-name deadproc_name, -nm deadproc_name
specifies the name of the process to be copied.
-no_delete, -ndl
specifies do not delete the dead process directory after
copying is complete. This is the default.
-owner, -ow
specifies that access be set appropriately for the user of the
fatal process. This is status on >dumps>save_pdirs and sm on
the dead process directory.
Notes: The use of this command requires access to hcs_, hphcs_,
and the system_privilege_gate_.
The amu_ Interface to copy_deadproc:
The copy_deadproc tool calls amu_$dp_create_uid_hash to build a
unique_id hash table (called uid_hash_table) for segments in
>system_library_1. Thus, when the analyze_multics deadproc
request is invoked, address resolution can continue to take place
dynamically without distinguishing between what kind of dump we
are looking at.
AZM deadproc MTB-665
This entrypoint, amu_$dp_create_uid_hash, is a transfer vector
for amu_deadproc_$create_uid_hash. Like the rest of amu_, this
will be left undocumented for now.
IV. AZM INTERFACE
To accommodate dead process analysis, one new request and
modifications to one existing request are needed. Many of the
azm requests used for fdump analysis are not meaningful when
analyzing a dead process. Such requests will be disabled when
the deadproc request is invoked. This will be done by using a
different request table.
Requests enabled for deadprocs are:
absolute_address, add_request_table, apply, display,
display_absolute, list_dumps, page_trace, quit, replace,
sdw, select_dump, search, name, number, set, stack, value,
machine_conditions, history_regs
Requests disabled for deadprocs are:
apte, associative_memory, aste, configuration_deck, events,
scus, select_process, syserr_log, traffic_control_queue,
verify_associative_memory, why
New Azm Request:
Name: select_deadproc, sldp
Syntax: sldp {NAME}
Function: Selects and translates a dead process. Found via the
dumps search list which defaults to >dumps>save_pdirs.
Argument:
NAME
Is the name of the process directory of interest. This can be
a relative or absolute pathname. The dead process directory
name is of the form person.project.date_time or just
person.project.N where N is a numeric number, N=1 for the most
recently copied dead process.
Notes: When sldp is invoked with no arguments, it prints an
identifying message. This is identical to how the select_dump
request works.
Modify Existing Request:
Change the list_dumps request to know about both fdumps and
deadprocs.
Name: list_dumps, lsd
MTB-665 AZM deadproc
Syntax: lsd {PATH} {-ctl_args}
Function: Lists dumps in the selected dump directory. If PATH
is not given, all dumps in the dump directories specified in the
dumps search list are listed.
Arguments:
PATH
specifies PATH as the dump directory to list.
Control Arguments:
-deadproc, -dp
specifies list only dead process directories. If PATH is not
given, it checks all directories in the dumps search list for
dead processes.
-fdump, -fd
specifies list only fdumps. If PATH is not given, it checks
all directories in the dumps search list.
Notes: If no arguments are given, the default is to list only
fdumps.
Search List:
Analyze_multics will use the search_list_defaults_ mechanism to
locate and setup the dumps search list, which by default, will
contain the directories >dumps and >dumps>save_pdirs.