Caché System Administration Guide
Using Caché on UNIX®, Linux, and macOS
This chapter describes specific administrative procedures on UNIX®, Linux, and macOS. This chapter addresses the following topics:
Every Caché installation on a UNIX® platform has the following users and groups:
Caché must be installed by root
, and some processing by Caché system daemons runs as root
Owner of instance
This user owns most installation files and has full control of the instance. If you install with Minimal initial security settings, root
is the default owner; otherwise, you are prompted for the owner during installation.
Effective user for Caché superserver and its jobs
All Caché processes spawned by the superserver to serve incoming requests run as this user; in addition jobs hosted by jobserver processes, taskmanager jobs, and user-defined startup routines (for example, ^%ZSTART
) also run as this user. By default, this user is cacheusr
, but you can change the user during installation.
Effective group for Caché processes
All Caché processes automatically run as this group, which allows normal users, while inside Caché, to access Caché database and journal files to which they may not otherwise have been granted access; file permissions on these and other Caché files are set to allow this group to have appropriate access. On a secure system, no actual user should be a member of this group. By default, this group is cacheusr
, but you can change the group during installation.
All journals and journal directories must have the group ownership set to the Effective group for Caché processes
group and grant full permissions to that group (rw
for journals, rwx
for journal directories). The user who owns the journal and journal directories may vary depending on how they were created.
Journals and journal directories created within Caché are created with the appropriate permissions. However, if you move, copy or create journal directories or journals externally (via scripts or administrator action), you must ensure that the proper permissions are maintained. Failure to set the permissions properly may lead to unexpected and serious errors.
journal directory cacheowner cacheusr drwxrwxr-x
20170801.001 cacheowner cacheusr -rw-rw----
These settings are maintained, in part, as the set of permissions on the executables within the install-dir/bin
directory of the Caché installation. Relevant properties include: ownership, group, mode, set-uid, and set-gid bits. It is important that you do not modify these permissions when performing administrative tasks at the operating-system level.
All databases and database directories must have the group ownership set to the Effective group for Caché processes
group and grant full permissions to that group (rw
for databases, rwx
for database directories). The user who owns the databases and database directories may vary depending on how they were created.
Databases and database directories created within Caché are created with the appropriate permissions. However, if you move, copy or create database directories or databases externally (via scripts or administrator action), you must ensure that the proper permissions are maintained. Failure to set the permissions properly may lead to unexpected and serious errors.
dataset directory cacheowner cacheusr drwxrwxr-x
CACHE.DAT cacheowner cacheusr -rw-rw----
The Caché instance uses the following resources to control starting, stopping, and creating new processes:
Caché uses advisory file locking to prevent multiple startups of the same instance on different machines. With advisory file locking, a single lock file (in this case, the file clock in the install-dir/bin
directory) may be used to exclusively lock multiple resources. The Control Process, Write daemon, and Journal daemon each lock a separate section of the lock file. If this section of the clock file is already locked, startup terminates. The locks held by the different daemons are called Daemon Resource Locks.
A file lock is held by a process until the process terminates. Thus if any lock is held, it indicates that some daemon process on some node is running. It does not indicate, however, whether or not the instance is healthy and running normally.
file contains the name of the node where Caché was started. The existence of the cache.ids
file acts as a flag to Caché utilities and customer-written scripts indicating whether or not the instance is up and running this file is often ignored during startup. However, if an error occurs when cache.ids
is being read, it will prevent Caché from starting up. In previous versions of Caché, the shared memory identifiers were also stored in the cache.ids
file, but this is no longer the case.
To best understand the startup sequence, imagine that the instance can be run from two (2) different nodes (machines), node A and node B. The cache.ids
file is visible to both nodes, as are the Daemon Resource Locks (for shared files). The shared memory itself, however, is visible only on the node on which it was created (that is, the node where you started Caché).
The startup routine runs cache cV
to find out the status of the instance. It first attempts to attach to shared memory for the instance:
If there is no shared memory for the instance, a test is made for Daemon Resource Locks:
If no Daemon Resource Locks are held, the instance is reported down.
If Daemon Resource Locks are held, the instance is reported to be running on the node specified in the cache.ids
file. If the cache.ids
file does not exist, no information is available on where the daemons are running.
If the attach succeeded, the system is assumed to be up and running. This status is reported to the user. Startup halts.
If an error displays indicating that startup cannot be completed because shared memory is still attached, wait a few minutes for the memory to be released. If the error persists, there may be an error related to the cache.shid
file, which tracks the shared memory ID of Caché on all UNIX® platforms except macOS. Contact the InterSystems Worldwide Response Center
(WRC) for support correcting the file.
The Caché startup process (cache
) is run. Checks are repeated to ensure that another startup is not competing for the startup resources:
Caché continues startup.
The owner of the installation has full privileges to start and stop the instance, to perform system administration, and to run diagnostic programs for that instance.
Only the user ID that is the owner of the instance can and should run all diagnostic activities. This ensures that any files or resources created are owned by the owner of the instance and not root (which may make it impossible to access these resources by a non-root user). For this reason, it is inadvisable for root to in any way administer an instance not owned by root (including starting and stopping the instance). A user running as root should only administer instances owned by root.
To start Caché, run the startup procedure at the system level. This procedure activates either a default configuration file or a configuration file you specify.
If you are not on the console machine, run Telnet and connect to the target machine where Caché is installed. Before you can start Caché on UNIX®, one of the following must be true:
ccontrol start <instname>
From the shell, a user with any user ID in the sysmgr
group can run ccontrol start
. This command verifies that the instance is not currently running on the current or another node, creates shared memory and basic Caché daemons, including multiple slave write daemons (SWDs), runs the startup (^STU
) routine, which creates additional daemons (for example, ECP daemon), and then allows user logins.
Running as anyuser:cacheusr
, Caché runs its standard startup logic, including Kerberos negotiation, to identify a $USERNAME
and a set of login roles. In many cases, this $USERNAME
value is associated with the actual user who invoked csession
. Thus, while any user may run Caché, the activities of that user once in Caché are defined and limited by the security roles assigned to that user.
The Caché executable is not itself a setgid-executable. It is the responsibility of the csession
wrapper to set the group properly on behalf of the user entering Caché. This is not a problem if you are running Caché from the /usr/bin
directory as set up by the ccontrol
default function. The ccontrol
default sets up an executable file called cache
in the /usr/bin/
directory and is a link to call csession
which sets permissions properly.
Normally you leave your Caché system running. However, if your operating system requires a restart, you should stop Caché before you shut down your system. The Caché maintenance tasks, such as backups and database repair utilities, do not require you to stop Caché.
To stop Caché on UNIX®, the same requirements exist as for starting Caché. One of the following must be true:
To stop Caché, from the command line:
You can stop Caché with the ccontrol force
command, but you should do so with caution because it may result in a loss of data.
This procedure invokes the Caché SHUTDOWN
utility, which displays a status report. Check for active processes in the report to determine if the next step is necessary.
Should it be necessary, broadcast a message to any users on the system:
Do you want to broadcast a message to anyone? No=> Yes
Send a message to other terminals. Message => Please sign off
Terminal => /dev/tty/06
After sending one message you can send others, until you respond to the Message
prompt by pressing Enter
When the system asks if you would like to see another system status, enter Yes
to see one, or press Enter
if you do not want another report.
If you answer Yes
, when the system status displays again, identify any active terminals.
Confirm that you want to halt by answering Yes
. If you answer No
, the shutdown procedure quits and Caché continues running.
On UNIX® platforms, when a Caché instance is stopped, restarted, or forced down, the instance will wait for all processes to detach from shared memory for a maximum of 30 seconds. After 30 seconds, the instance will close. If there are still processes attached to the shared memory after the instance has closed, restarting the instance will fail.
© 1997-2019 InterSystems Corporation, Cambridge, MA