First off, I would say that there is no need to mount /proc, if its not necessary.  For the most part, job files, wouldn't even require /proc to be mounted.  Following on from that logic, there is only 1 place, that I can see, that actually attempts to use a /proc file, when upstart changes the oom_adj value.  So, first check to see if the job file is even changing that value, if not, /proc is not needed and skip that step.  Second, if it does need /proc, then what?  You could simply fail the job, quietly ignore the error, or mount proc?  I guess that part is up for debate yet.

It should not use system(), it opens itself up for other problems.

Jeff

Garrett Cooper wrote:
On Mon, Feb 23, 2009 at 2:14 PM, Adam Sampson <[email protected]> wrote:
  
Scott James Remnant <[email protected]> writes:

    
Nobody has supplied a patch.
      
Well, here's what I'm using happily, but I suspect a little more finesse
would be useful. ;)

http://offog.org/darcs/garstow/sys/upstart/files/mountproc.diff
    

Uh, that will almost certainly fail if it can't allocate a shell
because system(3) calls execve(2) and allocates a shell.

Using mount(2), like so, would be better:

#include <string.h>          /* For strerror(3). */
#include <errno.h>
#include <sys/mount.h>
#include <linux/kernel.h> /* For panic(2). */

/* ... */

if (mount("none", "/proc", "proc", 0, NULL) < 0) {
    /* Change to OOM support not available, etc for this instead of a panic? */
    panic ("Failed to mount /proc: %s\n", strerror(errno));
}

    You'll potentially need to do similar for /dev and /dev/console
(we currently do that, but I'm not sure if /dev/console is needed...).
Combined with proper calls to fstab(5) with getent, this should be
solved properly in less than 30 lines.
Cheers,
-Garrett

  

 

 

Disclaimer: The information contained in this transmission, including any

attachments, may contain confidential information of Panasonic Avionics

Corporation.  This transmission is intended only for the use of the

addressee(s) listed above.  Unauthorized review, dissemination or other use

of the information contained in this transmission is strictly prohibited.

If you have received this transmission in error or have reason to believe

you are not authorized to receive it, please notify the sender by return

email and promptly delete the transmission.

-- 
upstart-devel mailing list
[email protected]
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/upstart-devel

Reply via email to