[11:14] <nibbo> like this guy http://serverfault.com/questions/267016/how-can-i-use-upstart-with-vendor-supplied-startup-programs I have two commands for starting/stopping my service. Is it possible to use upstart for this? I guess it bypasses alot of the nice things with upstart though
[16:15] <bencc> I'm using "limit nofile 20000 20000" at the top of my upstart script
[16:15] <bencc> how can I test if this is being set?
[17:04] <teolicy> Hi. I have an Ubuntu server (10.10) which booted without a runlevel, I'm rather baffled as to why. 'who -r' outputs nothing, and /etc/rcX.d scripts didn't run so I'm missing non-upstart services.
[17:04] <teolicy> Anyone here knows what could be the cause? Where in upstart / modern Ubuntu (10.10) can I see the default runlevel?
[18:53] <ion> nibbo: Replied at serverfault
[20:00] <bencc> I'm using limit nofile 20000 20000 for an erlang server
[20:01] <bencc> but the "beam" process of the erlang server still has 1024 nofile limit
[20:03] <ion> Try
[20:03] <ion> limit nofile 20000 20000
[20:03] <ion> task
[20:03] <ion> script
[20:03] <ion>   ulimit -a >/tmp/ulimit.out 2>&1
[20:03] <ion> end script
[20:03] <nibbo> ion: thanks for rocking my socks of!
[20:03] <nibbo> off*
[20:04] <nibbo> Now I am just having the problem of wanting to execute the command in a specific directory. Using script blocks, but a simple "cd" before does not seem to work. Any ideas?
[20:04] <bencc> ion: I don't understand the syntax of the task script part
[20:05] <bencc> let me dpaste and see if I got it right
[20:05] <ion> nibbo: init(5), /chdir
[20:05] <ion> bencc: Just paste all of that to ulimit-test.conf and run ‘start ulimit-test’
[20:06] <bencc> ok
[20:06] <nibbo> ion: Please elaborate. I do not quiet get what you mean.
[20:07] <ion> Let me try it here…
[20:08] <ion> Here it added to /tmp/ulimit.out: nofiles              20000
[20:08] <ion> So it seems to work at least here.
[20:08] <ion> Could beam apply its own limit?
[20:09] <bencc> ion: I've increased the limits to all users so I need to remove it first
[20:10] <ion> % ulimit -n 2000 
[20:10] <ion> % erl
[20:10] <ion> 1> os:cmd ("ulimit -n").
[20:10] <ion> "2000\n"
[20:10] <ion> Apparently not.
[20:10] <ion> Do you get ‘nofiles 20000’ in /tmp/ulimit.out when you start ulimit-test?
[20:10] <bencc> ion: this is what I got: http://dpaste.com/544785/
[20:11] <bencc> after 'sudo start ulimit-test'
[20:11] <ion> Alright, Upstart seems to work correctly then.
[20:11] <ion> And beam doesn’t seem to apply its own limit either. I’m out of ideas.
[20:12] <ion> Except for manual investigation.
[20:12] <bencc> maybe beam apply its own limits when it is started by the script in a release
[20:12] <bencc> what do you mean by manual investigation?
[20:13] <bencc> it defines number of ports with -env ERL_MAX_PORTS 4096 but I don't see settings for nofiles
[20:13] <ion> The usual debugging. Running the service from the command line and seeing if it gets a lower limit. Running it with strace -f -o /tmp/service.strace from Upstart and seeing what sets the limit. Adding ulimit -n calls to various places in the code to see at what point the limit gets set.
[20:14] <bencc> I'll do that
[20:14] <bencc> the start script has RUNNER_USER=myapp
[20:14] <bencc> maybe that's changes stuff? because upstart run with root, right?
[20:15] <ion> I take it the script doesn’t start a new PAM session? Because that would most likely affect ulimit.
[20:15] <bencc> it has:
[20:15] <bencc> # Make sure this script is running as the appropriate user
[20:15] <bencc> if [ ! -z "$RUNNER_USER" ] && [ `whoami` != "$RUNNER_USER" ]; then
[20:15] <bencc>     exec sudo -u $RUNNER_USER -i $0 $@
[20:15] <bencc> fi
[20:16] <ion> sudo indeed starts a new PAM session.
[20:16] <bencc> good than that's the problem
[20:16] <bencc> can I do it without sudo?
[20:16] <bencc> because upstart run as root
[20:17] <bencc> I'm also using sudo in my upstart script which might also be unnecessary 
[20:17] <SpamapS> upstart scripts run as root
[20:17] <ion> You could try adding a user-specific entry to /etc/security/limits.conf
[20:18] <bencc> that works
[20:18] <ion> which is used by PAM
[20:18] <SpamapS> so su should be sufficient
[20:18] <bencc> doing this in upstart make it much more portable
[20:18] <bencc> that's what make upstart so cool
[20:18] <bencc> SpamapS: su doesn't start a new PAM?
[20:19] <bencc> instead of 'exec sudo -u myapp -i myapp start' I need 'exec su -u myapp -i myapp start' ?
[20:19] <SpamapS> it does with -l
[20:19] <bencc> SpamapS so what is the correct way to run a script in upstart as another user?
[20:20] <SpamapS> su is the recommended way, not sure there is a "correct" way
[20:20] <SpamapS> Its been suggested that a 'user' stanza would make sense.
[20:20] <bencc> does 'exec su -u myapp -i myapp start' starts a new PAM?
[20:21]  * SpamapS would prefer it be 'run as [user x] [group y]' to keep the upstart stanzas as imperative as possible
[20:21] <SpamapS> bencc: I don't know that it actually runs login.. you should test it
[20:21] <SpamapS> bencc: certainly if it doesn't, and thats what you need.. then maybe sudo is more appropriate.
[20:22] <bencc> not sure I understand
[20:22] <ion> Both su and sudo start a PAM session.
[20:22] <bencc> if "limit nofile 20000 20000" works but a command that run a script as another user starts a new PAM than what's the point with the limit nofile setting
[20:24] <ion> daemontools seems to come with /usr/bin/setuidgid which might be useful here.
[20:24] <ion> The daemontools package
[20:26] <bencc> thanks
[20:27] <bencc> maybe editing limits.conf is the correct way to do it
[20:27] <bencc> I just don't know