Apparent VM startup script prob Google Cloud Fundamentals: Getting Started with Cloud Storage lab

[DuncsMoncrieff]

I've had some problems with the Google Cloud Fundamentals: Getting Started with Cloud Storage and Cloud SQL lab (https://www.cloudskillsboost.google/paths/19/course_sessions/23739510/labs/531581).

you have to launch a default Debian GNU/Linux 12 (bookworm) instance with the following startup script included in the automation section:

apt-get update
apt-get install apache2 php php-mysql -y
service apache2 restart

No errors, everything continues fine until...

Task 5. Configure an application in a Compute Engine instance to use Cloud SQL
Upon trying the cd command via ssh I get the following error:

Whilst of course I can create the text file in nano and call it index.php, it's not accessible - the restart apache server command is useless given that the apache service isn't running:

So when you try to connect to the external IP address of the VM instance, well, it doesn't want to speak (no apache server running).

From the logs explorer for the VM instance I see that there has been a problem with the start-up script:

I mean, maybe I'm wrong, but this looks like a problem that's not on my end (unless copying across the script somehow modified it - tried twice, same result!)

Any thoughts, suggestions or spare credits? 😅

thanks for reading 👍

[MikaCloud · Accepted solution]

Hi, DuncsMoncrieff.

As one idea is to SSH into VM and try to-reinstall Apache server manually (re-run sudo apt-get install apache ... the whole line). Then restart the server in VM....again with sudo.

Best,

MC

P.S. Apparently the start script was not executed as there is no Apache on the VM. 

[MikaCloud]

... and some quick googling brought this solution to your problem (check the logs in your picture...locking with linux installs is not something unusual even from my experience) - https://askubuntu.com/questions/1109982/e-could-not-get-lock-var-lib-dpkg-lock-frontend-open-11-reso...

[DuncsMoncrieff]

thanks for the reply @MikaCloud!

Yes, that's an option, probably with running the commands one at a time to avoid the dpkg lock conflict happening again...probably the simplest thing to do!
Or maybe something like:

apt-get -o DPkg::Lock::Timeout=60 install

in the install script..? Could you include "retry loops" in a startup script to avoid a clash with another "apt-get" process running causing the installation failure?(like it appears to have been the case)

[MikaCloud]

You always can do retrial loops in script (which is bash)...

You can try something like

while [[ $? != 0 ]]

do

(your re-try code here)

done