[HOME] [DOWNLOAD] [DOCS] [NEWS] [SUPPORT] [TIPS] [ISSUES] [DONATE]

Error Message: setterm: $TERM is not defined

I’m unsure how the qrexec module and qvm-* commands are implemented.

Don’t get these errors in Qubes Dom0 Terminal with other Qubes VMs.

I can literally out comment each of the problem commands in “20_power_savings_disable_in_vms.sh” and individual instances of the errors disappear, while the VM is live without reboot.

For example:

In Qubes Dom0 Terminal:

qvm-run --pass-io whonix-workstation 'date'

setterm: $TERM is not defined.
setterm: $TERM is not defined.
Sat Dec 25 12:00:00 UTC 2014

Then, if in the whonix-workstation VM, I comment out:

#setterm -blank 0
true "$0: exit code: $?"
setterm -powerdown 0
true "$0: exit code: $?"

and run again in Qubes Dom0 Terminal:

qvm-run --pass-io whonix-workstation 'date'

setterm: $TERM is not defined.
Sat Dec 25 12:00:00 UTC 2014

Then, if in the whonix-workstation VM, I comment out:

#setterm -blank 0
true "$0: exit code: $?"
#setterm -powerdown 0
true "$0: exit code: $?"

and run again in Qubes Dom0 Terminal:

qvm-run --pass-io whonix-workstation 'date'

Sat Dec 25 12:00:00 UTC 2014

Each instance of the Qubes Dom0 Terminal error is dynamically removed on live VMs by commenting out each “setterm” command in the Whonix VM.

But, anyway, our “2>/dev/null” patch takes care of the error output as well, without disabling the Whonix “setterm” commands.

The problem is that 20_power_savings_disable_in_vms.sh is executed when running qvm-run.

Or more generally said:
The problem is that /etc/profile.d is executed when running qvm-run. (Must be persistent.)

If you use some other VM and add /etc/profile.d/30_test.sh, make it executable and add.

#!/bin/bash
echo "$0: debug test"

It would have the same effect.

So “setterm: $TERM is not defined.” / power-savings-disable-in-vms is just a symptom. Not the issue.

Parsing whole /etc/profile.d/ for each run of qvm-run seems strange to me. Could be a Qubes specific issue.

[quote=“Patrick, post:14, topic:763”]Added this:

Are you sure there will be a /usr/lib/qubes folder?

The whonix-qubes package does not contain one. See https://github.com/nrgaway/whonix-qubes/tree/master/usr/lib.[/quote]

Yes, there will always be a /var/run/qubes. It is created before the network is brought up in /usr/lib/qubes/init/qubes-sysinit.sh.

[quote=“Patrick, post:22, topic:763”]The problem is that 20_power_savings_disable_in_vms.sh is executed when running qvm-run.

Or more generally said:
The problem is that /etc/profile.d is executed when running qvm-run. (Must be persistent.)

If you use some other VM and add /etc/profile.d/30_test.sh, make it executable and add.

#!/bin/bash
echo "$0: debug test"

It would have the same effect.

So “setterm: $TERM is not defined.” / power-savings-disable-in-vms is just a symptom. Not the issue.

Parsing whole /etc/profile.d/ for each run of qvm-run seems strange to me. Could be a Qubes specific issue.[/quote]

qvm-run is a command line utility that connects to the AppVM to run some command as superuser which will also echo its output back. profile.d is parsed for any shell connecting as it would for any distribution I would think. qvm-run is used instead of networking for inter-vm communications which means to be more secure and allows transferring of data (based on policies) between vm’s with no network access.

I have subjectively noticed that launching apps can feel slow. Especially remembering when launching apps via “qvm-run” command in Dom0.

It makes me wonder if executing Whonix’s full “/etc/profile.d” directory each time is causing the launching of apps to be slow.

Haven’t done explicit A/B tests yet to compare app launching speeds.

Contents of /etc/profile.d that supposedly gets executed every time:

ls /etc/profile.d

15_open_link_confirmation.sh
20_controlportfilt.sh
20_default_browser.sh
20_power_savings_disable_in_vms.sh
20_torbrowser.sh
20_whonix.sh
30_desktop.sh
30_setup.sh
40_msgdispatcher.sh
bash_completion.sh
qt_x11_no_mitshm.sh
qubes-gui.csh
qubes-gui.sh
qubes-session.sh

Could be. That’s what I meant by Qubes specific issue. I don’t think always parsing it is a good implementation. But what do I know. :slight_smile: Could be, that it’s not that simple to implement this any better in Qubes.

[quote=“Patrick, post:26, topic:763”][quote author=WhonixQubes link=topic=839.msg6328#msg6328 date=1420478957]
It makes me wonder if executing Whonix’s full “/etc/profile.d” directory each time is causing the launching of apps to be slow.
[/quote]
Could be. That’s what I meant by Qubes specific issue. I don’t think always parsing it is a good implementation. But what do I know. :slight_smile: Could be, that it’s not that simple to implement this any better in Qubes.[/quote]

I don’t think I understand what you mean by ‘always parsing’ or maybe what it’s in reference to.

From what I understand every file related to the shell (.sh for bash, .csh for csh) in the /etc/profile.d directory is sourced by every newly created shell. This would be the case for every distribution of Linux no matter the flavour, would it not?

Yes.

“parsing” = have the virtual console

which does

if [ -d /etc/profile.d ]; then
  for i in /etc/profile.d/*.sh; do
    if [ -r $i ]; then
      . $i
    fi
  done
  unset i
fi

Usually only a virtual console is doing this once after the user has (auto) logged in. (For example into tty0.)

“always parsing” = would be the case if virtual console did the above for each and every command that is entered.

Having qvm-run parse /etc/profile once for each VM might be fine. But it should be somehow cached. Doing this every time, for each and every command is what I mean by “always parsing” and this could be a performance issue.

[Imprint] [Privacy Policy] [Cookie Policy] [Terms of Use] [E-Sign Consent] [DMCA] [Investors] [Priority Support] [Professional Support]