NAME
nis_ping, nis_checkpoint — misc NIS+ log administration functions
SYNOPSIS
cc
[ flag... ] file...
-lnsl
[ library... ]
#include <rpcsvc/nis.h>
void nis_ping(const nis_name dirname,
const u_long utime,
const nis_object *dirobj);
nis_result *nis_checkpoint(const nis_name dirname);
DESCRIPTION
nis_ping()
is called by the master server for a directory
when a change has occurred within that directory.
The parameter
dirname
identifies the directory with the change.
If the parameter
dirobj
is
NULL,
this function looks up the
directory object for
dirname
and uses the list of replicas it contains.
The parameter
utime
contains the timestamp of the last
change made to the directory.
This timestamp is used by the replicas
when retrieving updates made to the directory.
The effect of calling
nis_ping()
is to schedule an update on the replica. A short time after a ping
is received, typically about two minutes, the replica compares
the last update time for its databases to the timestamp sent by the ping.
If the ping timestamp is later,
the replica establishes a connection with the master
server and requests all changes from the log that occurred after the
last update that it had recorded in its local log.
nis_checkpoint()
is used to force the service to checkpoint
information that has been entered in the log but has
not been checkpointed to disk.
When called, this function checkpoints the database for each table in
the directory, the database containing the directory
and the transaction log.
Care should be used in calling this function since directories
that have seen a lot of changes may take several minutes to checkpoint.
During the checkpointing process,
the service will be unavailable for updates for all directories
that are served by this machine as master.
nis_checkpoint()
returns a pointer to a
nis_result
structure (described in
nis_tables(3N)).
This structure should be freed with
nis_freeresult()
(see
nis_names(3N)).
The only items of interest in the returned result are
the status value and the statistics.
MULTITHREAD USAGE
- Thread Safe:
Yes
- Cancel Safe:
Yes
- Fork Safe:
No
- Async-cancel Safe:
No
- Async-signal Safe:
No
These functions can be called safely in a multithreaded environment. These
functions may be thread cancellation points because they invoke functions
that are thread cancellation points.
In a multithreaded environment, these functions are
not safe to be called by a child process after
fork()
and before
exec().
These functions should not be called by a multithreaded application
that support asynchronous cancellation or asynchronous signals.
