[systemd-devel] Fail to reset-failed as user

[Lennart Poettering]

On Thu, 05.02.15 19:20, Olivier Brunel (jjk at jjacky.com) wrote:

> On 02/03/15 22:17, Lennart Poettering wrote:
> > On Fri, 12.12.14 16:06, Olivier Brunel (jjk at jjacky.com) wrote:
> > 
> > Sorry for resurrecting this old thread this late. Is this still an
> > issue? Does this work on current git?
> 
> Still an issue w/ 218 yes, haven't actually had time to try with current
> git. I'll try to do that over the weekend.
> 
> >> Today I had one unit in failed state, and after taking care of things I
> >> wanted to simply reset its state (to inactive) w/out having to start it.
> >>
> >> Looking up the man page, I see there's a command reset-failed for this
> >> exact purpose, awesome. So I go:
> >>
> >> % systemctl reset-failed backups2.service
> >> Failed to reset failed state of unit backups2.service: No such device or
> >> address
> > 
> > Hmm, did you issue this from some weird environment (su/sudo context,
> > from a system service context or so?)
> > 
> > If this is still an issue, could you try to reproduce this after
> > issuing "systemd-analyze set-log-level debug"? Then please attach the
> > log output this generates!
> 
> Meanwhile, this is what I get today: http://ix.io/gaR
> This is not from some weird environment no (or, not that I'm aware of),
> but an (almost) up-to-date Arch Linux x64, systemd 218.

Puzzled. Don't see how this can happen. Also, works fine here...

If you can reproduce this on git, it would be good to gdb this. For
that:

a) start gdb, type "attach 1", to attach to PID 1

b) add a breakpoint on method_reset_failed_unit, by issuing "b
   method_reset_failed_unit"

c) Continue execution of PID 1, by typing in the line "c"

d) trigger the issue, gdb should break at that instant. 

e) now, check which call fails by stepping through the function with
   "n". As soon as the function is left, use "c" to continue
   execution. Not that the function will be executed twice, one after
   the other. The first invocation will be without PolicyKit privs,
   the second one with PolicyKit privs. The second invocation is the
   interesting one. Check why it exits non-zero, and whether
   unit_reset_failed() is invoked at all (which actually does the
   inetersting work).

f) post your findings here

g) leave gdb again with ^D

Don'd do much more than this at the same time. Since you stop
execution of PID 1 a lot of things will be slow and potentially time
ut while you run all this.

Thanks,

Lennart

-- 
Lennart Poettering, Red Hat