4

The startup-script added to an instance in GCP doesn't seem to run on first boot (but does on subsequent boots)

I'm using the https://www.googleapis.com/compute/v1/projects/centos-cloud/global/images/centos-7-v20160921 base image but had the same issue on a slightly older version of the centos-7 image too.

This happens whether I use the API to create an instance, or the web console.

According to the docs (https://cloud.google.com/compute/docs/startupscript) adding a metadata with the key startup-script and value of a script should cause the script to be run on every boot.

(There is a section about adding the script to a running instance, and it mentions that a reboot is required to get the script to run, but this (apparently) shouldn't apply to new instances.)

It's possible to force the script to run using sudo google_metadata_script_runner --script-type startup (https://cloud.google.com/compute/docs/startupscript#rerunthescript) which implies that the script is loaded, but just not run, so I'm not sure what's going on.

Am I doing something wrong, or have I found a bug in GCP? :)

  • 1
    I was able to reproduce the same behavior on my test account. I would suggest filing a new issue on the public Issue tracker [1] which then will be redirected to Google's engneering team in order to fix it as soon as possible. [1] code.google.com/p/google-compute-engine/issues/list – George Oct 4 '16 at 17:36
  • 1
    Thanks, I've opened the issue here: code.google.com/p/google-compute-engine/issues/detail?id=433 – funkyhat Oct 7 '16 at 20:27
  • This issue went away by itself, so either google quietly fixed the issue with their image or I was doing something wrong from the start. In any case, I'm no longer able to reproduce it. – funkyhat Feb 6 '17 at 17:16
  • I just ran into this as well. It still seems to be an issue. My google customer account can't seem to view that issue. I've opened a support case with google, but they are suggesting an instance level script, which is a no go for us. We are using a mix of *nix and win environments so the solutions below won't work for us. – nomadic_squirrel Oct 2 '18 at 17:38
1

This actually worked for me without issues using the Centos 7 image. I created the VM from the console and added this small script

#! /bin/bash
yum update
yum install -y httpd
cat <<EOF > /var/www/html/index.html
<html><body><h1>Hello World</h1>
<p>This page was created from a simple startup script!</p>
</body></html>
EOF

After the VM was created I was able to verify that Apache had been installed in the serial console.

…
Feb  3 20:36:17 instance-3 startup-script: INFO startup-script: ---> Package httpd.x86_64 0:2.4.6-45.el7.centos will be installed
Feb  3 20:36:17 instance-3 startup-script: INFO startup-script: --> Processing Dependency: httpd-tools = 2.4.6-45.el7.centos for package: httpd-2.4.6-45.el7.centos.x86_64
Feb  3 20:36:17 instance-3 startup-script: INFO startup-script: --> Processing Dependency: /etc/mime.types for package: httpd-2.4.6-45.el7.centos.x86_64
….
Feb  3 20:36:20 instance-3 startup-script: INFO startup-script: Installed:
Feb  3 20:36:20 instance-3 startup-script: INFO startup-script:   httpd.x86_64 0:2.4.6-45.el7.centos
Feb  3 20:36:20 instance-3 startup-script: INFO startup-script: Dependency Installed:
Feb  3 20:36:20 instance-3 startup-script: INFO startup-script:   apr.x86_64 0:1.4.8-3.el7                     apr-util.x86_64 0:1.5.2-6.el7
Feb  3 20:36:20 instance-3 startup-script: INFO startup-script:   httpd-tools.x86_64 0:2.4.6-45.el7.centos     mailcap.noarch 0:2.1.41-2.el7
Feb  3 20:36:20 instance-3 startup-script: INFO startup-script: Complete!

The script did install Apache but the service in the VM was not started. I just had to SSH in the VM to start the service.

| improve this answer | |
  • That's normal behaviour for RHEL-based distros, my startup script also includes the lines systemctl enable httpd systemctl start httpd – funkyhat Feb 6 '17 at 17:18
  • Were you able to solve this? Looking at the serial console might provide some hints. – Carlos Feb 6 '17 at 23:21
  • I stopped being able to reproduce the problem. Not sure exactly why and I wasn't keeping particularly good notes when it was occurring. It may have been down to incorrect network setup in the end. – funkyhat Feb 8 '17 at 1:39
1

This is not a bug, it still exists and it is tricky.

Startup scripts are ran after all init.d scripts.

So if you initialise a /etc/environment file for example and try to use it in a init.d script, on the first boot, /etc/environment will not exist when your script will be launched.

On the second boot, there is no more problem, /etc/environment already exists :-)

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.