The core dump configuration in your non global zone is A user is running a process in a non-global zone (testzone) and the process crashes. The process information is: user1 2663 2618 0 17:46:42…

Question

Exhibit

Options

• AThe file will be stored in the non-global zone's directory: /var/core/pprocess/core.hash.2663.
• BThe file will be saved in the global zone's directory: /var/core/core.bash.2663.
• CA core file cannot be generated in a non-global zone because it shares the kernel with the global zone.
• DThe file will be stored in the global zone's directory: /var/core/pprocess/core.bash.2663.
• EThe file will be saved in non-global zone's directory: /var/core/core.bash.2663

• A
  13% (3)
• B
  4% (1)
• D
  4% (1)
• E
  79% (19)

Explanation

Option E is correct because in Oracle Solaris, a non-global zone has its own filesystem namespace, so core dumps generated by processes running within that zone are written to paths inside the zone - /var/core/ in the zone's root - not the global zone's filesystem. The default coreadm naming pattern for per-process core files is core.%f.%p, where %f is the executable name (bash) and %p is the PID (2663), producing core.bash.2663.

Why the distractors fail:

• A & D invent a pprocess subdirectory and use hash in the filename - neither is a standard Solaris coreadm pattern.
• B correctly identifies the naming convention but wrongly places the file in the global zone; zone isolation keeps the file inside testzone.
• C is a plausible-sounding trap - zones do share the kernel, but that does not prevent core file generation; the zone has its own file namespace and processes can absolutely dump core.
• D doubles down on both errors: wrong zone and wrong path format.

Memory tip: Think "what happens in the zone, stays in the zone." A non-global zone is a virtualized container with its own filesystem view, so all process artifacts - including core dumps - are confined to that zone's directory tree, following the same coreadm naming rules (core.<name>.<pid>) as anywhere else in Solaris.

No community discussion yet for this question.