using rc.subr only by root restriction

[Adrian Chadd]

On 26 June 2017 at 00:32, Anthony Pankov <ap00 at mail.ru> wrote:
> Hello,
>
>> this was my fault. :)
>
> Did you mean that you've commited a patch which change the behavior?
>
>> There are some limits that you can set as a user.
>
>> I think this is a fine change; but I can't speak for the correctness
>> of using rc.subr as a general library set for your own purposes. :0
>
> At this time I don't think that my patch is a best solutions.
>
> First  of  all  I  don't see any explanation of ${name}_login_class in
> rc.subr(8).  Silently  applying  'daemon'  login class to all services
> seems to be very surprising. I think there are  people who modified 'daemon'
> login  class  and  get  a weird  result in their system. I know how
> complex to investigate such things.

It was supposed to be daemon class. That was the unclear part of it all.

If it runs as part of startup, it'd get the daemon class.

If you ran it using "service", you got whatever was in the users
class. So your daemons would then get the "root" class, and get a LOT
more file descriptors, etc.

> May  be  we  can agree at "explicit is better than implicit" principle
> and  do  not  apply  a  login  class  when  ${name}_login_class is not
> declared explicity?
>
> It will solve my problem too.

No, because the whole point of the services at startup was to actally
get the 'daemon' class. That was the intention all along and what
happened to things at startup time. My patch was to bring running
"service" in line with what the system did at startup time.

It sucks - ideally we'd have a service manager that you'd request to
run things on your behalf and it'd always apply a consistent set of
things, like login class.


-adrian