upstart job fails to start with "limit nofile unlimited unlimited"

[Nobuto Murata]

Upstart cookbook refers to "limit nofile unlimited unlimited".
http://upstart.ubuntu.com/cookbook/#limit

However it fails to start jobs, for example:

$ sudo stop cron
$ echo limit nofile unlimited unlimited | sudo tee /etc/init/cron.override
$ sudo start cron
start: Job failed to start

Feb 11 16:02:52 lifebook kernel: [36027.452599] init: Failed to spawn cron main process: unable to set "nofile" resource limit: Operation not permitted

ProblemType: Bug
DistroRelease: Ubuntu 15.04
Package: upstart 1.13.2-0ubuntu7
ProcVersionSignature: Ubuntu 3.18.0-13.14-generic 3.18.5
Uname: Linux 3.18.0-13-generic x86_64
.etc.init.cron.override: limit nofile unlimited unlimited
ApportVersion: 2.16.1-0ubuntu2
Architecture: amd64
CurrentDesktop: Unity
Date: Wed Feb 11 16:03:27 2015
EcryptfsInUse: Yes
InstallationDate: Installed on 2015-02-09 (1 days ago)
InstallationMedia: Ubuntu 15.04 "Vivid Vervet" - Alpha amd64 (20150207)
ProcKernelCmdline: BOOT_IMAGE=/vmlinuz-3.18.0-13-generic.efi.signed root=/dev/mapper/ubuntu--vg-root ro quiet splash vt.handoff=7
SourcePackage: upstart
UpgradeStatus: No upgrade log present (probably fresh install)
UpstartBugCategory: System
UpstartRunningSessionVersion: upstart 1.13.2
UpstartRunningSystemVersion: init (upstart 1.13.2)
modified.conffile..etc.at.deny: [inaccessible: [Errno 13] Permission denied: '/etc/at.deny']
modified.conffile..etc.libvirt.qemu.conf: [inaccessible: [Errno 13] Permission denied: '/etc/libvirt/qemu.conf']
modified.conffile..etc.libvirt.qemu.networks.default.xml: [inaccessible: [Errno 13] Permission denied: '/etc/libvirt/qemu/networks/default.xml']

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Jose Gonzalez (savant)]

I'm also seeing this on multiple Ubuntu 14.04 servers, but in regards to the docker-engine upstart file. It's unclear to me why this is the case, as a similarly configured server does not have this issue.

[Jose Gonzalez (savant)]

I figured out our problem. We lowered `fs.nr_open` on the non-working systems from the - apparent default - of `1048576` to `655360`. The docker package set a limit higher than our new limit, so the process was failing to start.

Upstart is going away - boo - but in case anyone sees this issue in the future, running the following was the fix for me:

```
sysctl -w fs.nr_open=1048576
```