Bug 767611

Created attachment 546739 [details]
Native systemd service file for bmc-watchdog

Created attachment 546740 [details]
Native systemd service file for ipmidetectd

Have you tried these unit files? I doubt about 'Type=oneshot', both ipmidetect and bmc-watchdog are forking daemons.

Created attachment 550731 [details]
Native systemd unit for bmc-watchdog.service type forking

Created attachment 550737 [details]
Native systemd unit for ipmidetectd type forking

(In reply to comment #3)
> Have you tried these unit files? I doubt about 'Type=oneshot', both ipmidetect
> and bmc-watchdog are forking daemons.

Hum did not look at their source code to check them. 

I simply dont have time to both convert and run upstream to properly check code and thoroughly test everything we still got ca 300 components to go.

Of those ca 300 we have 100 components which have 100+ units files to them which are stuck in bugzilla and thus aren't receiving any feedback/testing et all from the community and many of the packagers/maintainers of those components seem to be absent.

I have not enacted the non responsive maintainers policy on those maintainers since I dont have time for that either and that process is way to long. 

Those components would need to be removed from the distribution or have new maintainers no later then alpha to make any difference from my pov.

Those non-responsive maintainers are inadvertently delaying the next phase in the systemd migration as in the various clean up phase for those unit's submitted <F16  which by the current migration speed probably winds up to be an F20+ feature.  

+ I cant properly test this since I dont have any IPMI hw. 

Anyway added Type forking version of the unit files but still feel that there is something amiss with the daemons it's like they are exiting cleanly when they should not and aren't properly forking but anyway you are the maintainer and are familiar with the daemons and their code and have the necessary hw to test these so try those units see if they work. 

The sooner you push the unit files into rawhide the more testing and feedback they will receive before GA.

Jóhann, don't get me wrong, I appreciate the work you are doing and I understand your frustration, I was just curious if I miss something or the unit files were just bad.

Regarding testing HW, it's quite interesting problem. We as company have plenty of IPMI enabled HW here, but I don't know any which runs Fedora... I'll try to find some. Anyway, I'll try to provide native unit files for F17.

(In reply to comment #7)

> Regarding testing HW, it's quite interesting problem. We as company have plenty
> of IPMI enabled HW here, but I don't know any which runs Fedora... I'll try to
> find some. Anyway, I'll try to provide native unit files for F17.

If you can manage to package them that would be great we are that early in the release cycle thus we should be able to let testers/users catch any bugs that may come out of it.

Given the relative simplicity of the unit files fixes to them are usually just one liners...

The way how freeipmi daemons start confuse systemd, I sent a patch upstream: http://lists.gnu.org/archive/html/freeipmi-devel/2012-01/msg00001.html

Hum...

Did you try adding "Before=bmc-watchdog.service" to the ipmidetectd.service
And ipmidetectd.service to the After line as in "After=network.target ipmidetectd.service" to the bmc-watchdog.service

And still experienced the race condition?

Yes. These two daemons are independent, the race is between two processes of one daemon, not between two daemons. Anyway, upstream accepted my patches:
http://svn.savannah.gnu.org/viewvc?view=rev&root=freeipmi&revision=8299