KThorlund
Enthusiast
Enthusiast

Linux / silent update VMWare-Tools

Jump to solution

Hello,

I have made vRO workflow, which accesses our Linux (Ubuntu 18.4) boxes and initiates a system update via apt-get.

The script runs find, if I trigger it manually, but it hangs when called via VMWare Tools. I am sure it is because it prompts for some input (thou it doesnt when I run it manually).

It is really annoying that apt-get is so complex to configure for running non interactive..

I am already using the env, which is what I have found on the internet...

export DEBIAN_FRONTEND=noninteractive

export DEBIAN_PRIORITY=critical

Has anyone experienced similar - how can I 100% non interactive upgrade my machines?

Best regards, K

0 Kudos
1 Solution

Accepted Solutions
KThorlund
Enthusiast
Enthusiast

After much frustration, I finally found what caused it.

When you dispatch a command to the OS via VMTools, the tools initiates the request, returns a PID, and "hangs up". The process it running as expected.

E.g the command I trigger on the OS via VMTools is "sudo /home/vmtools/updateSystem.sh"

Somehow I would have expected the new process to be disconnected / spawned from the parent, here VMTools, but it does not seem to be the case.

As soon apt-get hits the VMTools package for the upgrade, it kills the main process and takes down the rest, which results a halted and semi corrupt upgrade.

It does make sense the it brings down the children, but at the same time not... I would have expected my call to the OS to be fully disconnected after the call.. To my surprise there was no identification, logs in either programs or consoles, that this was the issue.

There are too ways to avoid it...

One, skip the upgrade VMTools when updating the system. It works, but you will end up with an outdated package. It can be done with the hold/unhold in apt-get

sudo -E apt-mark hold open-vm-tools

sudo -E apt-get -qy update

sudo -E apt-get -qy dist-upgrade

sudo -E apt-mark unhold open-vm-tools

Alternative, and the one I prefer, as the request and process it completely disconnected from VMTools, is to schedule it with at. The request is then dispatched to init, and started from there. No interaction with VMTools.

The command executed from VMTools is then

echo 'sudo /home/vmtools/updateSystem.sh' | at now

The request is transferred to the OS via VMtools, but executed straight ahead with the "at now".

No more killed processes and faulty execution.

I believe above could be the case in several occasions, and in the future I will trigger all my commands with "at now".

I slept so good the night I found it... Smiley Happy I hope it will be useful for some of you too.

Kjeld

View solution in original post

0 Kudos
1 Reply
KThorlund
Enthusiast
Enthusiast

After much frustration, I finally found what caused it.

When you dispatch a command to the OS via VMTools, the tools initiates the request, returns a PID, and "hangs up". The process it running as expected.

E.g the command I trigger on the OS via VMTools is "sudo /home/vmtools/updateSystem.sh"

Somehow I would have expected the new process to be disconnected / spawned from the parent, here VMTools, but it does not seem to be the case.

As soon apt-get hits the VMTools package for the upgrade, it kills the main process and takes down the rest, which results a halted and semi corrupt upgrade.

It does make sense the it brings down the children, but at the same time not... I would have expected my call to the OS to be fully disconnected after the call.. To my surprise there was no identification, logs in either programs or consoles, that this was the issue.

There are too ways to avoid it...

One, skip the upgrade VMTools when updating the system. It works, but you will end up with an outdated package. It can be done with the hold/unhold in apt-get

sudo -E apt-mark hold open-vm-tools

sudo -E apt-get -qy update

sudo -E apt-get -qy dist-upgrade

sudo -E apt-mark unhold open-vm-tools

Alternative, and the one I prefer, as the request and process it completely disconnected from VMTools, is to schedule it with at. The request is then dispatched to init, and started from there. No interaction with VMTools.

The command executed from VMTools is then

echo 'sudo /home/vmtools/updateSystem.sh' | at now

The request is transferred to the OS via VMtools, but executed straight ahead with the "at now".

No more killed processes and faulty execution.

I believe above could be the case in several occasions, and in the future I will trigger all my commands with "at now".

I slept so good the night I found it... Smiley Happy I hope it will be useful for some of you too.

Kjeld

View solution in original post

0 Kudos