Turns the logging of system events On or Off. If On, a maximum of N events are kept in the debug structure (the default is 10). If Flag is get, a list of all logged events is returned. If Flag is print, the logged events are printed to standard_io. The events are formatted with a function that is defined by the process that generated the event (with a call to sys:handle_debug/4).

Enables or disables the logging of all system events in textual format to the file. The events are formatted with a function that is defined by the process that generated the event (with a call to sys:handle_debug/4).

Enables or disables the collection of statistics. If Flag is get, the statistical collection is returned.

Prints all system events on standard_io. The events are formatted with a function that is defined by the process that generated the event (with a call to sys:handle_debug/4).

Turns off all debugging for the process. This includes functions that have been installed explicitly with the install function, for example triggers.

Suspends the process. When the process is suspended, it will only respond to other system messages, but not other messages.

Resumes a suspended process.

Tells the process to change code. The process must be suspended to handle this message. The Extra argument is reserved for each process to use as its own. The function Module:system_code_change/4 is called. OldVsn is the old version of the Module.

Gets the status of the process.

The value of Misc varies for different types of processes. For example, a gen_server process returns the callback module's state, a gen_fsm process returns information such as its current state name and state data, a gen_statem process returns information about its current state and data, and a gen_event process returns information about each of its registered handlers. Callback modules for gen_server, gen_fsm, gen_statem and gen_event can also customise the value of Misc by exporting a format_status/2 function that contributes module-specific information; see gen_server format_status/2, gen_fsm format_status/2, gen_statem format_status/2, and gen_event format_status/2 for more details.

Gets the state of the process.

The value of State varies for different types of processes. For a gen_server process, the returned State is simply the callback module's state. For a gen_fsm process, State is the tuple {CurrentStateName, CurrentStateData}. For a gen_statem process State is the tuple {CurrentState,CurrentData}. For a gen_event process, State a list of tuples, where each tuple corresponds to an event handler registered in the process and contains {Module, Id, HandlerState}, where Module is the event handler's module name, Id is the handler's ID (which is the value false if it was registered without an ID), and HandlerState is the handler's state.

If the callback module exports a system_get_state/1 function, it will be called in the target process to get its state. Its argument is the same as the Misc value returned by get_status/1,2, and the system_get_state/1 function is expected to extract the callback module's state from it. The system_get_state/1 function must return {ok, State} where State is the callback module's state.

If the callback module does not export a system_get_state/1 function, get_state/1,2 assumes the Misc value is the callback module's state and returns it directly instead.

If the callback module's system_get_state/1 function crashes or throws an exception, the caller exits with error {callback_failed, {Module, system_get_state}, {Class, Reason}} where Module is the name of the callback module and Class and Reason indicate details of the exception.

The system_get_state/1 function is primarily useful for user-defined behaviours and modules that implement OTP special processes. The gen_server, gen_fsm, gen_statem and gen_event OTP behaviour modules export this function, so callback modules for those behaviours need not supply their own.

To obtain more information about a process, including its state, see get_status/1 and get_status/2.

Replaces the state of the process, and returns the new state.

The StateFun function provides a new state for the process. The State argument and NewState return value of StateFun vary for different types of processes. For a gen_server process, State is simply the callback module's state, and NewState is a new instance of that state. For a gen_fsm process, State is the tuple {CurrentStateName, CurrentStateData}, and NewState is a similar tuple that may contain a new state name, new state data, or both. The same applies for a gen_statem process but it names the tuple fields {CurrentState,CurrentData}. For a gen_event process, State is the tuple {Module, Id, HandlerState} where Module is the event handler's module name, Id is the handler's ID (which is the value false if it was registered without an ID), and HandlerState is the handler's state. NewState is a similar tuple where Module and Id shall have the same values as in State but the value of HandlerState may be different. Returning a NewState whose Module or Id values differ from those of State will result in the event handler's state remaining unchanged. For a gen_event process, StateFun is called once for each event handler registered in the gen_event process.

If a StateFun function decides not to effect any change in process state, then regardless of process type, it may simply return its State argument.

If a StateFun function crashes or throws an exception, then for gen_server, gen_fsm or gen_statem processes, the original state of the process is unchanged. For gen_event processes, a crashing or failing StateFun function means that only the state of the particular event handler it was working on when it failed or crashed is unchanged; it can still succeed in changing the states of other event handlers registered in the same gen_event process.

If the callback module exports a system_replace_state/2 function, it will be called in the target process to replace its state using StateFun. Its two arguments are StateFun and Misc, where Misc is the same as the Misc value returned by get_status/1,2. A system_replace_state/2 function is expected to return {ok, NewState, NewMisc} where NewState is the callback module's new state obtained by calling StateFun, and NewMisc is a possibly new value used to replace the original Misc (required since Misc often contains the callback module's state within it).

If the callback module does not export a system_replace_state/2 function, replace_state/2,3 assumes the Misc value is the callback module's state, passes it to StateFun and uses the return value as both the new state and as the new value of Misc.

If the callback module's system_replace_state/2 function crashes or throws an exception, the caller exits with error {callback_failed, {Module, system_replace_state}, {Class, Reason}} where Module is the name of the callback module and Class and Reason indicate details of the exception. If the callback module does not provide a system_replace_state/2 function and StateFun crashes or throws an exception, the caller exits with error {callback_failed, StateFun, {Class, Reason}}.

The system_replace_state/2 function is primarily useful for user-defined behaviours and modules that implement OTP special processes. The gen_server, gen_fsm, gen_statem and gen_event OTP behaviour modules export this function, and so callback modules for those behaviours need not supply their own.

This function makes it possible to install other debug functions than the ones defined above. An example of such a function is a trigger, a function that waits for some special event and performs some action when the event is generated. This could, for example, be turning on low level tracing.

Func is called whenever a system event is generated. This function should return done, or a new func state. In the first case, the function is removed. It is removed if the function fails.

Removes a previously installed debug function from the process. Func must be the same as previously installed.

This function orders the process to terminate with the given Reason. The termination is done asynchronously, so there is no guarantee that the process is actually terminated when the function returns.