Bug 1662278 - [ESXi][RHEL7.7]Enable cloud-init by default to change the systemd unit file vmtoolsd.service
Summary: [ESXi][RHEL7.7]Enable cloud-init by default to change the systemd unit file v...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: open-vm-tools
Version: 7.6
Hardware: Unspecified
OS: Unspecified
high
medium
Target Milestone: rc
: ---
Assignee: Cathy Avery
QA Contact: ldu
URL:
Whiteboard:
Depends On: 1644335 1660713
Blocks: 1623281
TreeView+ depends on / blocked
 
Reported: 2018-12-27 09:50 UTC by ldu
Modified: 2019-08-06 12:57 UTC (History)
13 users (show)

Fixed In Version: open-vm-tools-10.3.0-2.el7
Doc Type: If docs needed, set a value
Doc Text:
Clone Of: 1660713
Environment:
Last Closed: 2019-08-06 12:57:03 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2019:2139 None None None 2019-08-06 12:57:13 UTC

Comment 2 Cathy Avery 2019-03-07 20:05:19 UTC
Lili,

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

Thanks

Comment 3 ldu 2019-03-08 01:49:41 UTC
(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.

Comment 4 Cathy Avery 2019-03-08 15:23:53 UTC
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.

Comment 5 Pengpeng Sun 2019-03-11 03:07:52 UTC
(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

Comment 6 Daniel Berrangé 2019-03-11 09:56:14 UTC
(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.

Comment 7 Miroslav Rezanina 2019-03-13 08:01:35 UTC
Fix included in open-vm-tools-10.3.0-2.el7

Comment 9 ldu 2019-04-23 07:00:32 UTC
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

Comment 11 errata-xmlrpc 2019-08-06 12:57:03 UTC
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


Note You need to log in before you can comment on or make changes to this bug.