This section answers some of the questions you may have regarding the nature and workings of the Configuration Agent along with some tips for troubleshooting problems with the Agent.
The Configuration Agent is a policy caching and delivery application. It was designed and built to ensure that desktop client applications could be centrally configured without significant impact to the performance of these applications and the hosts they run on. This is achieved by:
Caching any downloaded policy in a locally available cache for future client use
Sharing any expensive resources (for example, connections to an LDAP server where policy is hosted ) that can and should be shared
The typical scenario where interaction occurs between client applications and the Configuration Agent is extremely simple and can be described as follows:
A user launches one of the relevant desktop client applications ( gconfd, Mozilla or StarOffice )
The client application connects to the Configuration Agent
The client application requests policy data that it needs from the Configuration Agent
The Configuration Agent searches its cache for the requested policy data
If the policy data is not found in the cache, the Configuration Agent downloads the required data from a pre configured policy repository and stores it in the cache
The policy data is sent to the requesting client application
The Configuration Agent monitors the policy repository for any modifications to policy data
If a modification is detected, the Configuration Agent refreshes its cache so that it is up to date and informs the client application of the modification.
The Configuration Agent is available and installed by default with Solaris 10
The Configuration Agent is disabled and not configured by default. To use the Configuration Agent, you must at least minimally configure it and enable it. Once you've completed these steps, your desktop client applications will automatically start to use any policy you provide when they are next started.
To configure the Configuration Agent correctly, use the Configuration Agent Wizard. You can start the wizard by executing (as root) the command /usr/bin/apoc-config. The wizard guides you through the steps required to correctly configure the agent. In most cases, the only piece of information you absolutely need to complete the wizard is the location of your policy repository.
It is also possible to configure the Configuration Agent by manually editing its configuration files. This is not recommended as it is far easier to incorrectly configure the Agent this way. Additionally, the Configuration Agent Wizard contains additional logic which determines whether or not a particular configuration change requires a restart or a reload of the Agent.
There are three possible mechanisms you can use to enable the Agent:
Using the Configuration Agent Wizard ( /usr/bin/apoc-config), set the Agent State to Active.
Using the Configuration Agent controller program ( /usr/lib/apoc/apocd), execute the following as root:
/usr/lib/apoc/apocd enable |
Using smf(5), execute the following as superuser:
/usr/sbin/svcadm enable svc:/network/apocd/udp |
The easiest way to know if the Configuration Agent is correctly configured and working is to create a policy with the Desktop Manager, assign the policy to a user, login to the desktop machine as that user and verify that the policy settings you made are being used. There are many policy settings which are easily detectable in a desktop session, for example, background and theme.
The Configuration Agent is an smf(5) compliant service and, as such, the notion of enabling the Agent comes from smf(5). Once the Agent is enabled, the Agent is ready to provide service. The following actions occur when you enable the Agent:
The Agent starts
Any desktop client applications started after the Agent is enabled can retrieve policy data
The Agent automatically restarts during system boot
You can use one of the following methods to determine if the Configuration Agent is enabled:
Use the controller program for the Configuration Agent. Become super user and type the following command:
/usr/lib/apoc/apocd is-enabled |
If the Agent is enabled, the controller program returns the following message:
Checking Configuration Agent enabled status ... Enabled |
Otherwise, the controller program returns the following message:
Checking Configuration Agent enabled status ... Not enabled |
Use smf(5) to execute the following command:
/usr/bin/svcs svc:/network/apocd/udp:default |
If the Agent is enabled, svcs returns the following message:
STATE STIME FMRI online 8:36:04 svc:/network/apocd/udp:default |
If the Agent is disabled, svcs returns the following message:
STATE STIME FMRI disabled 15:58:34 svc:/network/apocd/udp:default |
If the Agent is in maintenance mode, svcs returns the following message:
STATE STIME FMRI maintenance 8:38:42 svc:/network/apocd/udp:default |
Use one of the following methods to determine if the Configuration Agent is running:
Become superuser and execute the Configuration Agent controller program:
/usr/lib/apoc/apocd status |
If the Agent is enabled, the controller program returns the following message:
Checking Configuration Agent status ... Running |
Otherwise, the controller program returns the following message:
Checking Configuration Agent status ... Not running |
Execute the following command:
/usr/bin/svcs svc:/network/apocd/udp:default |
If the Agent is running, svcs returns the following message:
STATE STIME FMRI online 8:36:04 svc:/network/apocd/udp:default |
If the Agent is not running, svcs returns the following message:
STATE STIME FMRI disabled 15:58:34 svc:/network/apocd/udp:default |
If the Agent is in maintenance mode, svcs returns the following message:
STATE STIME FMRI maintenance 8:38:42 svc:/network/apocd/udp:default |
Execute the following command:
ps -ef | grep apoc |
If the Configuration Agent is running, you should see the following associated Java process in the output of ps:
daemon 29295 29294 0 13:05:22? 0:03 java -Djava.library.path=/usr/lib/apoc -cp /usr/share/lib/apoc/apocd.jar:/usr/s daemon 29294 1 0 13:05:22? 0:00 sh -c java -Djava.library.path=/usr/lib/apoc -cp /usr/share/lib/apoc/apocd.jar: root 29345 28134 0 13:08:59 pts/1 0:00 grep apoc |
You can consult the following log files when you need to troubleshoot a Configuration Agent problem:
smf(5) log files:
The /var/svc/log/network-apocd-udp:default.log file records events that relate to attempts to start and stop specific instances of the Configuration Agent. The file also contains the messages that Configuration Agent controller program, /usr/lib/apoc/apocd, writes to its standard output as well as the output messages for the JVM or the Configuration Agent.
The /var/svc/log/svc.startd.log log file keeps a record of higher level smf(5) events. For example, if multiple failed attempts to start the Configuration Agent occur in quick succession, smf(5) might decide that the Configuration Agent cannot be started. If this occurs, smf(5) places the Configuration Agent in maintenance mode and writes a log entry to that effect.
Both of these log files are typically useful if you experience problems with the Configuration Agent starting.
Configuration Agent logs:
The Configuration Agent writes log messages to log files in the default log directory, /var/opt/apoc/Logs. The "Data Directory" for the Configuration Agent is /var/opt/apoc. You can change the location of this directory with the Configuration Agent Wizard (/usr/bin/apoc-config) application. You can change the granularity of log messages by changing the "Log Level" with the Configuration Agent Wizard. If you think you did not configure the Configuration Agent correctly, or if you are experiencing some other sort of agent failure, use the Configuration Agent Wizard to set the Log Level to "Finest" before you consult the agent log files. This step ensures that you acquire the maximum amount of available logging information.
System logs:
You can also check the /var/adm/messages log file, or the /var/opt/SUNWut/log/messages log file on a SunRay machine to diagnose problems with the Configuration Agent.
smf(5) places the Configuration Agent in maintenance mode when it detects problems with starting or restarting the Agent. If smf(5) fails to start the Agent, it attempts multiple restarts until the Agent startup is successful or smf(5) decides that the Agent cannot be started. In the latter case, smf(5) places the Agent in maintenance mode to indicate to you that you need to address the problems it has encountered. Once you have addressed the problems, you can clear the smf(5) state of the Agent to return to normal operations.
Become superuser and execute the command /usr/sbin/svcadm clear svc:/network/apocd/udp.
smf(5) detects that the Agent has stopped running and tries to restart it. If successive attempts to restart fail for any reason, smf(5) places the Agent in maintenance mode. Running desktop client applications are unaffected if the Agent is restarted successfully. Any such client application reconnects to the Agent automatically when it restarts.
The action that you take actually depends on whether the Agent was enabled/running at the time when the specific desktop client application was started. If the Agent was enabled/running, the client application established a connection to the Agent and tries to reestablish the connection when it is lost. That is, every time you start, enable or disable the Agent, client applications always try to reconnect to the Agent once it's running. If the Agent was not enabled/running when the client application started, the client application does not use the Configuration Agent and does not even attempt to connect when the Agent starts. All this effectively means that:
Desktop client applications that started while the Agent was enabled/running do not need to be restarted.
Desktop client applications that started while the Agent was not enabled/running must be restarted.
The most common problem that relates to the Configuration Agent is the inability to see the effects of a configured policy on desktop client applications. The most common reasons for this problem are an incorrectly configured Agent, an incorrectly configured policy repository or the unavailability of the policy repository. The following guidelines can help you to discover and eliminate such problems:
Ensure that the Agent is configured.
Ensure that the Agent is enabled/running. If you need to start the Agent, you must also restart the desktop client applications that are currently open.
If your problems persist, temporarily increase the granularity of the Agent logging mechanism and, if possible, restart the Agent, so that you have complete and fine grained log messages from the time the Agent starts.
If the Agent fails to start correctly, consult the section Problems starting the Configuration Agent.
If the Agent starts correctly but your desktop client applications do not use an available policy, consult the section "Problems getting policy from a running Configuration Agent".
If you are still unable to resolve your problems, please contact Technical Support.
If the Configuration Agent cannot be started and you are satisfied that you have configured and enabled the Configuration Agent, you need to consult the log files. The following sections describe the most common errors for this problem.
The Configuration Agent Data Directory is created and used by the Agent to store log files, policy caches, and so on. The default location for this directory is /var/opt/apoc.
The Configuration Agent produces the following error message in the smf(5) logs when the Data Directory is set to an inaccessible location, that is, /dev/null/cant/write/here. To solve this problem, use the Configuration Agent Wizard (/usr/bin/apoc-config) to point the Data Directory to an accessible location.
[ Nov 17 14:35:38 Executing start method ("/usr/lib/apoc/apocd svcStart") ] Starting Configuration Agent ... Warning: Cannot create Log directory '/dev/null/cant/write/here/Logs' Warning:Failed to create log file handler Nov 17, 2005 2:35:39 PM com.sun.apoc.daemon.misc.APOCLogger config CONFIG: Daemon configuration: MaxRequestSize = 4096 DaemonAdminPort = 38901 ThreadTimeToLive = 5 DaemonChangeDetectionInterval = 10 IdleThreadDetectionInterval = 15 PROVIDER_URL = DataDir = /dev/null/cant/write/here ApplyLocalPolicy = true ChangeDetectionInterval = 60 MaxClientConnections = 50 GarbageCollectionInterval = 10080 InitialChangeDetectionDelay = 10 TimeToLive = 10080 ConnectionReadTimeout = 5000 DaemonPort = 38900 LogLevel = FINEST MaxClientThreads = 5 Nov 17, 2005 2:35:39 PM Daemon main FINER: THROW com.sun.apoc.daemon.misc.APOCException at com.sun.apoc.daemon.apocd.Daemon.initAuthDir(Unknown Source) at com.sun.apoc.daemon.apocd.Daemon.init(Unknown Source) at com.sun.apoc.daemon.apocd.Daemon.<init>(Unknown Source) at com.sun.apoc.daemon.apocd.Daemon.main(Unknown Source) [ Nov 17 14:36:08 Method or service exit timed out. Killing contract 980 ] [ Nov 17 14:36:08 Method "start" failed due to signal KILL ] |
The Configuration Agent uses TCP/IP socket connections to communicate with desktop client applications. By default, these connections are made through port 38900.
The following error message is produced when the Configuration Agent is configured to use port 1234, which is already in use by another service. The error message is recorded in the Configuration Agent Logs. To solve this problem, use the Configuration Agent Wizard (/usr/bin/apoc-config) to change the Agent Port setting to a port number which is not in use.
Nov 17, 2005 2:50:59 PM com.sun.apoc.daemon.misc.APOCLogger config CONFIG: Daemon configuration: MaxRequestSize = 4096 DaemonAdminPort = 38901 ThreadTimeToLive = 5 DaemonChangeDetectionInterval = 10 IdleThreadDetectionInterval = 15 PROVIDER_URL = DataDir = /var/opt/apoc ApplyLocalPolicy = true ChangeDetectionInterval = 60 MaxClientConnections = 50 GarbageCollectionInterval = 10080 InitialChangeDetectionDelay = 10 TimeToLive = 10080 ConnectionReadTimeout = 5000 DaemonPort = 1234 LogLevel = FINEST MaxClientThreads = 5 Nov 17, 2005 2:50:59 PM com.sun.apoc.daemon.misc.APOCLogger info INFO: Daemon starting Nov 17, 2005 2:50:59 PM com.sun.apoc.daemon.misc.APOCLogger fine FINE: Garbage collection scheduled ( interval = 10080 minutes ) Nov 17, 2005 2:50:59 PM Daemon main FINER: THROW com.sun.apoc.daemon.misc.APOCException: java.net.BindException: Address already in use at com.sun.apoc.daemon.transport.ChannelManager.<init>(Unknown Source) at com.sun.apoc.daemon.apocd.Daemon.run(Unknown Source) at com.sun.apoc.daemon.apocd.Daemon.main(Unknown Source) Caused by: java.net.BindException: Address already in use at sun.nio.ch.Net.bind(Native Method) at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:119) at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:59) at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:52) |
The Configuration Agent uses TCP/IP socket connections to communicate with the Configuration Agent controller program (/usr/lib/apoc/apocd). By default, these connections are made through port 38901.
The following error message occurs in the Configuration Agent logs when the Configuration Agent is configured to use port 1234, which is already in use by another service. To solve this problem, use the Configuration Agent Wizard (/usr/bin/apoc-config) to change the Administration Port setting to a port number which is not in use.
ONFIG: Daemon configuration: MaxRequestSize = 4096 DaemonAdminPort = 1234 ThreadTimeToLive = 5 DaemonChangeDetectionInterval = 10 IdleThreadDetectionInterval = 15 PROVIDER_URL = DataDir = /var/opt/apoc ApplyLocalPolicy = true ChangeDetectionInterval = 60 MaxClientConnections = 50 GarbageCollectionInterval = 10080 InitialChangeDetectionDelay = 10 TimeToLive = 10080 ConnectionReadTimeout = 5000 DaemonPort = 38900 LogLevel = FINEST MaxClientThreads = 5 Nov 17, 2005 2:55:11 PM com.sun.apoc.daemon.misc.APOCLogger info INFO: Daemon starting Nov 17, 2005 2:55:11 PM com.sun.apoc.daemon.misc.APOCLogger fine FINE: Garbage collection scheduled ( interval = 10080 minutes ) Nov 17, 2005 2:55:11 PM com.sun.apoc.daemon.misc.APOCLogger fine FINE: Client manager started Nov 17, 2005 2:55:11 PM com.sun.apoc.daemon.misc.APOCLogger fine FINE: Channel manager started Nov 17, 2005 2:55:11 PM Daemon main FINER: THROW com.sun.apoc.daemon.misc.APOCException: java.net.BindException: Address already in use at com.sun.apoc.daemon.admin.AdminManager.initChannel(Unknown Source) at com.sun.apoc.daemon.admin.AdminManager.<init>(Unknown Source) at com.sun.apoc.daemon.apocd.Daemon.run(Unknown Source) at com.sun.apoc.daemon.apocd.Daemon.main(Unknown Source) Caused by: java.net.BindException: Address already in use at sun.nio.ch.Net.bind(Native Method) at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:119) at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:59) at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:52) ... 4 more |
The Configuration Agent needs to connect to a valid configuration repository to download and to cache policy information. If you do not correctly identify the configuration repository in the Agent's configuration, for example, by using an invalid format or by not specifying a repository, errors similar to the following one are recorded in the Configuration Agent logs when desktop client applications start up. To solve this problem, use the Configuration Agent Wizard (/usr/bin/apoc-config) to identify the configuration repository that you want to use.
FINER: New client added Nov 18, 2005 1:59:22 PM com.sun.apoc.daemon.misc.APOCLogger finer FINER: CreateSession transaction started Nov 18, 2005 1:59:22 PM com.sun.apoc.daemon.misc.APOCLogger finer FINER: Creating new client session Nov 18, 2005 1:59:22 PM com.sun.apoc.daemon.misc.APOCLogger finest FINEST: Authenticating user geoffh Nov 18, 2005 1:59:22 PM com.sun.apoc.daemon.misc.APOCLogger finest FINEST: Authentication successful Nov 18, 2005 1:59:23 PM PolicyBackend openPolicyBackend FINER: THROW com.sun.apoc.daemon.misc.APOCException: com.sun.apoc.daemon.misc.APOCException: com.sun.apoc.spi.environment.InvalidParameterException: The parameter organisation PROVIDER_URL#protocol (null) is not valid, the value must be comprised in {ldaps,ldap,https,http,file}. at com.sun.apoc.daemon.apocd.PolicyBackend.<init>(Unknown Source) at com.sun.apoc.daemon.apocd.HostPolicyBackend.<init>(Unknown Source) at com.sun.apoc.daemon.apocd.PolicyBackendFactory.openPolicyBackend(Unknown Source) at com.sun.apoc.daemon.apocd.Cache$DataSource.openPolicyBackend(Unknown Source) at com.sun.apoc.daemon.apocd.Cache$DataSource.open(Unknown Source) at com.sun.apoc.daemon.apocd.Cache.createDataSources(Unknown Source) at com.sun.apoc.daemon.apocd.Cache.<init>(Unknown Source) at com.sun.apoc.daemon.apocd.CacheFactory.createNewCache(Unknown Source) at com.sun.apoc.daemon.apocd.CacheFactory.openCache(Unknown Source) at com.sun.apoc.daemon.apocd.Session.<init>(Unknown Source) at com.sun.apoc.daemon.transaction.CreateSessionTransaction.executeTransaction (Unknown Source) at com.sun.apoc.daemon.transaction.Transaction.execute(Unknown Source) at com.sun.apoc.daemon.apocd.ClientEventHandler.handleEvent(Unknown Source) at com.sun.apoc.daemon.apocd.EventWorkerThread.run(Unknown Source) Caused by: com.sun.apoc.daemon.misc.APOCException: com.sun.apoc.spi.environment.InvalidParameterException: The parameter organisation PROVIDER_URL#protocol (null) is not valid, the value must be comprised in {ldaps,ldap,https,http,file}. at com.sun.apoc.daemon.apocd.PolicyBackendFactory.openPolicyMgr(Unknown Source) ... 14 more Caused by: com.sun.apoc.spi.environment.InvalidParameterException: The parameter organisation PROVIDER_URL#protocol (null) is not valid, the value must be comprised in {ldaps,ldap,https,http,file}. at com.sun.apoc.spi.PolicyMgrFactoryImpl.createPolicyMgr(Unknown Source) ... 15 more Nov 18, 2005 1:59:23 PM PolicyBackend openPolicyBackend |
The Configuration Agent needs to connect to a valid configuration repository to download and cache policy information. If a connection cannot be established, errors similar to the following one are recorded to the Configuration Agent logs when desktop client applications are started. In the following case, the host sobuild does not exist, cannot be contacted, or cannot access an LDAP server through port 389. To solve this problem, use the Agent Configuration Wizard (/usr/bin/apoc-config) to ensure that you have correctly identified the Policy Repository and, if so, to ensure that access to the Policy Repository is available. For example, for an LDAP repository, you need to ensure that an LDAP server is running, the machine hosting the LDAP server is available on the network, and that the port that you specified is the one being used by the LDAP server.
If you are trying to access an LDAP server using an SSL connection, ensure that the proper certificate is available in the key store associated with the Java runtime environment used to run the Configuration Agent. See the section Configuration Agent for more details about apoc-config.
FINER: New client added Nov 18, 2005 2:17:43 PM com.sun.apoc.daemon.misc.APOCLogger finer FINER: CreateSession transaction started Nov 18, 2005 2:17:43 PM com.sun.apoc.daemon.misc.APOCLogger finer FINER: Creating new client session Nov 18, 2005 2:17:43 PM com.sun.apoc.daemon.misc.APOCLogger finest FINEST: Authenticating user geoffh Nov 18, 2005 2:17:43 PM com.sun.apoc.daemon.misc.APOCLogger finest FINEST: Authentication successful Nov 18, 2005 2:17:43 PM PolicyBackend openPolicyBackend FINER: THROW com.sun.apoc.daemon.misc.APOCException: com.sun.apoc.daemon.misc.APOCException: com.sun.apoc.spi.OpenConnectionException: An error occured while connecting to ldap://sobuild:389. at com.sun.apoc.daemon.apocd.PolicyBackend.<init>(Unknown Source) at com.sun.apoc.daemon.apocd.HostPolicyBackend.<init>(Unknown Source) at com.sun.apoc.daemon.apocd.PolicyBackendFactory.openPolicyBackend(Unknown Source) at com.sun.apoc.daemon.apocd.Cache$DataSource.openPolicyBackend(Unknown Source) at com.sun.apoc.daemon.apocd.Cache$DataSource.open(Unknown Source) at com.sun.apoc.daemon.apocd.Cache.createDataSources(Unknown Source) at com.sun.apoc.daemon.apocd.Cache.<init>(Unknown Source) at com.sun.apoc.daemon.apocd.CacheFactory.createNewCache(Unknown Source) at com.sun.apoc.daemon.apocd.CacheFactory.openCache(Unknown Source) at com.sun.apoc.daemon.apocd.Session.<init>(Unknown Source) at com.sun.apoc.daemon.transaction.CreateSessionTransaction.executeTransaction (Unknown Source) at com.sun.apoc.daemon.transaction.Transaction.execute(Unknown Source) at com.sun.apoc.daemon.apocd.ClientEventHandler.handleEvent(Unknown Source) at com.sun.apoc.daemon.apocd.EventWorkerThread.run(Unknown Source) Caused by: com.sun.apoc.daemon.misc.APOCException: com.sun.apoc.spi.OpenConnectionException: An error occured while connecting to ldap://sobuild:389. at com.sun.apoc.daemon.apocd.PolicyBackendFactory.openPolicyMgr(Unknown Source) ... 14 more Caused by: com.sun.apoc.spi.OpenConnectionException: An error occured while connecting to ldap://noSuchHost:389. at com.sun.apoc.spi.ldap.LdapClientContext.prepareConnection(Unknown Source) at com.sun.apoc.spi.ldap.LdapClientContext.connect(Unknown Source) at com.sun.apoc.spi.ldap.LdapConnectionHandler.openAuthorizedContext(Unknown Source) at com.sun.apoc.spi.ldap.LdapConnectionHandler.connect(Unknown Source) at com.sun.apoc.spi.ldap.entities.LdapOrganizationProvider.open(Unknown Source) at com.sun.apoc.spi.PolicyMgrFactoryImpl.createPolicyMgr(Unknown Source) ... 15 more Caused by: netscape.ldap.LDAPException: failed to connect to server sobuild:389 (91); Cannot connect to the LDAP server at netscape.ldap.LDAPConnSetupMgr.connectServer(LDAPConnSetupMgr.java:422) at netscape.ldap.LDAPConnSetupMgr.openSerial(LDAPConnSetupMgr.java:350) at netscape.ldap.LDAPConnSetupMgr.connect(LDAPConnSetupMgr.java:244) at netscape.ldap.LDAPConnSetupMgr.access$0(LDAPConnSetupMgr.java:241) at netscape.ldap.LDAPConnSetupMgr$1.run(LDAPConnSetupMgr.java:179) at java.lang.Thread.run(Thread.java:595) Nov 18, 2005 2:17:44 PM PolicyBackend openPolicyBackend |
Before the Configuration Agent can locate policy data in a Policy Repository, the Policy Repository must be correctly configured. If you specify a non-configured or incorrectly configured Policy repository, errors similar to the following are recorded in the Configuration Agent logs when desktop client applications are started. To solve this problem, please see the section
FINER: New client added Nov 18, 2005 2:36:55 PM com.sun.apoc.daemon.misc.APOCLogger finer FINER: CreateSession transaction started Nov 18, 2005 2:36:55 PM com.sun.apoc.daemon.misc.APOCLogger finer FINER: Creating new client session Nov 18, 2005 2:36:55 PM com.sun.apoc.daemon.misc.APOCLogger finest FINEST: Authenticating user geoffh Nov 18, 2005 2:36:55 PM com.sun.apoc.daemon.misc.APOCLogger finest FINEST: Authentication successful Nov 18, 2005 2:36:55 PM PolicyBackend openPolicyBackend FINER: THROW com.sun.apoc.daemon.misc.APOCException: com.sun.apoc.daemon.misc.APOCException: com.sun.apoc.spi.environment.RemoteEnvironmentException: Error on reading the configuration data on LDAP server ldap://sobuild:389. at com.sun.apoc.daemon.apocd.PolicyBackend.<init>(Unknown Source) at com.sun.apoc.daemon.apocd.HostPolicyBackend.<init>(Unknown Source) at com.sun.apoc.daemon.apocd.PolicyBackendFactory.openPolicyBackend(Unknown Source) at com.sun.apoc.daemon.apocd.Cache$DataSource.openPolicyBackend(Unknown Source) at com.sun.apoc.daemon.apocd.Cache$DataSource.open(Unknown Source) at com.sun.apoc.daemon.apocd.Cache.createDataSources(Unknown Source) at com.sun.apoc.daemon.apocd.Cache.<init>(Unknown Source) at com.sun.apoc.daemon.apocd.CacheFactory.createNewCache(Unknown Source) at com.sun.apoc.daemon.apocd.CacheFactory.openCache(Unknown Source) at com.sun.apoc.daemon.apocd.Session.<init>(Unknown Source) at com.sun.apoc.daemon.transaction.CreateSessionTransaction.executeTransaction (Unknown Source) at com.sun.apoc.daemon.transaction.Transaction.execute(Unknown Source) at com.sun.apoc.daemon.apocd.ClientEventHandler.handleEvent(Unknown Source) at com.sun.apoc.daemon.apocd.EventWorkerThread.run(Unknown Source) |
Each desktop client application (gconfd, Mozilla, StarOffice) that is enabled by the Configuration Agent opens a connection to the Configuration Agent when it runs. The limit of such connections is specified in the configuration of the Agent. The default limit for connections is 50. On a machine with multiple users, you might have to increase this limit by changing the “Maximum Client Connections” settings with the Configuration Agent Wizard (/usr/bin/apoc-config). If the Configuration Agent reaches the maximum number of connections, error messages similar to the following one are recorded in Configuration Agent logs:
Nov 18, 2005 3:20:55 PM com.sun.apoc.daemon.misc.APOCLogger warning WARNING: The maximum number of client connections ( 50 ) has been reached. No new client connections can be established at this time. |
One of the assumptions made when designing the Configuration Agent is that policy data created by the Desktop Manager is relatively static, that is, not subject to frequent change. This assumption results in an approach where the Agent intermittently consults the Policy Repository to see if modifications have occurred. By default, the Agent checks the repository once an hour for all running desktop applications. As a result, when you make a change with the Desktop Manager, you need to wait up to one hour before running desktop applications are notified of the change. If you want, you can use the Agent Configuration Wizard (/usr/bin/apoc-config) to change the value of the "General Detection Interval" to increase the frequency of repository checks. Alternatively, you can force the Configuration Agent to refresh policy data for all connected applications by becoming superuser and executing the /usr/lib/apoc/apocd change-detect command.