I have a python script which manages an Erlang daemon. Everything works fine when used through a shell once the system is initialized.
Now, when I included the same script under "/etc/init.d" and with the symlinks properly set in "/etc/rcX.d", the python script still works but my Erlang daemon fails to start and leaves no discernible traces (e.g. crash_dump, dmesg etc.)
I also tried setting the environment variable "HOME" through 'erl -env HOME /root' and still no luck.
Any clues?
To manually run the script the same way the system does, use service daemon start if you have that command, or else try
cd /
env -i LANG="$LANG" PATH="$PATH" TERM="$TERM" /etc/init.d/daemon start
That forces the script to run with a known, minimal environment just like it would at startup.
Thanks for this answer - I was having a devil of a time starting the "Alice" RESTful interface to rabbitmq on startup. The key was using 'env HOME=/root /path/to/alice/startup/script' in my init script.
Related
I come with a Vagrant script that pulls down an bionic 18 which then runs an ansible playbook which generates two EC2s ubuntu 20.04 which successfully run though every "task:" I assign. I am able to run everything I want in a largely automated download and execution for a publisher subscriber method. Here is the issue: I can run my .sh and .py scripts manually and the systems works, but when I use the ansible methods I must be doing something wrong much like these solutions point to:
Shell command works on direct hosts but fail on Ansible
ansible run command on remote host in background
https://superuser.com/questions/870871/run-a-remote-script-application-in-detached-mode-in-ansible
What I want to do is simply correct the issue with this, and run it in the background.
- name: Start Zookeeper
shell: sudo /usr/local/kafka-server/bin/zookeeper-server-start.sh /usr/local/kafka-server/config/zookeeper.properties </dev/null >/dev/null 2>&1 &
- name: Sleep for 30 seconds and continue with play
wait_for:
timeout: 15
- name: Start Kafka broker
shell: sudo /usr/local/kafka-server/bin/kafka-server-start.sh /home/ubuntu/usr/local/kafka-server/config/server.properties </dev/null >/dev/null 2>&1 &
I have tried it with just a single "&" at the end as well as passing in explicit calls to my user account "ubuntu". I've used the "become: yes". I really don't want to use a daemon especially since others seem to have used this successfully before.
I do want to note that a glaring sign to you that I can't seem to think through is that it hangs when I don't include the &, but if I do include the & it just outright fails, which made me think it was running, but the script won't proceed because these are listener processes.
# - name: Start Zookeeper
# become: yes
# script: /usr/local/kafka-server/bin/zookeeper-server-start.sh
# args:
# chdir: /usr/local/kafka-server/config/zookeeper.properties
This failed, and I'd rather not create another script to copy over the directories and localize it if there is a simple solution to the first block of code.
Multiple ways to skin this cat, but I'd rather just have my mistake on the shell ansible command fixed, and I don't see it.
As explained in the answers written in your third link:
https://superuser.com/questions/870871/run-a-remote-script-application-in-detached-mode-in-ansible
This happens because the script process is a child process from the shell spawned by ansible. To keep the process running after ansible has finished you would need to disown this child process.
The proper way to do this is configuring the software (zookeeper in your case) as a service. There are plenty of examples for this such as:
https://askubuntu.com/questions/979498/how-to-start-a-zookeeper-daemon-after-booting-under-specific-user-in-ubuntu-serv
Once you have configured it as a service, you can start it or stop it using ansible service module.
When I run my nodejs application on my Ubuntu Linux server using node server.js it works correctly, and outputs the value of the environment variable $db using process.env.db.
However, the app breaks when running sudo pm2 start server.js, seeing the environment variable as undefined.
I've tried adding the variable in the following files:
etc/environment: db="hello"
~/.ssh/environment : db="hello"
~/.bashrc : export db="hello"
I've also rebooted and run source ~/.bashrc to ensure the variable is available.
I think I've tried everything mentioned here, I don't know what else to do:
https://unix.stackexchange.com/questions/117467/how-to-permanently-set-environmental-variables
https://github.com/Unitech/pm2/issues/867
Why does an SSH remote command get fewer environment variables then when run manually?
https://serverfault.com/questions/389601/etc-environment-export-path
Note that saying source ~/.bashrc you are loading the variables on your current user. However, when you say sudo ... you are running with the user root, so this won't change.
What you can do is to use sudo with -E:
sudo -E pm2 start server.js
From man sudo:
-E, --preserve-env
Indicates to the security policy that the user wishes to reserve their
existing environment variables. The security policy may eturn an error
if the user does not have permission to preserve the environment.
Please refer to this thread https://github.com/Unitech/pm2/issues/204
Seems like your environment variables get's cached.
I deleted the pm2 process and started it again as normal. simply restarting the process didn't work though.
I have some cronjobs that I always used and worked fine. But now, trying to move everything to Docker containers, I'm running into these errors:
/usr/bin/service: 127: /usr/bin/service: stop: not found
/usr/bin/service: 128: exec: start: not found
They occur when executing things like "service restart nginx" these cronjobs. Note that the same commands work fine outside the cronjobs.
The PATH is correctly set in /etc/crontab . Adding it to the individual cronfiles in /etc/cron.d doesn't work either. I also tried changing SHELL=/bin/sh to SHELL=/bin/bash (even though it's insecure, but wanted to try) in /etc/crontab, didn't work.
Any ideas?
I solved it changing the command from
"service start mysql"
to
"/sbin/start mysql &"
Good luck
Enric
I am not sure, but I think that the problem is in paths. I believe you want to run /usr/sbin/service and not /usr/bin/service. You may try to specify full path for service instead of just service.
I need to understand the difference between starting a command using init.d script and service start.
For example what is the difference between
/etc/init.d/nginx start and service nginx start.
They do the same thing except service runs the script in a controlled environment. From the service(8) man page:
DESCRIPTION
service runs a System V init script in as predictable environment
as possible, removing most environment variables and with current
working directory set to /.
ENVIRONMENT
LANG, TERM
The only environment variables passed to the init scripts.
Furthermore:
Calling /etc/init.d/* scripts directly is deprecated by facts because:
On latest Debian/Ubuntu distro ( and derived ), sysvinit ( which was default init system ) has been replaced by either upstart or systemd. Thus, if one of the service is managed using either an usptart job or systemd unit configuration file, calling /etc/init.d/* will be a NOOP in sense that the script will exit without further information.
Instead, users must use the service command to start/stop/restart services. The service command is a wrapper which will invoke the right script, in as predictable environment as possible, whatever the init system in use ( sysinit, upstart or systemd ).
I'm using a Bootle Python Web Framework to develop webapps on Ubuntu.
Is there any effective way to daemonize script that starts default bottlepy webserver?
Thank you.
UPD: Now I'm using Supervisord for this purposes.
As reclosedev mentions, nohup ... & will work without fuss.
You can also use something like daemonize Which has more options than using nohup.
Personally I run the following while developing with autoreload switched on:
while true; do python app.py ; done
which restarts the server if I write something stupid. Other solutions will force you to restart your server for a syntax error.
Deployment happens behind apache or lighttpd.
On ubuntu I use following steps:
Remember to insert full path to templates into bottle.TEMPLATE_PATH
Make script executable (chmod +x <script_name>)
Make symlink to script w/o .py extension
Navigate to /etc/init.d and copy skeleton to <script_symlink_name>
Modify new init script
Change NAME to <script_symlink_name>
Change DAEMON to <path_to_script_symlink>
Change DAEMON_ARGS to ""
Change DESCRIPTION
Add "--background" switch to start-stop-daemon (line w/o "--test" switch) in do_start()
Make init script executabe
Test via "service <script name> start"
Set autostart: update-rc.d <script-name> defaults
You can use supervisord or monit to start/stop and restart the app.