Bug 1662278

Lili,

Do you happen to have an esx 7.7 vm that I can test my build on?

Thanks

(In reply to Cathy Avery from comment #2)
> Lili,
> 
> Do you happen to have an esx 7.7 vm that I can test my build on?
> 
> Thanks

@Cathy, as only have nightly build for RHEL7.7 ,I will prepare one nightly RHEL7.7 for you, and send the detail info to you via mail.

From berrange@redhat.com

@ pengpengs@vmware.com please respond.

> @Cathy,
> 
> I still sugeest keep “DefaultDependencies=no” to vmtoolsd.service file.
> There is no need this flag in cloud-init-local.service. 
> With this flag and “before=cloud-init-local.service” flag in
> vmtoolsd.service, they makes sure vmtoolsd service start before
> cloud-init-local.service, this is necessary for cloud-init based guest os
> customization.

This doesn't really make sense. 

'Before=cloud-init-local.service' should be sufficient for vmtoolsd.service to be started before cloud-init-local.service.

The effect of the default behaviour (aka DefaultDependancies=yes) is merely to add an After=sysinit.target / Before=shutdown.target - these are very early targets. So this wouldn't invalidate the Before=cloud-init-local.service dependancy

[man systemd.service]
   Default Dependencies
       The following dependencies are added unless DefaultDependencies=no is set:

       ·   Service units will have dependencies of type Requires= and After= on sysinit.target, a
           dependency of type After= on basic.target as well as dependencies of type Conflicts= and
           Before= on shutdown.target. These ensure that normal service units pull in basic system
           initialization, and are terminated cleanly prior to system shutdown. Only services
           involved with early boot or late system shutdown should disable this option.
[/man]

So setting DefaultDependencies=no  just removes the After=sysinit.target. 

> Without it, the test may or may not work since systemd services are randomly
> starting during boot.

services aren't started randomly. They are started according to the declared dependencies. If there is no dependency between 2 units, they can be started in parallel. Since vmtoolsd.service declared Before=cloud-init-local.service, it will be started before cloud-init-local.service. It can be started in parallel with any other services. Setting DefaultDependancies=no will actually *increase* parallelism potentially since it is removing a dependancy which permits (but doesn't guarantee that) vmtoolsd.service be started even earlier.

(In reply to Cathy Avery from comment #4)
Hi Cathy,

AFAIK, cloud-init-local.service starts very early and I just checked the unit of it. There are "DefaultDependencies=no", "Before=sysinit.target" and "Before=shutdown.target".

So if we remove "DefaultDependencies=no" from vmtoolsd.service, and with "Before=cloud-init-local.service", it might introduce cycle dependencies.

If there are no blocks for RHEL, still suggest keep "DefaultDependencies=no" to vmtoolsd.service.

Thanks,
Pengpeng

(In reply to Pengpeng Sun from comment #5)
> (In reply to Cathy Avery from comment #4)
> Hi Cathy,
> 
> AFAIK, cloud-init-local.service starts very early and I just checked the
> unit of it. There are "DefaultDependencies=no", "Before=sysinit.target" and
> "Before=shutdown.target".
> 
> So if we remove "DefaultDependencies=no" from vmtoolsd.service, and with
> "Before=cloud-init-local.service", it might introduce cycle dependencies.

Yes, it cloud-init-local.service has DefaultDependancies=no, then vmtoolsd.service MUST have the same otherwise the dependencies are mutually incompatible.

Fix included in open-vm-tools-10.3.0-2.el7

Verified this bug on RHEL7.7.
[root@bootp-73-199-103 ~]# uname -r
3.10.0-1034.el7.x86_64
[root@bootp-73-199-103 ~]# rpm -qa |grep open-
open-vm-tools-10.3.0-2.el7.x86_64

The Before=cloud-init-local.service had add to vmtoolsd.service file.

cat /lib/systemd/system/vmtoolsd.service
[Unit]
Description=Service for virtual machines hosted on VMware
Documentation=http://github.com/vmware/open-vm-tools
ConditionVirtualization=vmware
Requires=vgauthd.service
After=vgauthd.service
DefaultDependencies=no
Before=cloud-init-local.service

[Service]
ExecStart=/usr/bin/vmtoolsd
TimeoutStopSec=5

[Install]
WantedBy=multi-user.target
Also=vgauthd.service

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2019:2139