I want to automatically start nodered on boot. I'm using a raspberry 3 model B v2.
According to those instructions "https://nodered.org/docs/getting-started/raspberrypi" , I have install and create a flow.
I'm using
Node-RED version: v0.20.7
Node.js version: v8.16.0
When I start nodered using node-red-pi --max-old-space-size=256
it's working perfectly.
But now I want to use it as a service and launch it automatically.
Following the same instructions, I ran the command sudo systemctl enable nodered.service. The reboot, and nothing happened. Nodered didn't start.
I tried to run it directly as a service using node-red-start, and I got this error message
Starting as a systemd service.
Unit nodered.service entered failed state.
nodered.service holdoff time over, scheduling restart.
Stopping Node-RED graphical event wiring tool...
Starting Node-RED graphical event wiring tool...
Started Node-RED graphical event wiring tool.
/usr/bin/env: node-red-pi: No such file or directory
nodered.service: main process exited, code=exited, status=127/n/a
Unit nodered.service entered failed state.
nodered.service holdoff time over, scheduling restart.
Stopping Node-RED graphical event wiring tool...
Starting Node-RED graphical event wiring tool...
Started Node-RED graphical event wiring tool.
/usr/bin/env: node-red-pi: No such file or directory
nodered.service: main process exited, code=exited, status=127/n/a
Unit nodered.service entered failed state.
nodered.service holdoff time over, scheduling restart.
Stopping Node-RED graphical event wiring tool...
Starting Node-RED graphical event wiring tool...
Started Node-RED graphical event wiring tool.
/usr/bin/env: node-red-pi: No such file or directory
nodered.service: main process exited, code=exited, status=127/n/a
Unit nodered.service entered failed state.
nodered.service holdoff time over, scheduling restart.
Stopping Node-RED graphical event wiring tool...
Starting Node-RED graphical event wiring tool...
Started Node-RED graphical event wiring tool.
/usr/bin/env: node-red-pi: No such file or directory
nodered.service: main process exited, code=exited, status=127/n/a
Unit
nodered.service entered failed state.
nodered.service holdoff time over, scheduling restart.
Stopping Node-RED graphical event wiring tool...
Starting Node-RED graphical event wiring tool...
nodered.service start request repeated too quickly, refusing to start.
Failed to start Node-RED graphical event wiring tool.
Unit nodered.service entered failed state.
Has someone an idea about this error and how to fix it?
There is another way to start nodered automatically?
I advise you to use pm2 as a watchdog for nodeRed and to monitor its behavior.
(it's more than a watchdog, if you want to fiddle)
simply get pm2 from npm:
npm install pm2#latest -g
then run nodeRed using pm2:
pm2 start <PATH to nodered folder> --node-args="--max-old-space-size=128" -- -v
typically the path you are referring to is : /usr/bin/node-red
finally use:
pm2 save
to save the configuration and
pm2 startup
to create a startup script
to manage the process check the commands here:
PM2 quick start
I was facing the same problem a while ago. you can use nohup to start it automatically or not to end the session even you close the device.
Just install nohup, and type nohup node-red.
If you want to check status, write nohup status in the terminal.
for stoping, nohup stop node-red. Enjoy :)
Related
Opening macOS Console and looking at the System Log i ran into this error message that keeps repeating itself indefinitely:
com.apple.xpc.launchd[1] (com.macpaw.CleanMyMac4.HealthMonitor[21558]): Service exited with abnormal code: 78
com.apple.xpc.launchd[1] (com.macpaw.CleanMyMac4.HealthMonitor): Service only ran for 0 seconds. Pushing respawn out by 10 seconds.
com.apple.xpc.launchd[1] (com.macpaw.CleanMyMac4.HealthMonitor[21559]): Could not find and/or execute program specified by service: 149: Could not find a bundle of the given identifier through LaunchServices: com.macpaw.CleanMyMac4.HealthMonitor
I also tried to search inside
home/Library/LaunchAgents
but cannot find anything about CleanMyMacX.
A few days ago I deleted the "HealthMonitor" application because it was always running in background. I think that some service is trying to keep the application alive, but how can I stop it?
If you're not seeing it there, it's likely a launch daemon, not an agent. That means the binary is located in the /Library/PrivilegedHelperTools/ directory and its registration file is located in the /Library/LaunchDaemons/ directory.
Background
I have multiple (30+) custom services/timers which have the same structure (below in Contents section), but different timings. They have to be executed only when they are scheduled and cannot be run manually at random times. The application behind these jobs is often updated and during the update these jobs must be disabled/stopped and re-enabled/started-per-schedule after the update.
Question
I've created new systemd timer/service files and placed them under /etc/systemd/system/. How do I schedule this to start for first time based on OnCalendar without manually starting the timer or rebooting the server?
Contents
I have a service file:
# /etc/systemd/system/dummy.service
[Unit]
Description=dummy Service
Wants=dummy.timer
[Service]
Type=oneshot
User=root
ExecStart=/bin/ping -c 30 8.8.8.8
StandardOutput=journal
StandardError=journal
[Install]
WantedBy=multi-user.target
And a corresponding timer:
# /etc/systemd/system/dummy.timer
[Unit]
Description=dummy Timer
Requires=dummy.service
[Timer]
Unit=dummy.service
OnCalendar=*-*-* *:00:00
AccuracySec=1ms
RandomizedDelaySec=0
[Install]
WantedBy=timers.target
They are placed in /etc/systemd/system/ and then I run the following commands to enable the timer:
systemctl daemon-reload
systemctl enable dummy.timer
And if I run systemctl list-timers --all 'dummy*', the output is as per below, and the timer never executes..
NEXT LEFT LAST PASSED UNIT ACTIVATES
n/a n/a n/a n/a dummy.timer dummy.service
The only way I can make it start running on its schedule is either by rebooting the server (which is not an option) or by manually starting the timer with systemctl start dummy.timer, which is also not what I need.
I've been searching for solution for quite some time now and all I could find was either start manually or reboot. Having found anything SystemD man pages...
The workaround I have in place is using systemd-analyze calendar to read the next run time, date to convert it to %Y%m%d%H%M format and then schedule it with linux at command. This is far from elegant and has issues with jobs that run once a week or once a month, and the server is rebooted after application update and before scheduled run time.
Any ideas?
Thank you!
Ah, found the answer just after commenting.
The timer is implictly bound to the service of the same name. The Requires= line in the timer definition causes it to run the service. If you remove this line and then enable/start the timer it will only trigger on its schedule. Not at boot, and not when the start is performed, i.e.
systemctl enable --now dummy.timer
I have the following script:
whie true
do
#code
sleep 60
done
I then wanted to create a service to start the machine and launch this script as service:
created my.service at /etc/systemd/system/my.service
[Unit]
Description=my Script
[Service]
Type=forking
ExecStart=/bin/script.sh
[Install]
WantedBy=multi-user.target
problem occurs when i systemctl start my.service
it goes to while true loop and hang in there, how can i run this service and make it run in the background ?
According to systemd specification at link. Type=forking is not exactly correct kind of start-up in your case
If set to forking, it is expected that the process configured with
ExecStart= will call fork() as part of its start-up. The parent
process is expected to exit when start-up is complete and all
communication channels are set up. The child continues to run as the
main service process, and the service manager will consider the unit
started when the parent process exits. This is the behavior of
traditional UNIX services. If this setting is used, it is recommended
to also use the PIDFile= option, so that systemd can reliably identify
the main process of the service. systemd will proceed with starting
follow-up units as soon as the parent process exits.
The Type=simple can be correct one. You can try with it
If set to simple (the default if ExecStart= is specified but neither
Type= nor BusName= are), the service manager will consider the unit
started immediately after the main service process has been forked
off. It is expected that the process configured with ExecStart= is the
main process of the service. In this mode, if the process offers
functionality to other processes on the system, its communication
channels should be installed before the service is started up (e.g.
sockets set up by systemd, via socket activation), as the service
manager will immediately proceed starting follow-up units, right after
creating the main service process, and before executing the service's
binary. Note that this means systemctl start command lines for simple
services will report success even if the service's binary cannot be
invoked successfully (for example because the selected User= doesn't
exist, or the service binary is missing).
My golang web app cannot start when I use systemd, but it works fine when manually start. What are problems with my systemd configuration?
goweb.service
$ cat goweb.service
[Unit]
Description=Backend service
After=network.target
[Service]
User=myapp
Group=myapp
Restart=on-failure
ExecStart=/u01/backend
[Install]
WantedBy=multi-user.target
backend is a binary file compiled with command: env GOOS=linux GOARCH=amd64 go build -v bitbucket.org/myapp/backend
systemd service status
$ sudo service goweb status
Redirecting to /bin/systemctl status goweb.service
● goweb.service - Backend service
Loaded: loaded (/usr/lib/systemd/system/goweb.service; disabled; vendor preset: disabled)
Active: inactive (dead)
May 18 10:55:56 instance-1 systemd[1]: Started Backend service.
May 18 10:55:56 instance-1 systemd[1]: Starting Backend service...
P/S: It looks like my web app started, but then stoped immediately.
I try config Type=forking, then service status show as below. Could someone explains why the log Started Backend service. and Starting Backend service... order is reversed.
$ sudo service goweb status
Redirecting to /bin/systemctl status goweb.service
● goweb.service - Backend service
Loaded: loaded (/usr/lib/systemd/system/goweb.service; enabled; vendor preset: disabled)
Active: inactive (dead) since Wed 2016-05-18 11:06:02 UTC; 2s ago
Process: 25847 ExecStart=/u01/backend (code=exited, status=0/SUCCESS)
May 18 11:06:02 instance-1 systemd[1]: Starting Backend service...
May 18 11:06:02 instance-1 systemd[1]: Started Backend service.
Result when I run web app manually (from terminal):
$ /u01/backend
[GIN-debug] [WARNING] Running in "debug" mode. Switch to "release" mode in production.
- using env: export GIN_MODE=release
- using code: gin.SetMode(gin.ReleaseMode)
[GIN-debug] POST /upload --> main.uploadFileHandler (3 handlers)
[GIN-debug] Environment variable PORT="9005"
[GIN-debug] Listening and serving HTTP on :9005
Update:
I try supervisord and it works fine (same binary file)
With systemd, I changed service config to Restart=always, RestartSec=15. And systemd keeps restarting my web app.
Does anyone know why supervisord work fine but systemd not? I think that systemd would work fine with a basic task like that!
I know this is old, but saw that there weren't any sufficient answers, so thought I would post. My app was also being run manually, but when using systemd it wouldn't work. I realized it had to do with the filepaths that the Go program would state, such as:
tpl = template.Must(template.ParseGlob("templates/*"))
When running the app manually, the templates folder was there relative to my main.go file, but when systemd would run it, the filepath was different (not sure why or how to solve this yet), but for now I just hardcoded an absolute filepath, such as:
tpl = template.Must(template.ParseGlob("./home/ubuntu/templates/*"))
Now systemd works.
Hope this helps. If anyone can elaborate on how to come up with a better solution, would totally help me as well!
I'll take a wild stab and guess your app listens on port 80 and/or 443, so your best bet is to use setcap on it to give it permission.
example: sudo setcap 'cap_net_bind_service=+ep' /u01/backend, this will need to be done every time you compile your app.
From #RijulSudhir comment above, insert:
WorkingDirectory=/home/ubuntu/
below:
[service]
of systemd service file.
Replace your app temporarily with a minimal version that just dumps the environment out. Are the environment for running manually and under systemd sufficiently similar?
In this specific instance, I guess it's because you don't specify
ExecStart=/path/to/app
As a result, there's nothing to start.
I've made a (docker) container for ddclient.
The problem is that I'm having problems in running that service in the foreground so that the docker container keeps running.
I've managed to keep the docker running by adding a bashat the end of the script but this is hackish, since the actual process it should be whatching is the ddclient.
Another way I found was to tail -f the log file, but if the service stops, the container will keep running instead of stoping.
Q: So is there any (easy) way to keep a service running in the foreground?
The problem with the process (any process) running in a container is signal management: you need to make sure the SIGKILL and other signals are properly communicated to the right process(es) in order to successfully stop/remove a container (and not leave zombie processes: see "PID 1 zombie reaping issue")
One option is at least to make your service at least write in a log file
ENTRYPOINT ["/bin/sh" "-c" ]
CMD yourProcess > log
That should keep it in foreground, as suggested in "How do I bring a daemon process to foreground?".
For a service, try and use as a base image phusion/baseimage-docker which manages other services properly.