automatic start dropbox in VM

[Jos den Bekker]

I would like to have dropbox start automatically when I start my work VM. How best do I do that? Install a new service? Or is there a startup script to which I can add the appropriate command?
Thanks for any feedback.

[Zrubi]

You can put any command in the file:
/rw/config/rc.local

This will called on every boot.


--
Zrubi

[Jos den Bekker]

On 21 september 2014 21:10:42 UTC+2 Laszlo Zrubecz wrote:

You can put any command in the file:
/rw/config/rc.local

This will called on every boot.

Thanks very much. And this file will not be overwritten during system update?

[Zrubi]

No, it is located on the actual AppVM private.img

More about the template sharing:
https://wiki.qubes-os.org/wiki/TemplateImplementation


--
Zrubi

[Jos den Bekker]

On 21 september 2014 21:28:53 UTC+2 Laszlo Zrubecz wrote:

No, it is located on the actual AppVM private.img

More about the template sharing:
https://wiki.qubes-os.org/wiki/TemplateImplementation

Put the command - "dropbox start &" in the file, but nothing happens. If I execute rc.local, however, dropbox is started. Don't understand this. I made rc.local executable and this is how it looks:

#!/bin/sh -c

dropbox start &

exit 0

What am I doing wrong?

[Gorka Alonso]

make that file executable.

chmod a+x /rw/config/rc.local

[Marek Marczykowski-Górecki]

This script is run as root, perhaps you need to switch to user first.
Something like:
su -c "dropbox start" - user &


--
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[Jos den Bekker]

On 21 september 2014 23:48:04 UTC+2 Marek Marczykowski-Górecki wrote:

This script is run as root, perhaps you need to switch to user first.
Something like:
su -c "dropbox start" - user &

Did that. Great disaster. Now my work VM doesn't start anymore: "Cannot start qubes guid"! How can I get to rc.local to undo the change?

[Marek Marczykowski-Górecki]

Perhaps you've run out of disk space?

[Jos den Bekker]

On 22 september 2014 00:29:54 UTC+2 Marek Marczykowski-Górecki wrote:
Perhaps you've run out of disk space?

Judge for yourself:

[Jos@dom0 -]$ df -h
Filesystem                               Size Used Avail Use% Mounted on
/dev/mapper/qubes_dom0-root   455G  12G  420G   3%    /
devtmpfs                                   1.8G      0  1.8G   0%    /dev
tmpfs                                        1.8G 227M 1.6G  13%   /dev/shm
tmpfs                                        1.8G 9.0M  1.8G   1%   /run
tmpfs                                        1.8G      0  1.8G    0%   /sys/fs/cgroup
tmpfs                                        1.8G  12K  1.8G    1%   /tmp
/dev/sdbl                                  477M 111M  338M  25%   /boot
xenstore                                    1.8G 144K  1.8G    1%   /var/lib/xenstored
[Jos@dom0 ~]$ |

Doesn't look like a lack of disk space to me.

In noticed that my work VM kept busy (CPU usage), so I wondered if the ampersand (&) at the end of the line could be the culprit:

su -c "dropbox start" - user &

because imho that means that the su proces doesn't stop.

Can't I access the file from root on dom0?

[Marek Marczykowski-Górecki]

Try access it using "sudo xl console VMNAME" (login as root there).

[Jos den Bekker]

On 22 september 2014 12:18:59 UTC+2 Marek Marczykowski-Górecki wrote:

Try access it using "sudo xl console VMNAME" (login as root there).

Thanks. That saved my VM

I changed the command in rc.local into su - user -c "dropbox start &", but same disastrous result. I left out the ampersand, same result. I'm not sure I understand this. "dropbox" is a frontend python script in /usr/bin, and I should think that with "su" the script runs within the VM.

But "work" is the only VM that has the dropbox daemon installed, so now I execute it directly in rc.local, and that works perfectly.

Thanks for all the feedback.

[cprise]

--

Try adding /usr/bin path to the command.

[gonda...@gmail.com]

May I ask how did you manage to make it work in the end?

I am using this approach with dropbox but somehow cannot start it up.
cd ~ && wget -O - "https://www.dropbox.com/download?plat=lnx.x86_64" | tar xzf -
Next, run the Dropbox daemon from the newly created .dropbox-dist folder.
~/.dropbox-dist/dropboxd

My guess is that rc.local is executed as root.

[jrhe...@gmail.com]

FWIW, after successfully installing dropbox using these steps:
1) 'rpm -Uvh nautilus-*'
2) 'dropbox start -i' (from a command line w/ a URL handler installed)
3) following authn instructions in the resulting browser window

I found that I could get dropbox to start automatically at boot by adding this to /rw/config/rc.local and making it executable:

sudo -c '/usr/bin/dropbox start' - user &

Note: because dropbox is installed in the user's home dir, only step #1 above makes sense in the template; the others need to happen in the VM.

[marllus...@gmail.com]

The only solution that solved my problem was to add the following line in this file '/home/user/.bash_profile':

sh ~/.dropbox-dist/dropboxd &

thanks a lot

[John Goold]

On Sunday, September 21, 2014 at 1:49:05 PM UTC-5, Jos den Bekker wrote:
> I would like to have dropbox start automatically when I start my work VM. How best do I do that? Install a new service? Or is there a startup script to which I can add the appropriate command?
> Thanks for any feedback.

I simply put a symbolic link to dropbox.desktop in ~/.config/autostart

Works perfectly. I also have links to slack.desktop and thunderbird.desktop.

The .desktop files are located in /usr/share/applications/

Cheers,
John

[Manuel Amador (Rudd-O)]

On 30/01/2019 15.53, John Goold wrote:
>
> I simply put a symbolic link to dropbox.desktop in ~/.config/autostart
>
> Works perfectly. I also have links to slack.desktop and thunderbird.desktop.
>
> The .desktop files are located in /usr/share/applications/

This is the cleaner solution and I highly recommend it.  It's the best
way to get apps autostarted with the *right* environment variables for
your desktop environments, something that `sudo` in the context of
`rc.local` will *not* give you.

--
Rudd-O
http://rudd-o.com/