Upstart script needs to run after /tmp is mounted and writable

Question

I have an Ubuntu Linux server that is running in a Vagrant virtual environment. I use the server for development of a web service. When the server starts up I have a shell script that needs to run once in order to setup a cache directory structure on the /tmp/ filesystem.

description "setup web cache"

start on startup

script
    mkdir -p /tmp/cache/persistent
    mkdir -p /tmp/cache/models
    mkdir -p /tmp/cache/views
    chmod -R 777 /tmp/cache/
end script

When I boot the server I get an error message that show up in /var/log/upstart/webcache.log:

mkdir: cannot create directory `/tmp/cache': Read-only file system

Apparently startup is too soon to start on. The question is, when is /tmp available for writing and what do I pass to start on?

score 4 · Accepted Answer · answered Nov 26 '13 at 07:57

4

Since your job needs to start when local file system is mounted most likely you need following definition: start on local-filesystems

See local-filesystem event example.

You will find overview of well known Upstart events here.

Further on, your job is a short lived job and not a service/daemon. It will be more appropriate to use task stanza. In such way you might run a job that depends on cache directories created once those directories are actually created. Otherwise, if you define all dependent jobs to start runlevel [2345] dependent job might start before needed directories are created e.g. dependent job might use following definition: start on started webcache.

description "setup web cache"

start on  local-filesystems

task

script
    mkdir -p /tmp/cache/persistent
    mkdir -p /tmp/cache/models
    mkdir -p /tmp/cache/views
    chmod -R 777 /tmp/cache/
end script

Finally, you might consider using Vagrant shell provisioner to create needed cache directories.

answered Nov 26 '13 at 07:57

Goran Miskovic

496
3
11

Good answer, thank you. I did consider shell provisioner, but provisioning only runs once, by default (though it can be forced to run each time), which is why I was looking for a way to put the functionality into the vagrant guest. – SunSparc Nov 26 '13 at 17:47
1

I don't know requirements but usual [location](http://www.linfo.org/var.html) for application cache would be /var/cache/app-name. However, in that case it will be on the application e.g. you to clean up cache. :) – Goran Miskovic Nov 26 '13 at 18:40
That is good to know (though perhaps off topic). In this particular instance, the application is a web app, and as such is being run as the web user. The web user does not seem to have write access to `/var/cache` by default. – SunSparc Nov 26 '13 at 20:38
That is true. However, user www-data does not need write access to /var/cache but to /var/cache/app-name which could be granted during setup: `chown -R www-data:www-data /var/cache/app-name && chmod -R u+w /var/cache/app-name`. Speaking of been slightly off the topic: Whenever I found myself in a similar situation stepping back and asking myself which problem I am trying to solve and looking for alternatives turned out to be a good decision. In this case created directory structure will not persist since /tmp will be cleared on reboot. Instead of seeking for workaround redefine the problem. :) – Goran Miskovic Nov 26 '13 at 22:35
I agree. Though in this case I do not mind the data being cleared on reboot since it is for development only. Though using `/var/cache/app` I could change the script to clear it for me instead of recreating it. Both are viable solutions for my current situation. Thanks for all the feedback. – SunSparc Nov 26 '13 at 23:16

Martijn · Answer 2 · 2016-03-24T09:31:28.117

3

Though the accepted answer by @schkovich is certainly sufficient, I wanted to add that Vagrant emits a vagrant-mounted event. This event is emitted even after local-filesystems. I just had a situation in which I got the same error as described in the question, which could only be solved by:

start on vagrant-mounted

Source: this blog post.

edited Mar 24 '16 at 09:31

answered Jun 24 '15 at 19:10

Martijn

5,491
4
33
41

score 0 · Answer 3 · answered Nov 25 '13 at 20:11

While reading through the "Upstart Intro, Cookbook and Best Practises" I found a section about "Normal start" which uses runlevels for triggering an upstart script. Adjusting my script as follows allowed the script to run after /tmp/ was mounted:

start on runlevel [2345]

There may well be other solutions that are equally viable.

Upstart script needs to run after /tmp is mounted and writable

3 Answers3