Menu
▾
▴
open-vm-tools-devel
|
From: Justin M. F. <jmf...@li...> - 2007-11-01 14:39:00
|
I have noticed when using shutdown guest or restart from the host, on the first attempt I get a pop up window saying that the request failed "because the corresponding VMware Tools script did not run successfully." Yet a second attempt at the same operation always seems to work. Any ideas on the cause for that one? Justin |
|
From: Justin M. F. <jmf...@li...> - 2007-11-01 15:04:18
|
On Thu, 2007-11-01 at 09:38 -0500, Justin M. Forbes wrote: > I have noticed when using shutdown guest or restart from the host, on > the first attempt I get a pop up window saying that the request failed > "because the corresponding VMware Tools script did not run > successfully." Yet a second attempt at the same operation always seems > to work. Any ideas on the cause for that one? Aha, after a bit of probing, it seems that it chokes when /etc/vmware-tools/poweroff-vm-default is not present instead of simply falling back to CONFVAL_HALT_DEFAULT, though I am not sure why it works on the second try. I guess the question is, should we include default scripts, or just make the code DTRT if the scripts are not present. Justin |
|
From: Sean D. <se...@du...> - 2007-11-01 15:06:22
|
Justin M. Forbes wrote: > Aha, after a bit of probing, it seems that it chokes > when /etc/vmware-tools/poweroff-vm-default is not present instead of > simply falling back to CONFVAL_HALT_DEFAULT, though I am not sure why it > works on the second try. I guess the question is, should we include > default scripts, or just make the code DTRT if the scripts are not > present. > The right answer is probably to do both. Include the scripts, and make sure the code DTRT if they're not there. |
|
From: Justin M. F. <jmf...@li...> - 2007-11-01 15:16:24
|
On Thu, 2007-11-01 at 11:05 -0400, Sean Dilda wrote: > Justin M. Forbes wrote: > > > Aha, after a bit of probing, it seems that it chokes > > when /etc/vmware-tools/poweroff-vm-default is not present instead of > > simply falling back to CONFVAL_HALT_DEFAULT, though I am not sure why it > > works on the second try. I guess the question is, should we include > > default scripts, or just make the code DTRT if the scripts are not > > present. > > > > The right answer is probably to do both. Include the scripts, and make > sure the code DTRT if they're not there. > In that case, the default scripts would really just do the default fallback. In other words, the behavior would be the same if the scripts were present or not. In this case, it would be better to not package the scripts, so that users could replace them without worrying about getting trampled by their package manager, or more importantly, the packaged implementation could be used while packages providing more specific scripts could be packaged elsewhere without file conflicts. Justin |
|
From: Justin M. F. <jmf...@li...> - 2007-11-01 19:11:54
|
On Thu, 2007-11-01 at 10:16 -0500, Justin M. Forbes wrote: > On Thu, 2007-11-01 at 11:05 -0400, Sean Dilda wrote: > > Justin M. Forbes wrote: > > > > > Aha, after a bit of probing, it seems that it chokes > > > when /etc/vmware-tools/poweroff-vm-default is not present instead of > > > simply falling back to CONFVAL_HALT_DEFAULT, though I am not sure why it > > > works on the second try. I guess the question is, should we include > > > default scripts, or just make the code DTRT if the scripts are not > > > present. > > > > > > > The right answer is probably to do both. Include the scripts, and make > > sure the code DTRT if they're not there. > > > In that case, the default scripts would really just do the default > fallback. In other words, the behavior would be the same if the scripts > were present or not. In this case, it would be better to not package > the scripts, so that users could replace them without worrying about > getting trampled by their package manager, or more importantly, the > packaged implementation could be used while packages providing more > specific scripts could be packaged elsewhere without file conflicts. > Okay, a bit more reading and understanding the code here... I didn't realize those are pre/post scripts. So the issue is that VMware Workstation or VMware Server shouldn't complain if guestd replies not implemented on those scripts, but no point in changing the client to give a fake response either. It seems most sane to actually add/package those scripts and make them check some given dir (say /etc/vmware-tools/scripts.d) for the corresponding script and execute the script if it exists, exit cleanly if not. that not only keeps the console from erroring or complaining about missing functionality, but allows people to package proper shutdown and startup scripts if they have any real needs. Sorry for the earlier confusion. Justin |
|
From: Elliot L. <el...@vm...> - 2007-11-06 18:49:58
|
On 11/1/07 12:11 PM, "Justin M. Forbes" <jmf...@li...> wrote: >> In that case, the default scripts would really just do the default >> fallback. In other words, the behavior would be the same if the scripts >> were present or not. In this case, it would be better to not package >> the scripts, so that users could replace them without worrying about >> getting trampled by their package manager, or more importantly, the >> packaged implementation could be used while packages providing more >> specific scripts could be packaged elsewhere without file conflicts. >> > > Okay, a bit more reading and understanding the code here... I didn't > realize those are pre/post scripts. So the issue is that VMware > Workstation or VMware Server shouldn't complain if guestd replies not > implemented on those scripts, but no point in changing the client to > give a fake response either. It seems most sane to actually add/package > those scripts and make them check some given dir > (say /etc/vmware-tools/scripts.d) for the corresponding script and > execute the script if it exists, exit cleanly if not. that not only > keeps the console from erroring or complaining about missing > functionality, but allows people to package proper shutdown and startup > scripts if they have any real needs. > Sorry for the earlier confusion. Hey Justin, I believe that the missing scripts were actually an oversight and should be included in the next open-vm-tools release. Sorry about that! Right now it looks like the scripts as they'll be shipped either execute another script directly, or just run a bunch of initscripts (/etc/init.d/* stuff). At this point, it sounds like you understand more about those scripts than I do. Are you mainly suggesting that each of the default scripts look in a scripts.d directory for other scripts to execute? Best, -- Elliot |
|
From: Justin M. F. <jmf...@li...> - 2007-11-07 03:44:15
|
On Tue, 2007-11-06 at 10:49 -0800, Elliot Lee wrote:
>
> I believe that the missing scripts were actually an oversight and should be
> included in the next open-vm-tools release. Sorry about that!
>
> Right now it looks like the scripts as they'll be shipped either execute
> another script directly, or just run a bunch of initscripts (/etc/init.d/*
> stuff). At this point, it sounds like you understand more about those
> scripts than I do. Are you mainly suggesting that each of the default
> scripts look in a scripts.d directory for other scripts to execute?
>
Right, so the scripts themselves are not necessary, in fact the ones
that ship with the closed vmware-tools only do:
echo `date` ": Executing '$0'"
They are run before the shutdown or restart when called from the
console. The console complains when they are not present as they are
reported not implemented, but the shutdown command should work fine.
>From an appliance standpoint, it would be nice to give appliance
developers the ability to add startup or shutdown scripts without
modifying the open-vm-tools package themselves. In this vein, we
shipped the following script
for /etc/vmware-tools/{poweroff,poweron,suspend,resume}-vm-default:
#!/bin/bash
execscript=$(basename $0)
scriptdir=/etc/vmware-tools/scripts/$execscript.d
for file in $scriptdir/*
do
[ -x $file ] && $file
done
# To match output from older VMware Tools
echo `date` ": Executing '$0'"
Realistically, the reboot or shutdown does a shutdown -r or -h so init
does it's job normally, and I don't think that the scripts will get much
use. Unfortunately the host complains and an error dialog appears if
they are not there, so we might as well give them the potential to be
useful.
Justin
|
|
From: Elliot L. <el...@vm...> - 2007-11-09 02:21:45
|
On 11/6/07 7:44 PM, "Justin M. Forbes" <jmf...@li...> wrote:
>> From an appliance standpoint, it would be nice to give appliance
> developers the ability to add startup or shutdown scripts without
> modifying the open-vm-tools package themselves. In this vein, we
> shipped the following script
> for /etc/vmware-tools/{poweroff,poweron,suspend,resume}-vm-default:
>
> #!/bin/bash
>
> execscript=$(basename $0)
> scriptdir=/etc/vmware-tools/scripts/$execscript.d
>
> for file in $scriptdir/*
> do
> [ -x $file ] && $file
> done
>
> # To match output from older VMware Tools
> echo `date` ": Executing '$0'"
>
> Realistically, the reboot or shutdown does a shutdown -r or -h so init
> does it's job normally, and I don't think that the scripts will get much
> use. Unfortunately the host complains and an error dialog appears if
> they are not there, so we might as well give them the potential to be
> useful.
Hey Justin,
Thanks for the explanation. I think a .d scheme would be very useful and
very easy to do. Can't promise it for the next release (which I'm hoping
will be ready in a week or so), but I'll try if there's time. The main thing
I'd like feedback from others on is the actual directory path that these
scripts will be dropped into. I'm thinking of either
Scriptsdir="`dirname $0`"/scripts/`basename $0`.d"
(to match your current setup) or just
Scriptsdir=$0.d
The main constraint is that it has to work properly even if the scripts are
in /usr/local/etc or /var/fooblah.
Thoughts?
Best,
-- Elliot
|
|
From: Justin M. F. <jmf...@li...> - 2007-11-11 20:22:49
|
On Thu, 2007-11-08 at 18:21 -0800, Elliot Lee wrote: > Thanks for the explanation. I think a .d scheme would be very useful and > very easy to do. Can't promise it for the next release (which I'm hoping > will be ready in a week or so), but I'll try if there's time. The main thing > I'd like feedback from others on is the actual directory path that these > scripts will be dropped into. I'm thinking of either > > Scriptsdir="`dirname $0`"/scripts/`basename $0`.d" > > (to match your current setup) or just > > Scriptsdir=$0.d > > The main constraint is that it has to work properly even if the scripts are > in /usr/local/etc or /var/fooblah. > Right, so the scripts really have to be in a set place at build time, by default that is $sysconfdir/vmware-tools. It seems to make the most sense to me that we look in that tree for the user scripts. Scriptsdir="`dirname $0`"/scripts/`basename $0`.d" would work just fine, our actual scripts use %(sysconfdir)s/vmware-tools/ and use conary macro substitution to place that as /etc/vmware-tools at build time. Of course if the builder has those set elsewhere, that is fine too. Justin |
Thanks for helping keep SourceForge clean.
X