See attachment 3823 [details] for update log, attached to Bug 9882

The scriplet in the upower package itself is fine.

I have no idea why the script (which is really /usr/share/rpm-helper/add-service) is exiting with status 6, I don't see how that can happen.

These "Failed to issue method call: file exists" messages appear several places in your log, and according to:
https://wiki.archlinux.org/index.php/Systemd_FAQ#Q:_Failed_to_issue_method_call:_File_exists_error

They come from "systemctl enable" and can be fixed by adding the --force option (though it's not clear why a *conflicting* symlink already exists).

This is probably from this line in add-service:
/bin/systemctl --quiet enable $units_to_enable >/dev/null

First of all, the >/dev/null is useless with the --quiet there, which suppresses output to STDOUT (according to the manpage).  Perhaps that should be 2>/dev/null?

This still doesn't explain the exit status of 6.

One thing different about this particular error is "Unit upower.service failed to load" part.  This may be because the service was renamed from upowerd.service in Mageia 2 to upower.service in Mageia 3.  Colin, is there some canonical way to handle a renamed service?  BTW, this led me to that conclusion about the issue:
http://forums.gentoo.org/viewtopic-p-7080174.html

You also had the scriplet failing for apache.  Shlomi Fish fixed the perl-XML-LibXML issue you see there.

Not sure what that liblzma issue is all about (appears during the apache scriplet, as well as several other places).  Maybe liblzma needs to be in urpmi's priority upgrade list, since we're using lzma compression in RPMs?

Other than leaving errors in the log, do these scriplet failures actually adversely affect the the upgrade in any way?

CC: (none) => dmorganec, luigiwalser, thierry.vignaud
Assignee: dmorganec => mageia

The redirection is probably old and predated --quiet or something similar. It could be cleaned but it's also harmless so I won't go in and do housekeeping for now :)

As for unit renames, it's kinda tricky. I think it's likely easier to just handle it in the package itself. It could be that the new unit has an alias or similar and thus the old symlink is actually getting in the way? Dunno, I would have to look more closely to say for sure.

liblzma is often complainy but I don't think it's a real problem. Might be wise to make rpm require a specific version of it tho'.

(In reply to Colin Guthrie from comment #3)
> The redirection is probably old and predated --quiet or something similar.
> It could be cleaned but it's also harmless so I won't go in and do
> housekeeping for now :)

Is the lack of the --force option causing some symlinks to not be properly updated though?  If so, we should fix this.

> As for unit renames, it's kinda tricky. I think it's likely easier to just
> handle it in the package itself. It could be that the new unit has an alias
> or similar and thus the old symlink is actually getting in the way? Dunno, I
> would have to look more closely to say for sure.

How can we handle this in the package?

> liblzma is often complainy but I don't think it's a real problem. Might be
> wise to make rpm require a specific version of it tho'.

That might work.

just add "|| :" at end of line

(In reply to David Walser from comment #2)

> Other than leaving errors in the log, do these scriplet failures actually
> adversely affect the the upgrade in any way?

In addition to the errors in the log, it
generates a pop-up message, blocking the
upgrade until the ok button is selected.

Really not sure why this would cause such an error. The packaging helper scripts should be such that upower will not be activated unless it is a new install. 

I wonder if upower was pulled in as a suggestion or a require and thus it was a fresh install? This, combined perhaps with the fact that the unit itself contains a "Documentation" directive which the older systemd doesn't recognise could mean that the unit failed to load and be enabled? This doesn't seem to stand up to my test here where Documentation directive is just happily ignored.

But either way, the rename of the unit should be handled better but I still don't see why this actually fails without some kind of more complex local setup issue, perhaps left over from mga1->mga2 upgrade?

OK, this is making more sense now, as I had forgotten that a bash script process will have an exit status of the last command that was run in the script.

I don't know exactly which of the commands in the add-service script is causing this, but it's likely one of the systemctl commands (and Colin might know what exit status 6 from that means).

A short term fix would be to add a "|| :" at the end of the _post_service line as Thierry suggested, but really, that should be done at the end of every line in the add-service script that could be the last command called and that we don't want a non-zero exit status to cause the whole script to have a non-zero exit status.  There's already one in at least one of the commands near the end of the script (but because of all of the if's in there, there's a lot of commands that could be the last one run).

What's really confusing is that I cannot see how this *could* occur. Especially not on upgrade. On upgrade nothing specific is done unless migrating from sysvinit, but we don't do that in this case.... Oh... hmmm, thought... perhaps it's related to the lack of a /var/lib/rpm-helper stuff.

Because I'm now using the rpm-helper commands it'll trigger the "migration" from sysvinit but for upower there never was anything to migrate.

Due to the lack of a sysvinit script it *should* just result in enable_targets being empty and then any code relating to systemctl enable etc not being run.

I really can't see how this could happen unless some links exist in /etc/init.d/rc3.d/S??upower which AFAICT there cannot be.

So I'm still confused that this error even showed up.

It also did not show up for my mga2->mga3 migration with upower installed. I'd be tempted to call this an anomaly unless it can be reproduced.

Has anyone other than Dave seen this happen?

*addendum: my upgrade log cleverly doesn't include stderr :( So it *may* have occurred on my upgrade also. I cannot say for sure. I'll check on another machine I'll have to upgrade soon.

I did see it too

Cool. I'm still confused as to why it happens tho'. I'll try and reproduce in a VM to get a proper understanding as masking the error seems wrong.

OK, it's apparently the try-restart bit that fails. No idea as I can't see how a "file exists" error could result.

A fix is simply to rm the enabling symlink and then recreate it again afterwards (under it's new name).

I'm not totally convinced this is needed anyway (as it'll be spawned by dbus) but meh.

Fix committed.

Status: NEW => RESOLVED
Resolution: (none) => FIXED

We really should wait until packages are pushed before marking bugs FIXED.