Chris's Wiki :: blog/linux/UpstartDependencyProblem Commentshttps://utcc.utoronto.ca/~cks/space/blog/linux/UpstartDependencyProblem?atomcommentsDWiki2012-12-11T18:27:01ZRecent comments in Chris's Wiki :: blog/linux/UpstartDependencyProblem.By Chris Siebenmann on /blog/linux/UpstartDependencyProblemtag:CSpace:blog/linux/UpstartDependencyProblem:0aee99d697d1faa83ea7c54d8d0ffeb49bf735d2Chris Siebenmann<div class="wikitext"><p>I don't think that per-user Upstart scripts will help us. There are
several things wrong with them in an environment like ours. Off the
top of my head:</p>
<ul><li>according to the documentation, a user has to run <code>initctl</code> first before
their <code>$HOME/.init</code> is read. So how does that happen automatically after
the machine is rebooted?<p>
</li>
<li><code>$HOME/.init</code> is global, not per-machine. We don't want webserver jobs
starting on any machine that the user happens to run <code>initctl</code> on (or
vice-versa for boot time jobs on other machines). This gets worse if
<code>$HOME/.init</code> is processed automatically.<p>
</li>
<li>if <code>$HOME/.init</code> was processed automatically and assuming that we
could somehow delay processing until after NFS mounts were up,
scanning for it is something that very much does not scale. We have
over 1500 accounts with NFS-mounted home directories; I do not want
any system looking for <code>$HOME/.init</code> in all of them.</li>
</ul>
<p>Apart from the start ordering, crontab is exactly what we need; it is
automatic, per-machine, and requires registration (avoiding mass scans).</p>
</div>2012-12-11T18:27:01ZFrom 65.110.252.109 on /blog/linux/UpstartDependencyProblemtag:CSpace:blog/linux/UpstartDependencyProblem:c5f2fa922dff03085b0c7e44787dc915c75c4587From 65.110.252.109<div class="wikitext"><p>I suspect there are better examples, but here, it looks like the problem isn't that Cron's dependency changed, but that those per-user crontabs are really additional jobs (the webservers) that depend on NFS mounts. Worse, it's not even cron itself, it's the fact that you're hacking Cron to serve as an additional init system.</p>
<p>It looks like you can add <a href="http://upstart.ubuntu.com/cookbook/#user-job">per-user Upstart scripts</a>, which makes a lot more sense. (I assume you can do something similar under systemd.)</p>
<p>I think you might be onto something, but I'm not sure this is a good example.</p>
<pre>
-- Dave
</pre>
</div>2012-12-10T19:44:38ZFrom 93.34.59.252 on /blog/linux/UpstartDependencyProblemtag:CSpace:blog/linux/UpstartDependencyProblem:0325699de6f4eba9844a71db799a1caafe4f1816From 93.34.59.252<div class="wikitext"><p>So, how do I start an app server only after mysql has been started? That was easy with the rc.d system.</p>
</div>2011-07-23T09:59:07ZBy Chris Siebenmann on /blog/linux/UpstartDependencyProblemtag:CSpace:blog/linux/UpstartDependencyProblem:5f76fc654be83b7462a5edbeabae433aeb91f9edChris Siebenmann<div class="wikitext"><p>I did some looking into systemd. While the question is hard to answer
from the available systemd manual pages (I looked <a href="http://0pointer.de/public/systemd-man/">here</a>), it appears likely that
you can glue something together that doesn't require modifying
supplied service configuration files.</p>
<p>(A general systemd index and reference is <a href="http://www.freedesktop.org/wiki/Software/systemd">here</a>.)</p>
</div>2011-04-26T17:01:19ZBy gsauthof on /blog/linux/UpstartDependencyProblemtag:CSpace:blog/linux/UpstartDependencyProblem:d584f7c5ac5dc1b86b253c372341a170ba965c3fgsauthof<div class="wikitext"><p>Chris, did you have a look at the new systemd project? (it replaces upstart in FC15) I am wondering if you would have similar dependency problems with systemd.</p>
</div>2011-04-26T09:13:44ZFrom 205.208.123.236 on /blog/linux/UpstartDependencyProblemtag:CSpace:blog/linux/UpstartDependencyProblem:921f71f8cf92fa7c9cc7a5b3348c7c9d4ed33630From 205.208.123.236<div class="wikitext"><p>"Under the old init.d approach you could specifically set an order for services to load within a runlevel", and you can still do this in RHEL6, because that traditional system is implemented in Upstart. That is, RHEL6 uses Upstart as a direct replacement for init, instead of the hybrid approach Ubuntu uses (where there are upstart-style and deb-init-style scripts). There may be downsides to RHEL's approach, but I prefer it precisely because of Chris' complaint.</p>
<p>Elijah</p>
</div>2011-04-23T23:01:06ZFrom 70.95.102.101 on /blog/linux/UpstartDependencyProblemtag:CSpace:blog/linux/UpstartDependencyProblem:e0c531d85f96cbac8d3a215317df895d98f3ab87From 70.95.102.101<div class="wikitext"><p>Elijah, I don't think from Chris's blog that its the "What run level" problem, it's that everything is now controlled within the specific init script for the service.
Under the old init.d approach you could specifically set an order for services to load within a runlevel, within /etc/init.d/rc.(1|2|3|4|5) (location varies based on the distribution, annoyingly, might find them under /etc/rc.d), by altering the number on the symbolic link. Services inside that directory get started in alphanumeric order. Even if the init script got changed you didn't have to worry, the symbolic links were what set the start order.</p>
<p>In Ubuntu there is a command line tool, update-rc.d, which allows you to assign services to levels, so your assertion that you can't use the normal tools for the job aren't true. Debian has been using update-rc.d from nearly the beginning of its existence (and Ubuntu has from day 1 as a consequence). As someone who uses both regularly, I can assure you it's really not all that different from chkconfig.</p>
<p>Under Ubuntu's implementation of upstart the files Chris is talking about are in /etc/init. Taken from the start of mysql.conf file in there on an Ubuntu 10.10 vps:</p>
<pre>
# MySQL Service
</pre>
<pre>
description "MySQL Server"
author "Mario Limonciello <superm1@ubuntu.com>"
start on (net-device-up
and local-filesystems
and runlevel [2345])
stop on runlevel [016]
....
</pre>
<p>it then goes on to define the startup process itself. What Chris isn't happy about is that the dependencies, that 'start on' section, are all set in the file inside that directory. The risk is that if the package manager hasn't been told these are protected config files it could just up and replace them without warning, removing any custom dependencies you've got.
Other packages like Apache have their .d directories so that 1) the main config file can be updated or replaced by the package manager without disrupting any custom changes, and 2) it's easier to manage by having nicely segmented configuration.</p>
</div>2011-04-23T18:29:56ZFrom 70.30.90.144 on /blog/linux/UpstartDependencyProblemtag:CSpace:blog/linux/UpstartDependencyProblem:1f27aa669423894dccd536af17ba7b962cf5c162From 70.30.90.144<div class="wikitext"><p>You may want to check out the "rcNG" system that a lot of the BSDs use. It is also referred to as the "rc.d" system:</p>
<p><a href="http://www.netbsd.org/docs/guide/en/chap-rc.html">http://www.netbsd.org/docs/guide/en/chap-rc.html</a> <br>
<a href="http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/configtuning-rcd.html">http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/configtuning-rcd.html</a> <br>
<a href="http://www.mewburn.net/luke/papers/rc.d.pdf">http://www.mewburn.net/luke/papers/rc.d.pdf</a> (USENIX 2001 paper) <br>
</p>
<p>It was originally created on NetBSD, but FreeBSD and Dragonfly have converted to using it as well:</p>
<p><a href="http://www.freebsd.org/cgi/man.cgi?query=rc">http://www.freebsd.org/cgi/man.cgi?query=rc</a> <br>
<a href="http://www.freebsd.org/cgi/man.cgi?query=rcorder">http://www.freebsd.org/cgi/man.cgi?query=rcorder</a> <br>
<a href="http://www.freebsd.org/cgi/man.cgi?query=rc.conf">http://www.freebsd.org/cgi/man.cgi?query=rc.conf</a> <br>
</p>
</div>2011-04-23T16:21:56ZFrom 71.57.69.135 on /blog/linux/UpstartDependencyProblemtag:CSpace:blog/linux/UpstartDependencyProblem:e75260ee3799f1ea04cfd7e5d4edf5dc20fdaf6fFrom 71.57.69.135<div class="wikitext"><p>This is just Ubuntu's poor design. Fedora/RedHat implement the traditional init system using Upstart, so that you can continue to use the normal chkconfig tool to manage what services start at which runlevel, regardless of Upstarts native support for such things.</p>
<p>Elijah</p>
</div>2011-04-23T14:33:00Z