It's not the same. Irregardless you are running the script as user root and
class tor. Then the script executes the daemon as `user`. I don't know if it
will have the desired effect, but perhaps do
# usermod -L tor tor_user. Change tor_user to the correct user.
Sent from BlueMail
On Jul 7,
On 07/07/17 15:11, Alexander Nasonov wrote:
Edgar Pettijohn wrote:
Look at rc.subr. it calls su to start the daemon. Look at the
manual for rc.subr I think there are some variables you could add
to the rc.d script to change the behavior.
I only see su -m user -c ... in rc.subr. It's not the
Edgar Pettijohn wrote:
> Look at rc.subr. it calls su to start the daemon. Look at the
> manual for rc.subr I think there are some variables you could add
> to the rc.d script to change the behavior.
I only see su -m user -c ... in rc.subr. It's not the same as su -c class user.
$ man su
..
Sorry for top post, this mua sucks.
Look at rc.subr. it calls su to start the daemon. Look at the manual for
rc.subr I think there are some variables you could add to the rc.d script to
change the behavior.
Sent from BlueMail
On Jul 7, 2017, 1:50 AM, at 1:50 AM, Alexander Nasonov
Edgar Pettijohn wrote:
> did you:
> # cap_mkdb /etc/login.conf
Yes, I did run it.
> > My understaning is that the tor process doesn't move to the "tor"
> > login class when switching a user. As a result, I can't restart it
> > when I login as root. I have to set the login class with su -c like
>
On 07/06/17 16:00, Alexander Nasonov wrote:
Another issue on my server was trying to start a service (tor relay in
my case) with a low limit on open files in the default login class.
The relay starts as root but then it swiches to user "tor". I set the
login class of the tor user to "tor"
Another issue on my server was trying to start a service (tor relay in
my case) with a low limit on open files in the default login class.
The relay starts as root but then it swiches to user "tor". I set the
login class of the tor user to "tor" which further extends a limit of
the daemon class.
