View Full Version : SLES 12 SP2 YAST Services Manager Error

21-Feb-2017, 00:26
I just updated our SLES12 SP2 server (with XEN) and after rebooting, it has been very sluggish. I started up YAST to check on the running services and I get the following error message

Internal error. Please report a bug report with logs.
Details: Systemctl command failed: Timeout 30 seconds: LANG=C TERM=dumb COLUMNS=1024 systemctl --no-legend --no-pager --no-
Caller: /usr/share/YaST2/lib/yast2/systemctl.rb:29:in `rescue in execute'

At a loss as to what I should do to address this and get teh server back to normal operations.

Automatic Reply
27-Feb-2017, 06:30

It appears that in the past few days you have not received a response to your
posting. That concerns us, and has triggered this automated reply.

These forums are peer-to-peer, best effort, volunteer run and that if your issue
is urgent or not getting a response, you might try one of the following options:

- Visit http://www.suse.com/support and search the knowledgebase and/or check all
the other support options available.
- Open a service request: https://www.suse.com/support
- You could also try posting your message again. Make sure it is posted in the
correct newsgroup. (http://forums.suse.com)

Be sure to read the forum FAQ about what to expect in the way of responses:

If this is a reply to a duplicate posting or otherwise posted in error, please
ignore and accept our apologies and rest assured we will issue a stern reprimand
to our posting bot..

Good luck!

Your SUSE Forums Team

07-Mar-2017, 15:56
Hi Larry,

what about diagnosing this with more simple tools, like

- "vmstat 1" to get current memory/swap/io/cpu information at one-second intervals

- "top" to check for CPU- or memory-intensive tasks

- "iostat -zN 2" (from the sysstat package) to check for I/O

- "dmesg -wT" to see if i.e. the kernel reports on problems

That should give you a first hint at what might be slowing down your system.


08-Mar-2017, 14:09
I ended up calling in an SR on this. The problem was traced to the ZENworks 11 installation on the server - after the updates were applied, it was causing massive swapping. We ended up disabling the ZENworks server services and the problem is not occurring. One of the SLES12 SP2 updates seems to have caused the problem but since I was planning to retire ZENworks from the metal server, this was the quickest solution.

All I need to do now is to move the database to the virtual ZENworks server I have running.


08-Mar-2017, 15:11
Hi Larry,

thank you for reporting back on the found cause. (JFTR: The swapping would have been visible using "vmstat 1")

All I need to do now is to move the database to the virtual ZENworks server I have running.

I guess you'll probably find more answers on that in the Zenworks product forum at https://forums.novell.com/forumdisplay.php/20-ZENworks , as the forums here focus on the base OS.


08-Mar-2017, 16:41
Yeah. I already found some material - just need to find time to actually try it.