Bug 1071453

*** Bug 1069245 has been marked as a duplicate of this bug. ***

Reproducer:

# tuned-adm profile virtual-host & service tuned start

This is not regression, the problem seems to be there since the beginning of the tuned project, but I am going to fix it.

Also another thing I noticed during the overview of the ovirt-host-deploy log, you shouldn't (IMHO) mix upstart and sysvinit commands, i.e.: 

execute-output: ('/sbin/initctl', 'status', 'tuned')

This is asking about status of the upstart job, so for sysvinit service it will always return:
initctl: Unknown job: tuned

So next you are starting the service (now using the sysvinit syntax):
execute: ('/sbin/service', 'tuned', 'start')
even if the service is already started. This applies not only to tuned but also to other sysvinit services. Starting already started service should be harmless in most cases, but redundant.

(In reply to Jaroslav Škarvada from comment #4)
> Reproducer:
> 
> # tuned-adm profile virtual-host & service tuned start
> 
> This is not regression, the problem seems to be there since the beginning of
> the tuned project, but I am going to fix it.

Great. We are using same sequence since rhel-6.4 (2012-12-27), and have not experienced issue... up to after rhel-6.5... so it is strange... :)

(In reply to Jaroslav Škarvada from comment #5)
> Also another thing I noticed during the overview of the ovirt-host-deploy
> log, you shouldn't (IMHO) mix upstart and sysvinit commands, i.e.: 
> 
> execute-output: ('/sbin/initctl', 'status', 'tuned')

Right, unfortunately we have mixed mode services and should prefer upstart if available, so this failure is expected.

> So next you are starting the service (now using the sysvinit syntax):
> execute: ('/sbin/service', 'tuned', 'start')
> even if the service is already started. This applies not only to tuned but
> also to other sysvinit services. Starting already started service should be
> harmless in most cases, but redundant.

Correct... instead of asking for status and start, we start. Simpler code path.

So is something blocking this getting fixed?

I fail to see where the problem is. Maybe someone could enlighten
me and everyone who wants to deploy RHEL 6.5 based Hosts :)

(In reply to Sven Kieske from comment #8)
> So is something blocking this getting fixed?
> 
Unfortunately the reproducer from comment 4 is not reproducer for this bug (it reproduces similar problem). I noticed this later.

I think I know where the original problem is. I will provide scratch build for testing, because I am unable to reproduce the original problem.

(In reply to Alon Bar-Lev from comment #6)
> (In reply to Jaroslav Škarvada from comment #4)
> > Reproducer:
> > 
> > # tuned-adm profile virtual-host & service tuned start
> > 
> > This is not regression, the problem seems to be there since the beginning of
> > the tuned project, but I am going to fix it.
> 
> Great. We are using same sequence since rhel-6.4 (2012-12-27), and have not
> experienced issue... up to after rhel-6.5... so it is strange... :)

Could you provide me version number of tuned which worked for you? I am afraid the problem was there all the time (but could manifest itself with much lower probability), and the probability was amplified by the latest update.

Can't reproduce with tuned from RHN and even with tuned from brew.

I tried with (based on alonbl@ tip):

- while true; do service tuned stop ; service tuned start ; tuned-adm profile virtual-host; done
- while true; do service tuned stop; service messagebus stop ; service messagebus start; service tuned start ; tuned-adm profile virtual-host ; done

(In reply to Jiri Belka from comment #13)
> Can't reproduce with tuned from RHN and even with tuned from brew.
> 
> I tried with (based on alonbl@ tip):
> 
> - while true; do service tuned stop ; service tuned start ; tuned-adm
> profile virtual-host; done
> - while true; do service tuned stop; service messagebus stop ; service
> messagebus start; service tuned start ; tuned-adm profile virtual-host ; done

Thanks, this is one of the reproducers that I have been trying, but I also haven't been successful in reproducing the problem. I think the only way is to try to re-provision the affected machine.

Lukas - can you approve you tested the scratch build and it's reproducible on qe environment?

I reverted provided WA [1], and we were experiencing same problem during night.
Notice that it doesn't occur every run, I mean it is not 100% reproducible.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1069119#c8

(In reply to Lukas Bednar from comment #16)
> I reverted provided WA [1], and we were experiencing same problem during
> night.
> Notice that it doesn't occur every run, I mean it is not 100% reproducible.
> 
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1069119#c8

Build from comment 12 adds locking to places that could cause deadlocks. No idea what else is wrong, could you provide simple reproducer?

You could also try running tuned with --debug option, just append --debug to line containing:
daemon $exec -d -c $config
i.e.:
daemon $exec -d -c $config --debug

in /etc/init.d/tuned
Maybe verbose logging would reveal something useful.