# [Beginner] Service restart permission - No errors reported but it does not work



## Zucca (Dec 2, 2020)

I have followed this guide and everything seems to work.
The only problem I have I can not start or restart the "octoprint" service as user "octoprint" (yes the service and the user name are the same):


```
$ service octoprint status
octoprint is running as pid 1202.
$ service octoprint stop
Stopping octoprint.
Waiting for PIDS: 1202.
$ service octoprint status
octoprint is not running.
$ service octoprint start
Starting octoprint.
$ service octoprint status
octoprint is not running.
$ service octoprint restart
octoprint not running?
Starting octoprint.
$ service octoprint status
octoprint is not running.
```

This is the fist time for me that FreeBSD is not reporting an error and not getting the job done, so that's why I post here.
I would like to understand what is the problem.

 As root user no problem:


```
root@op_server:/ # service octoprint status
octoprint is not running.
root@op_server:/ # service octoprint start
Starting octoprint.
root@op_server:/ # service octoprint status
octoprint is running as pid 1202.
```

so I think it is a permission problem but I do not know what I can do to fix it.

Here some investigations I have done:


```
$ cd /usr/local/etc/rc.d/
$ ls -l
total 23
-rwxr-xr-x  1 root  wheel   689 Oct 17 01:33 git_daemon
-rwxr-xr-x  1 root  wheel  1954 Oct 28 20:11 octoprint
-rwxr-xr-x  1 root  wheel  1021 Oct 17 01:26 svnserve
-rwxr-xr-x  1 root  wheel  1239 Sep 17 06:24 tcsd
-rwxr-xr-x  1 root  wheel   628 Sep 17 06:21 tpmd
```

here octoprint looks good.


```
$ id
uid=1002(octoprint) gid=1002(octoprint) groups=1002(octoprint),5(operator),68(dialer)
```

here my octoprint service:


```
#!/bin/sh

# PROVIDE: octoprint
# REQUIRE: NETWORKING
# KEYWORD: shutdown

# *******DESCRIPTION: FreeBSD 12.1 - rc.d script for the 3D Printer Software OctoPrint. This script takes advantage of FreeBSD's rc.subr framework to start OctoPrint automatically at startup and to allow it to be controlled as a FreeBSD service (eg. service octoprint start). This script assumes you are running OctoPrint as a virtual python environment (py27-virtualenv), but it can easily be changed if you want.

# *******HELP:
# 1. To increase security we want to avoid running it as root so create a user named "octoprint" (or any name you want but then change the script to reflect the change) and add the user to the "dialer" group so it can access the USB serial port that connects to the 3D Printer.
# 2. Add the line "octoprint_enable="YES"" to the end of "etc/rc.conf" this will enable and start OctoPrint at boot time.
# 3. Place this rc.d script file in "/usr/local/etc/rc.d/" (make sure this file is executable, if not run: "chmod +x /usr/local/etc/rc.d/octoprint")
# 4. Make sure the variables below such as, "command", "octoprint_basedir", "command_interpreter", etc..., reflect the correct paths to your octoprint executable, base directory, and virtual python executable (if you are using a virtual python environment like this script does).
# 5. After startup the service can be controlled like any other service "service octoprint {start,status,reset,stop,start}"

. /etc/rc.subr

name=octoprint
rcvar="octoprint_enable"

: ${octoprint_enable:=no}

octoprint_user=octoprint
octoprint_group=${octoprint_user}
octoprint_user_path="/usr/home/${octoprint_user}"
octoprint_basedir="${octoprint_user_path}/.octoprint"

command_interpreter="${octoprint_user_path}/OctoPrint/venv/bin/python3.7"
command="${octoprint_user_path}/OctoPrint/venv/bin/${name}"
command_args="serve --basedir ${octoprint_basedir} > /dev/null 2>&1 &"

load_rc_config $name
run_rc_command "$1"
```

other infos:


```
$ ls -l OctoPrint/venv/bin/python3.7
-rwxrwxr-x  1 root  octoprint  15208 Oct 28 17:23 OctoPrint/venv/bin/python3.7
$ ls -l OctoPrint/venv/bin/octoprint
-rwxr-xr-x  1 octoprint  octoprint  240 Nov 30 21:53 OctoPrint/venv/bin/octoprint
$
```

Many thanks in advance!


----------



## richardtoohey2 (Dec 2, 2020)

Are there any logs?  There might be errors in those that help you track this down.


----------



## Zucca (Dec 2, 2020)

Good point! I forgot to mention that I already did that, I looked at


```
$ cd /var/log
$ ls
auth.log        dmesg.today     maillog.0.bz2   mount.today     utx.lastlogin
bsdinstall_log  dmesg.yesterday maillog.1.bz2   ppp.log         utx.log
cron            init.log        maillog.2.bz2   security        utx.log.0
debug.log       lpd-errs        messages        setuid.today    xferlog
devd.log        maillog         messages.0.bz2  userlog
```

but I did not find anything useful... This is puzzling me, why FreeBSD is not complaining in any way?
99% it is my service that has a bug.


----------



## monwarez (Dec 2, 2020)

Why do you want to start it manually as user octoprint? When you are launching a service that have
`octoprint_user=octoprint` as root (like at startup) it will use su to change user. So you cannot run su with the octoprint user(and you shouldn't else it defeat the purpose of using a non privileged user).

```
#       ${name}_user    n       User to run ${command} as, using su(1) if not
#                               using ${name}_chroot.
#                               Requires /usr to be mounted.
```


----------



## SirDice (Dec 2, 2020)

monwarez said:


> So you cannot run su with the octoprint user


Actually, you can. You can certainly su(1) to your own account without issues.

```
testuser@williscorto:~ % id
uid=1002(testuser) gid=1002(testuser) groups=1002(testuser)
testuser@williscorto:~ % su - testuser
Time to change your password? Type "passwd" and follow the prompts.
                -- Dru <genesis@istar.ca>
testuser@williscorto:~ % logout
testuser@williscorto:~ % su testuser
testuser@williscorto:~ % exit
testuser@williscorto:~ % id
uid=1002(testuser) gid=1002(testuser) groups=1002(testuser)
```



monwarez said:


> and you shouldn't else it defeat the purpose of using a non privileged user)


You can actually su(1) to a _different_ user account but you will need to know the password for that account:

```
testuser@williscorto:~ % su - dice
Password:
Time to change your password? Type "passwd" and follow the prompts.
                -- Dru <genesis@istar.ca>
dice@williscorto:~ % id
uid=1001(dice) gid=1001(dice) groups=1001(dice),0(wheel)
dice@williscorto:~ % logout
testuser@williscorto:~ % id
uid=1002(testuser) gid=1002(testuser) groups=1002(testuser)
```

The other restriction you may be familiar with is using su(1) to become the super-user aka root, only members of the wheel group are allowed to do that. 

```
testuser@williscorto:~ % id
uid=1002(testuser) gid=1002(testuser) groups=1002(testuser)
testuser@williscorto:~ % su - root
su: Sorry
```

A so-called "non-privileged" user can actually do a lot more than most people realize. That "non-privileged" label is a bit of a misnomer because user accounts have lots of privileges. They're certainly limited in what they can do that's true. But 'non-privileged' suggests it can't do anything at all, which is a false assumption.

(_Mod: moving this thread to userland scripting, seems more at place there_)


----------



## George (Dec 3, 2020)

> This script assumes you are running OctoPrint as a virtual python environment (py27-virtualenv),


Wasn't there a switch to py37 recently?

I am not sure but " > /dev/null 2>&1 &" as command line arguments might suppress error logs.


----------



## Zucca (Dec 3, 2020)

monwarez said:


> Why do you want to start it manually as user octoprint?


Yeah, the reason I want to do that is because sometime when I upgrade some octoprint plugins I need to restart the service to finish the installation process. In octoprint there is a setting where I can enter the command to restart the service. Normally I just reboot the box and since user octoprint is in the operator group it is not a problem.

Soooo it is not a major issue to solve.

The point here is since FreeBSD is THE Operating System (all the others are pretending to run stable), getting no error and having that service not up and running was for me a big surprise, I almost fall off the chair. I would like to investigate what it is going on here and learn (for sure) something.



Elazar said:


> Wasn't there a switch to py37 recently?
> 
> I am not sure but " > /dev/null 2>&1 &" as command line arguments might suppress error logs.


Octoprint works with py37 no problem. Interesting about the /dev/null stuff... so I could try to remove those arguments as a test and see what happens, correct?

BTW, Thanks to all of you.


----------



## monwarez (Dec 3, 2020)

If you need octoprint to restart it then I guess this is the line that prevent it

```
octoprint_group=${octoprint_user}
```


```
#       ${name}_group   n       Group to run chrooted ${command} as.
#                               Requires /usr to be mounted.
#
```
This seems to require `chroot` which may be the issue here.


----------

