Configuring limits globally

[James Hunt]

On 09/02/12 08:49, Lukáš Nykrýn wrote:
> Lukáš Nykrýn píše v Čt 10. 11. 2011 v 11:24 +0100:
>> Steve Langasek píše v Út 08. 11. 2011 v 09:40 -0800:
>>> On Tue, Nov 08, 2011 at 11:43:34AM +0000, James Hunt wrote:
>>>> On 08/11/11 10:51, Lukáš Nykrýn wrote:
>>>>> Hello,
>>>>> I want to ask if this patch
>>>>> https://bugs.launchpad.net/upstart/+bug/282854 was considered for
>>>>> inclusion or if there are some issues that needs to be worked on.
>>>>> This was possible in SysVinit so I think it is very unpleasant that
>>>>> Upstart does not provide possibility to change limits globally.
>>>
>>>> This would be a useful idea. However, there is quite a lot of work still
>>>> to do to have the patch accepted.  See my comments:
>>>
>>>> https://bugs.launchpad.net/upstart/+bug/282854/comments/2
>>>
>>> As far as I can see, there isn't even a patch that's been proposed yet?
>>>
>>> FWIW, a workaround for this would be to set global limits in the initramfs
>>> (or via a diversion of /sbin/init) before calling upstart.  Not pretty, but
>>> would do the job, while we don't have a patch.
>>>
>>
>> I think that adding other stanzas to init.conf in the same way like is
>> in this patch for limit would be quite easy, most of it can be taken
>> from parse_job and if there is a chance that this will be accepted I can
>> prepare it. But if somebody thinks that this is not necessary or
>> unwanted it would be good to known.
>>
>> Lukas
> 
> Hello,
> I was thinking about implementing possibility of setting global value
> for some of the stanzas. My idea is to share parse_ functions between
> parse_conf and parse_job (writing parse_* functions specifically for
> parse_conf would lead to duplicities in code). Main principle is that,
> parse_conf will create "template" JobClass which than will be passed to
> parse_job and used in case of creating new class.
> I have begun to implement this, but I came to some questions:
> 1) Is this idea acceptable or does it need some changes or this behavior
> should not be in upstart?
Hi Lukáš - sorry, this mail seems to have "fallen through the cracks". I think the strategy you're
proposing makes sense.

> 2) How to handle this from view of sessions? Should there be only one
> configuration file for all jobs or one for every job dir or some
> hierarchical structure.
If we allow /etc/init.conf, we should allow ~/.init.conf too. But ~/.init.conf would only affect
jobs in ~/init/ for that particular user.

Should be limits set by the stanzas
> in /etc/init.conf "mandatory" or can user overwrite them?
I think user jobs (~/.init/*.conf) should be able to override the values in ~/.init.conf as this
would then mirror the behaviour of system jobs (/etc/init/*.conf) overriding values in
/etc/init.conf. So, we'd have something like this:

# system job files (in priority order)

/etc/init.override   # XXX: disallow?
/etc/init.conf
/etc/init/job.override
/etc/init/job.conf

# User jobs (in priority order)
~/.init.override   # XXX: disallow?
~/.init.conf
~/.init/job.override
~/.init/job.conf

I'm wondering though if we should disallow /etc/init.override and ~/.init.override (in other words
only allow override files for concrete *jobs*) as there is little value in adding extra complexity
at the "template level" since /etc/init.override and ~/.init.override will be editable either by an
admin or a user (respectively).

Users can't actually override the limits for user jobs of course as Upstart setuid()'s to the user
as early as possible such that if a user attempts to set a limit above what the system policy
allows, the job will fail to start.

> 3) Are there any new stanzas which should be only in parse_conf?
I don't _think_ so, but there are certainly stanzas that should *not* be allowed in parse_conf()
(like "stanza", "respawn", "script").

One concern I have with "init.conf" is the ability for an admin to inadvertently make their system
unbootable by specifying a bad set of these default/template values. As such, and continuing with
our policy of adding command-line options to give Upstart the ability to revert to previous
behaviour [1], I think we would need a command-line option such as '--no-default-config' which would
make Upstart ignore /etc/init.conf entirely to allow the system to be booted and /etc/init.conf to
be corrected.

Kind regards,

James.
--
James Hunt

[1] - http://upstart.ubuntu.com/cookbook/#command-line-options
____________________________________
http://upstart.ubuntu.com/cookbook
http://upstart.ubuntu.com/cookbook/upstart_cookbook.pdf