Service from Python 3 virtual environment does not start at boot

Rastaf

Rastaf

I have created a service from a Python 3 virtual environment that works fine when called (start, stop, restart, status) from the terminal, also when the user is root. But although it's active for boot (shows up in service -e) it does not get started on boot.

I tried to get it started later in the sequence using the REQUIRE option in the rc.d script with some more dependencies, but that didn't help.

Of course I added tcv_enable="YES" to the rc.conf.

Here is my rc.d script:

Bash: 
#!/bin/sh

# PROVIDE: myapp
# REQUIRE: DAEMON

. /etc/rc.subr

instancename="myapp"
name="myapp"
instancepath="/my/path/to/zope-instances/${instancename}"

rcvar="${name}_enable"

zope="/my/path/to/Zope"
#procname needed for stopping daemon
procname="${zope}/bin/python"
pidfile="/var/run/instances/${instancename}.pid"
zope_ini="${instancepath}/etc/zope.ini"

. /path/to/my/own/functions/myrc.subr

command="${zope}/bin/runwsgi"

# daemon needs user if not called as myuser
daemon_argument=""

if ! [ `whoami` = "myuser" ]; then
    daemon_argument='-u myuser'
fi

start_cmd="/usr/sbin/daemon $daemon_argument $command ${zope_ini}"

load_rc_config "$name"
run_rc_command $*

I'm at the end of my wits... Any suggestions are greatly appreciated!
 
Maybe the problem lies elsewhere. After booting I tried quickly to check if the process exists (with the ps command) and it did, with a state of "Ds". Some seconds afterwards, it had disappeared, so apparently it started and shut down immediately afterwards. That's still strange, because it does not behave like that when started manually.
 
These things happen. Placing a task at its proper place in the rc.d sequence usually is some work, as there happen things one usually has not thought about.
One can go single-user and then start the respective components manually, one-by-one, to see what happens (rcorder() will show the sequence).
 
SirDice Thank you for the advice, unfortunately that didn't solve it.
I guess next I'll try a cron job with @reboot and a time delay. The only thing I can think of at the moment is that maybe it depends on another service that takes some time to start up, so putting my service in the right position might not be enough.

I've also already tried putting a time delay in the rc.d script, but that had the strange effect to prevent other (later) services from starting (which where in no way dependent on this one). But that isn't really an option anyway as I'd like to start the service manually without a delay.
 
@PMc It's on a remote server, so single user mode is not a practical option unfortunately. But I checked the order of the services with
Code: 
service -e
(which is a way of calling rcorder if I understood correctly), so I know the sequence but I cannot try to start them one by one. I guess starting them manually would work as they'd have enough time to start up before my service comes into play.
 
cron @reboot did the job for me, even without a time delay.

So the issue is solved for me, but I'm still a bit unhappy that I couldn't solve it with the services configuration. :-/
 
Sounds like an environment issue.
I would fully qualify that whois statement with it's path.
Code: 
if ! [ `whoami` = "myuser" ]; then
with
Code: 
if ! [ `/usr/bin/whoami` = "myuser" ]; then
 
leebrown66 said:
Sounds like an environment issue.
I would fully qualify that whois statement with it's path.
Code: 
if ! [ `whoami` = "myuser" ]; then
with
Code: 
if ! [ `/usr/bin/whoami` = "myuser" ]; then
Click to expand...

Thank you, that's a very interesting thought, unfortunately it's not the issue. I just tried it and I previously had already tried to set the daemon argument without the condition.
 
You must log in or register to reply here.
Back
Top