Autostart applications in AppVM - settings feature request

I always have a terrible time getting apps to autostart on AppVM startup.

Note to self: shut up and read the docs

I use a google search and come up with a variety of protocols, some referring to an rw location, others to '~/.config/autostart`.

To top it off, I struggle to find the .desktop file.

I can’t be sure, and I can’t be sure if its a Qubes issue or a Linux issue, but I swear the relevant locations have changed, and I know that for some (e.g. firefox) the names of desktop files have changed.

(I don’t understand why the find / -iname [name] doesn’t find .desktop files, either).

Can someone point to THE protocol I should be using - I’m just quite confused at the moment.

Also, as a feature request, I would LOVE IT if the Settings panel for an AppVM had an option to add an application to autostart. It seems a logical place (that’s how you set up the application in the menu) and a fairly common task for setting up a qube.

4 Likes

The user documentation explains how to list the available desktop shortcuts within the AppVM:

1 Like

I agree, this would be fantastic to have easy access to be able to achieve this as a result.
To get an application to autostart at the moment is to have it set up in libxl hook so that it reads your configuration file and executes the commands in the guest when it has reached a STARTED state.

Not hard to set up, but annoying to maintain if you have plenty of guests.

I have a hundred or so guests, and my libxl has stopped working, noone knows why, and so the script doesn’t run any more for me. but it was working before the issue.

I’ll get the code off my backup drive and upload it shortly.

1 Like

~/.autostarts
would look something like this…

guest1 firefox-esr
guest1 thunderbird
guest2 nautilus
guest3 claws-mail
guest4 wget -o http://localhost.net --pass-io --nogui > ~dom0user/fromguest.wgot

/etc/libvirt/hooks/libxl

Inside add the code…

guest_name="$1"
libvirt_operation="$2"

if [ "$libvirt_operation" == "started" ]; then
  if [ -f ~/.autostarts ]; then
    grep -R "^$guest_name " ~/.autostarts | sed "s/^$guest_name //g" | while IFS= read -r command; do
      qvm-run $guest_name $command
    done
  fi
fi

This will allow you to set up for any number of autoruns for any guest.

I have to type it in by hand from my notebook, hopfully it is all correct and working. I mean it all looks correct.

ADDN: I should also mention that it will perform the commands in the order that you have them there listed.
If you add any wait for completion before moving on as options and all, it will run those too. like if you added a “–pass-io” (editing for detail in the listing.)

Yes I know I don’t need to have them separated out and all, but I do more in that for my own things that I do in there as well, so that’s why that is like it is.

2 Likes

@alimirjamali would this be simple enough to add? Perhaps worth creating an issue for it?

Related:

1 Like

There are multiple approaches on how to achieve this goal. Most of them involves different technical and UX challenges.

  1. Just like suggestion, adding autostart checkbox somewhere in qube-vm-settings GUI to enable automatic launch of all Apps selected in Applications tab. This involves changes to qubes-manager repository for changes required for setup dialog and qubes-core-admin to honour it (via a preference or feature).
  2. A separate tab in qube settings which should allow individual selection of App Menu available items and autostart items. Again this involves changes to qubes-manager repo and qubes-core-admin repo to honour a feature similar to menu-items but for autostart items.
  3. There is a proposal for complete redesign of Application Tab. Theoretically it could include another column for autostart items.
    Redesign and improve the VM Settings: Applications tab · Issue #6366 · QubesOS/qubes-issues · GitHub

I would categories this feature somewhere between easy and hard. If someone wants to do this, they could decide & discuss the right approach (if all selected apps should be automatically started or a separate list should be allocated for autostart items). Then they must work on core patch. Finally UX.

I am personally busy on another aspect of Applications tab improvement (adding icons like screenshot below). Since I believe it might have higher demand.

2 Likes

Problem is that some of those aren’t always what need to be started.

One thing that would have to be added is the availability to have extra things set.

Personally, I have scripts there that run things with 8-9 parameters if a guest has a certain wording in it.

For example I have my WRK-VSCode-Lazarus-QEMU guests.

I have these guests that check a specific file in a specific location, gets the identifiers, checks it against several other guests, then copies the right files over from the guest with the latest data.

All this is done from Domain-0.

So while it is launching applications, it is the availability of doing much more that I think also needs to be implimented for those that know what they are doing.

As for the applications TAB, it is sometimes useless for that.

On guest boot, there are many that install software after they have started.
And they install the software every time. So it doesn’t appear inside the Application menus. So I have delays in the execution script. Set it to have a time before execution in the guest after it has started.

So there are many factors that are at play here, and the Qubes Manager, the way it is, needs a new TAB for this, not just alter the TAB. So option 2 is partly right.

Adding the tab is easy, creating the scripts for it is easy, every part is easy. making it work together is the harder part.
If the Qubes Manager code was structured well and coded well, then I would be able to make the changes and have something uploaded within 2 hours.
Unfortunately, that isn’t the case, so I’ll leave it up to those that know that tangled mess.

But all in all, needs a new tab with option to have selected item launched, as well as custom command to launch, including a delay after guest started.

That I think is the way to have it done.

Would you agree with that?

1 Like

The above should work and should be sufficient in many cases. In addition to technical challenges, it would be necessary to communicate the proposal with decision making core developers and have their opinion as well (on Github related issues).

1 Like

Yes, their opinion on if it’s good or not would be good.

Then it just needs to be implemented correctly. Don’t know who would do that properly though. that’s the real problem.

1 Like