The known issues with Solaris Management Console (SMC) are listed in the following sections.
If the machine on which the SMC server is running does not have sufficient swap space and the Java garbage collector is not given enough time to release allocated memory, the servlet may run out of memory and cause a segmentation fault.
As a result, all client machines disappear and the initial server remains with a red slash through it, indicating that it is not available.
Workaround: To resume, become superuser and restart the SMC servlet by executing these commands:
/etc/init.d/ehttpd stop
/etc/init.d/ehttpd start
This problem can be avoided by spacing authentication requests far enough apart to allow the Java garbage collector to do its work, adding sufficient swap space, or periodically restarting the servlet or rebooting the machine.
If multiple clients are accessing the same SMC server, and one of the clients updates the SMC registry on the server, the others will not be notified of the change. SMC displays only the old registry information in the Applications View and SMC Server View. This display causes Already exists errors to be reported to the older clients when they attempt to manually add the same registry changes.
Workaround: Log out and log in again to refresh the SMC client display.
SMC uses smc_console as its pam service name when SMC calls pam_start(). The default /etc/pam.conf file does not have an entry for the smcconsole service. This causes pam to correctly use the pam module other in pam.conf, which refers to the pam_unix module.
Applications that are registered with Solaris Management Console to be launched with user, root, or group 14 permission can have their SMC registry information modified or removed by any user.
Workaround: None
When running SMC client on a remote xhost, launched applications may not be displayed.
Workaround: Add each remote server to your X authorization list, for example xhost + .