COREADM(8) | Maintenance Commands and Procedures | COREADM(8) |
coreadm - core file administration
coreadm [-g pattern] [-G content] [-i pattern] [-I content]
[-d option]... [-e option]...
coreadm [-p pattern] [-P content] [pid]...
coreadm specifies the name and location of core files produced by abnormally-terminating processes. See core(5).
Only users and roles that belong to the "Maintenance and Repair" RBAC profile can execute the first form of the SYNOPSIS. This form configures system-wide core file options, including a global core file name pattern and a core file name pattern for the init(8) process. All settings are saved persistently and will be applied at boot.
Non-privileged users can execute the second form of the SYNOPSIS. This form specifies the file name pattern and core file content that the operating system uses to generate a per-process core file.
A core file name pattern is a normal file system path name with embedded variables, specified with a leading % character. The variables are expanded from values that are effective when a core file is generated by the operating system. The possible embedded variables are as follows:
%d
%f
%g
%m
%n
%p
%t
%u
%z
%Z
%%
For example, the core file name pattern /var/cores/core.%f.%p would result, for command foo with process-ID 1234, in the core file name /var/cores/core.foo.1234.
A core file content description is specified using a series of tokens to identify parts of a process's binary image:
anon
ctf
data
debug
dism
heap
ism
rodata
shanon
shfile
shm
stack
symtab
text
In addition, you can use the token all to indicate that core files should include all of these parts of the process's binary image. You can use the token none to indicate that no mappings are to be included. The default token indicates inclusion of the system default content (stack+heap+shm+ism+dism+text+data+rodata+anon+shanon+ctf+symtab). The /proc file system data structures are always present in core files regardless of the mapping content.
You can use + and - to concatenate tokens. For example, the core file content default-ism would produce a core file with the default set of mappings without any intimate shared memory mappings.
The coreadm command with no arguments reports the current system configuration, for example:
$ coreadm
global core file pattern: /var/cores/core.%f.%p
global core file content: all
init core file pattern: core
init core file content: default
global core dumps: enabled
per-process core dumps: enabled
global setid core dumps: enabled per-process setid core dumps: disabled
global core dump logging: disabled
The coreadm command with only a list of process-IDs reports each process's per-process core file name pattern, for example:
$ coreadm 278 5678
278: core.%f.%p default
5678: /home/george/cores/%f.%p.%t all-ism
Only the owner of a process or a user with the proc_owner privilege can interrogate a process in this manner.
When a process is dumping core, up to three core files can be produced: one in the per-process location, one in the system-wide global location, and, if the process was running in a local (non-global) zone, one in the global location for the zone in which that process was running. Each core file is generated according to the effective options for the corresponding location.
When generated, a global core file is created in mode 600 and owned by the superuser. Nonprivileged users cannot examine such files.
Ordinary per-process core files are created in mode 600 under the credentials of the process. The owner of the process can examine such files.
A process that is or ever has been setuid or setgid since its last exec(2) presents security issues that relate to dumping core. Similarly, a process that initially had superuser privileges and lost those privileges through setuid(2) also presents security issues that are related to dumping core. A process of either type can contain sensitive information in its address space to which the current nonprivileged owner of the process should not have access. If setid core files are enabled, they are created mode 600 and owned by the superuser.
The following options are supported:
-d option...
Multiple -e and -d options can be specified on the command line. Only users and roles belonging to the "Maintenance and Repair" RBAC profile can use this option.
-e option...
global
global-setid
log
process
proc-setid
Multiple -e and -d options can be specified on the command line. Only users and roles belonging to the "Maintenance and Repair" RBAC profile can use this option.
-g pattern
Only users and roles belonging to the "Maintenance and Repair" RBAC profile can use this option.
-G content
Only users and roles belonging to the "Maintenance and Repair" RBAC profile can use this option.
-i pattern
Only users and roles belonging to the "Maintenance and Repair" RBAC profile can use this option.
-I content
Only users and roles belonging to the "Maintenance and Repair" RBAC profile can use this option.
-p pattern
A nonprivileged user can apply the -p option only to processes that are owned by that user. A user with the proc_owner privilege can apply the option to any process. The per-process core file name pattern is inherited by future child processes of the affected processes. See fork(2).
If no process-IDs are specified, the -p option sets the per-process core file name pattern to pattern on the parent process (usually the shell that ran coreadm).
-P content
A nonprivileged user can apply the -p option only to processes that are owned by that user. A user with the proc_owner privilege can apply the option to any process. The per-process core file name pattern is inherited by future child processes of the affected processes. See fork(2).
If no process-IDs are specified, the -P option sets the per-process file content to content on the parent process (usually the shell that ran coreadm).
The following operands are supported:
pid
Example 1 Setting the Core File Name Pattern
When executed from a user's $HOME/.profile or $HOME/.login, the following command sets the core file name pattern for all processes that are run during the login session:
example$ coreadm -p core.%f.%p
Note that since the process-ID is omitted, the per-process core file name pattern will be set in the shell that is currently running and is inherited by all child processes.
Example 2 Dumping a User's Files Into a Subdirectory
The following command dumps all of a user's core dumps into the corefiles subdirectory of the home directory, discriminated by the system node name. This command is useful for users who use many different machines but have a shared home directory.
example$ coreadm -p $HOME/corefiles/%n.%f.%p 1234
Example 3 Culling the Global Core File Repository
The following commands set up the system to produce core files in the global repository only if the executables were run from /usr/bin or /usr/sbin.
example# mkdir -p /var/cores/usr/bin example# mkdir -p /var/cores/usr/sbin example# coreadm -G all -g /var/cores/%d/%f.%p.%n
/var/cores
The following exit values are returned:
0
1
2
gcore(1), pfexec(1), svcs(1), exec(2), fork(2), setuid(2), time(2), syslog(3C), core(5), prof_attr(5), user_attr(5), attributes(7), smf(7), init(8), svcadm(8)
In a local (non-global) zone, the global settings apply to processes running in that zone. In addition, the global zone's apply to processes run in any zone.
The term global settings refers to settings which are applied to the system or zone as a whole, and does not necessarily imply that the settings are to take effect in the global zone.
The coreadm service is managed by the service management facility, smf(7), under the service identifier:
svc:/system/coreadm:default
Administrative actions on this service, such as enabling, disabling, or requesting restart, can be performed using svcadm(8). The service's status can be queried using the svcs(1) command.
The -g, -G, -i, -I, -e, and -d options can be also used by a user, role, or profile that has been granted both the solaris.smf.manage.coreadm and solaris.smf.value.coreadm authorizations.
August 3, 2021 | OmniOS |