SLES 11 SP3 - Network Connection dialog box not exiting


Been having an issue with SLES 11 SP3 recently; performed an in-place upgrade from SP2 and the system works fine (from what I can tell) except for one item. When the Network Settings config tool is launched from Yast2, I can make all the changes I like, hit ok and the config tool window pops back open, even if I hit Abort while it’s starting, Close while it’s up or Ok. All of the config changes made to the NIC will be committed but the window will not stay closed; it appears to close and then the process re-starts itself. Effectively, once opened, the Network Settings config tool wants to stay open.

If anyone has any insights into this item, I would appreciate them immensely. Also, if I missed a post in the search of the forum, my apologies ahead of time.

Best regards.

Does the same thing happen if you SSH into the box and use the ncurses
version of Yast:

sudo /sbin/yast lan

If this has the same symptom, then perhaps it’s a bug in the backend
causing something to reload when closed.

Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below…

Nice catch, thank you.

/sbin/yast lan exhibits the same behavior as /sbin/yast2 lan. If I cancel out, the config app restarts.

Any ideas or suggestions?

If you are current on patches (not just SP3, but patches on top of SP3)
then I’d probably open an SR. I just tried on an SP3 system of mine and
did not have any issues. My wild guess at a root cause is something
unique about your configuration that causes the process to not exist as
normally as it should, and then the reload. What setting would that be?
No idea. Can you share more about this system? Do you have others, and
do they have the problems (and are they at the same (hopefully latest)
patch level)? Is this SLES 11 SP3 x86_64 or are you using x86_32 or
something for System Z or other architectures?

Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below…

Thanks again for the input, much appreciated.

It’s x86_64 SLES 11 for VMware if that makes a difference. A few notes:

  • behavior persists through reboots/power cycles;
  • this is an in-place upgrade from SLES 11 SP2, accomplished via wagon;
  • saw this happen once before but can not ID the system for cross-referencing configurations. Most in-place upgraded systems I’m handling are not experiencing this behavior;
  • the system exhibiting the behavior has been updated to the latest SP3 patch-level.

Again, thank you.

Hmmmmmmm… well, I still cannot duplicate it so a couple of ideas
to help you progress despite me:

  1. Wait for others to respond. I’m pretty good at SLES, but I do not
    think (in this forum certainly) that I am the best. If magic31 or
    malcolmlewis or others drop in, they may have better ideas.

  2. Perhaps share the contents of your /etc/syconfig/network directory. I
    have never found much useful in the subdirectories, but the ifcfg-*,
    route, and other files in this directory may help reproduce the issue…

  3. Post a supportconfig, which will likely have #2 plus a lot more data.
    This is usually a large file, and it is usually intended for use with a
    Service Request (SR) with SUSE/Novell/NetIQ more than here, but if you can
    put it somewhere accessible I’ll look through it (as may others seeing
    this thread). Generate one by running ‘supportconfig’ as ‘root’ on your
    server. Feel free to look through the contents yourself too… very
    useful tool and more-useful the more you use it and become familiar with
    what is in there and what is normal.

Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below…


have you had a look at the logs in /var/log/YaST2? It’d be really interesting to see what was recorded there during from when you submitted the changes, 'til the “window” re-opens.


I wanted to first of all thank you both for your input to this item; definitely pointed me in the right direction.

The problem has vanished for the time being after a migration to a new hypervisor. Puzzling. If it resurfaces, I will take a look at the /var/log/Yast2 and supportconfig output.

Again, thank you very much for your time. Vielen Dank.