zypper exit code - 102 doesn't occur


I am writing a background update script that is started by systemd-timers. It would be an internal replacement for the yast2 method to be more homogeneous between many Leap and Tumbleweed (client) installations.
According to the documentation, when a reboot is required, zypper should exit with the code “102”. This is necessary because I would generate a GUI notification in this case. But it doesn’t seem to work.

After manually updating systemd or kernel (for testing purposes), I always get “0” back at “$?”. “105” if I cancel the update, which is correct and expected.

Any advice?

           Returned after a successful installation of a patch which requires reboot of computer.

Is it really the difference between “patch” and “update/upgrade”?

Best and thx a lot,

That sort of process on multiple machines sounds fraught with danger… :wink: If lots of machines, why not consider salt or other management ways, eg staging updates etc?

If it’s not returning the correct exit code, I would assume it’s a bug and worth reporting: openSUSE:Submitting bug reports - openSUSE

I don not know the answers, but can tell what I think about the semantics of Patch and Update. It is a bot confusing, but as I understand it (from the zypper man page), those things that come from the Update repositories (Oss-Update and non-OSS-Update) are Patches . You will install patches when you do:

  • zypper patch;
  • zypper up (which may include more e.g. from Packman).

According to this theory, when you do a zypper up, you will also install patches and thus in theory you should get a return code of 102 when e.g. a new kernel is involved (as you assume).

I normally use YaST > Software > Online Update (equivalent to zypper patch), which shows pop-up windows before starting a the process to inform that a reboot asap is required) giving the oportunity to bail out) and after finishing (as a reminder). This means that the correct information is available in the RPMs. BTW, I can not remember to have seen this for systemd, only for the kernel.

So, when you can prove that the return code is not set correctly in these cases, a bug report may be needed.

malcolmlewis, hcvv,

thx for your feedback. :slight_smile:
I think everyone could reproduce that as following:

mlsuse:~ # zypper in -f systemd
Loading repository data...
Reading installed packages...
Forcing installation of 'systemd-234-lp152.31.25.1.x86_64' from repository 'Main Update Repository'.
Resolving package dependencies...

The following package is going to be reinstalled:

The following package requires a system reboot:

1 package to reinstall.
Overall download size: 2.5 MiB. Already cached: 0 B. No additional space will be used or freed after the operation.

    Note: System reboot required.
Continue? [y/n/v/...? shows all options] (y): 

mlsuse:~ # echo $?

Shouldn’t we get 102 back instead of 0?

I’ve never heard about this (https://github.com/saltstack/salt ?). But anyway, I know cdist or ansible for example. But in my opinion, “update logic” should working independent and without a single point of failure. Also, clients can be turned off or traveling around the globe. Ansible, cdist and may be others are more straight forward for server farm purposes.
Why do you think that’s very dangerous? Are updates from openSUSE not stable or zypper/yast powerful enough?
Sure, in respect of tumbleweed’s dist-upgrade, that’s another story (and wouldn’t be the default system).
But, I will check out their documentation. Thanks a lot. :wink:

I know about the difference between patch, update and upgrade. But you’re right! “zypper up” do patches as well.
Therefore 102 should be triggered anyway.


I would say what you posted above should be enough to put into a bug report.
https://bugzilla.opensuse.org/index.cgi same credentials as here.

Please post the URL of the report you made. Then those who are interested can follow (and maybe add to) it.

Just rolling out automatic updates without some sort of review, with Tumbleweed at least there is the snapshot notification and if something is broken folks post on the Mailing list pretty quick :wink:

With some sort of staging process it gives you a chance to review, check then deploy… AFAIK RMT could also do this for you to deploy out to systems wherever they may be…

Let’s see…
…what the experts say…

Thanks for your time again.
I will update this topic as soon as there are news.

Nicely done. Let us wait.

Nice response time there…
Just a couple of hours later, I got a very helpful answer regarding my problem. I like that. :slight_smile: :good:

The information whether one or more packages needs a reboot is stored in the function ‘zypper needs-rebooting’. In scripts I can do the following:

zypper -q needs-rebooting
echo $?

…which is then 0 or 102.

Just for the sake of completeness:


OT: Isn’t there any resolved button or behavior here? Sorry if I missed that in the FAQ.

You expressed your satisfaction with how it has gone. That is enough.