17 Troubleshooting

The next step you take will depend on the Operating System of the clone.

The following scenario can occur after on-boarding cloned Salt minions. If after accepting all cloned minion keys from the onboarding page and you see only one minion on the System Overview page, this is likely due to these machines being clones of the original and using a duplicate machine-id. Perform the following steps to resolve this conflict based on OS.

If your machines still have the same minion id then delete the minion_id file on each minion (FQDN will be used when it is regenerated on minion restart):

# rm /etc/salt/minion_id

Finally delete accepted keys from Onboarding page and system profile from SUSE Manager, and restart the minion with:

# systemctl restart salt-minion

You should be able to re-register them again, but each minion will use a different '/etc/machine-id' and should now be correctly displayed on the System Overview page.

This section provides guidance on troubleshooting cloned traditional systems registered via bootstrap.

The next step you take will depend on the Operating System of the clone.

This section provides answers for typical issues regarding OSAD and jabberd.

Starting spacewalk services...
   Initializing jabberd processes...
       Starting router                                                                   done
       Starting sm startproc:  exit status of parent of /usr/bin/sm: 2                   failed
   Terminating jabberd processes...

jabberd/sm[31445]: starting up
jabberd/sm[31445]: process id is 31445, written to /var/lib/jabberd/pid/sm.pid
jabberd/sm[31445]: loading 'db' storage module
jabberd/sm[31445]: db: corruption detected! close all jabberd processes and run db_recover
jabberd/router[31437]: shutting down

spacewalk-service stop
 rm -Rf /var/lib/jabberd/db/*
 spacewalk-service start

rcosa-dispatcher stop
 rcjabberd stop
 cd /var/lib/jabberd/db
 rm *
 cp /usr/share/doc/packages/jabberd/db-setup.sqlite .
 sqlite3 sqlite.db < db-setup.sqlite
 chown jabber:jabber *
 rcjabberd start
 rcosa-dispatcher start

The spacewalk-report command is used to produce a variety of reports for system administrators. These reports can be helpful for taking inventory of your entitlements, subscribed systems, users, and organizations. Using reports is often simpler than gathering information manually from the SUSE Manager Web UI, especially if you have many systems under management.

Note: spacewalk-reports Package

To use spacewalk-report, you must have the spacewalk-reports package installed.

spacewalk-report allows administrators to organize and display reports about content, systems, and user resources across SUSE Manager. Using spacewalk-report, you can receive reports on:

spacewalk-report allows administrators to organize and display reports about content, systems, and user resources across SUSE Manager. To get the report in CSV format, run the following at the command line of your SUSE Manager server.

spacewalk-report report_name

The following reports are available:

For more information about an individual report, run spacewalk-report with the option --info or --list-fields-info and the report name. The description and list of possible fields in the report will be shown.

For further information on program invocations and options, see the spacewalk-report(8) man page as well as the --helpparameter of the spacewalk-report.

RPC connection timeouts are configurable on the SUSE Manager server, SUSE Manager Proxy server, and the clients. For example, if package downloads take longer then expected, you can increase timeout values. spacewalk-proxy restart should be run after the setting is added or modified.

Set the following variables to a value in seconds specifying how long an RPC connection may take at maximum:

In some cases, updates are available in the web interface, but not appearing on the client. If you schedule an update on the client, it will fail with an error stating that no updates are available. This can be caused by a metadata regeneration problem, or because update packages have been locked.

The notice that updates are available will appear immediately, but new metadata is only generated on the server after synchronizing. In this case, an inconsistency can occur if taskomatic crashes, or because taskomatic is still running and creating new metadata.

To address this issue, check the /var/log/rhn/rhn_taskomatic_daemon.log file to determine if any processess are still running, or an exception which could indicate a crash. In the case of a crash, restart taskomatic.

Check package locks and exclude lists to determine if packages are locked or excluded on the client:

On Expanded Support Platform, check /etc/yum.conf and search for exclude=.

On SUSE Linux Enterprise Server, use the zypper locks command.

If the information in /var/cache/rhn/repodata/sles12-sp4-updates-x86_64 becomes out of date, it will cause problems with updating the server. The repository data file can be regenerated using the spacemd command:

Some older bootstrap scripts will will create a link to the local certificate in the wrong place, which can cause problems with zypper returning an Unrecognized error about the local issuer certificate. In this case, ensure that the link to the local issuer certificate has been created in /etc/ssl/certs/, and consider updating your bootstrap scripts.