I have my executable file in service folder /var/www/project/service/project.exe.
Currently I'm running on runlevel 2. I used this link to change my default runlevel to 5.
Since this will be deployed on the cloud ,I want that it should start the service(project.exe) in runlevel 5 automatically, rather than manually.
How this can be achieved?
You could create an Upstart job. Write /etc/init/project.conf file:
start on runlevel 5
exec /var/www/project/service/project.exe
You probably want to specify other options such as description, stop on, respawn, setuid.
Related
I need running a (bash)Script after each start from my EC2.
The machine stops 90% a day - after wake up - a script should run.
I tried to push it in the USER-DATA - but this only runs on init.
After this I followed up here: https://aws.amazon.com/de/premiumsupport/knowledge-center/execute-user-data-ec2/
but this didn't also work - because to stop a machine and start a machine seems to be no reboot
I also implement a simple output in the rc.local but also: nothing happens.
Is there a way?
So we talk to switch from this Instance-State
to this:
You could use the oneshot feature of systemd
Write scripts for mystart.sh and mystop.sh, chmod/chown them
/etc/systemd/system/mystart.service. Note that we must specify RemainAfterExit=true so that systemd considers the service as active after the setup action is successfully finished.
[Unit]
Description=mystart
After=network.target
[Service]
Type=oneshot
ExecStart=/usr/local/bin/mystart.sh
RemainAfterExit=true
ExecStop=/usr/local/bin/mystop.sh
StandardOutput=journal
[Install]
WantedBy=multi-user.target
Reload the systemd (systemctl reload) and try stopping and starting to test it
Cloud-Init (which runs the User Data script on first boot) can also run scripts:
On every boot
On the next boot only
So, simply install your script in this directory:
/var/lib/cloud/scripts/per-boot/
Each time the instance is booted (started), the script will run. This is a great way to trigger a batch process on the instance.
See also: Auto-Stop EC2 instances when they finish a task - DEV Community
We have an embedded target environment (separate from out host build environment) in which systemd is running but not cron.
We also have a script which, under most systems, I would simply create a cron entry to run it every five minutes.
Now I know how to create a service under systemd but this script is a one-shot that exits after it's done its work. What I'd like to do is have it run immediately on boot (after the syslog.target, of course) then every five minutes thereafter.
After reading up on systemd timers, I created the following service file is /lib/systemd/system/xyzzy.service:
[Unit]
Description=XYZZY
After=syslog.target
[Service]
Type=simple
ExecStart=/usr/bin/xyzzy.dash
and equivalent /lib/systemd/system/xyzzy.timer:
[Unit]
Description=XYZZY scheduler
[Timer]
OnBootSec=0min
OnUnitActiveSec=5min
[Install]
WantedBy=multi-user.target
Unfortunately, when booting the target, the timer does not appear to start since the output of systemctl list-timers --all does not include it. Starting the timer unit manually seems to work okay but this is something that should be run automatically with user intervention.
I would have thought the WantedBy would ensure the timer unit was installed and running and would therefore start the service periodically. However, I've noticed that the multi-user.target.wants directory does not actually have a symbolic link for the timer.
How is this done in systemd?
The timer is not active until you actually enable it:
systemctl enable xyzzy.timer
If you want to see how it works before rebooting, you can also start it:
systemctl start xyzzy.timer
In terms of doing that for a separate target environment where you aren't necessarily able to easily run arbitrary commands at boot time (but do presumably control the file system content), you can simply create the same symbolic links (in your development area) that the enable command would do.
For example (assuming SYSROOT identifies the root directory of the target file system):
ln -s ${SYSROOT}/lib/systemd/system/xyzzy.timer
${SYSROOT}/lib/systemd/system/multi-user.target.wants/xyzzy.timer
This will effectively put the timer unit into an enabled state for the multi-user.target, so systemd will start it with that target.
Also, normally your custom files would be stored in /etc/systemd/system/. The equivalent lib directory is intended to host systemd files installed by packages or the OS.
If it's important that your cron job run precisely every 5 minutes, you should check the accuracy because systemd's monotonic timers can slip over time
In my usecase, I am trying to write an upstart script for grafana service. Here is my content,
#grafana upstart script
description "start and stop grafana server"
start on (net-device-up
and local-filesystems
and runlevel [2345])
stop on runlevel [016]
respawn
respawn limit 5 30
console output
exec service grafana-server stop
But this is not woking all the time. Do I need remove any pid after stopping the service?
Also is this the right way to create upstart conf with service. Because I tried to do the same for nginx service. But it fails because we need to remove the pid after stopping the service.
So in general how can we write upstart script for services?
I am using amazon linux [ec2]. Could someone help me with this?
You can just look at any script in the folder /etc/init.d and change the instructions according your your needs. The you can use the systemctl (or the appropiate command for your distribution) to make it run on the desired init levels
My python source file automatically starts while I boot the system. I tried in init.d and some other shell scripts, but its not working. Note (I also make the executable file), but it doesn't work.
Please help.
There are a number of other posts covering this topic, notably here
Put this in /etc/init (Use /etc/systemd in Ubuntu 15.x)
mystartupscript.conf
start on runlevel [2345] stop on runlevel [!2345] exec /path/to/script.py
By placing this conf file there you hook into ubuntu's upstart service that runs services on startup.
manual starting/stopping is done withsudo service mystartupscript start and sudo service mystartupscript stop
There is another solution here also also
So by default I am in runlevel 3. During shutdown I switch into runlevel 0. But I am not getting any success if am putting my script (having a curl call) in /etc/rc0.d/, as in runlevel 0 network is already stopped and therefore it is not able to do the curl call.
How to get the desired result ?
Generally in the older SysVinit systems, boot sequence and shutdown sequence were controlled by the alpha-numeric order of symbolic links to your init-script located in each runlevel directory under /etc/init.d (or /etc/rc.d/) where the links numbered S## (start) were run during boot and K## (kill/stop) scripts were run during shutdown. The services available at any given point in time are controlled by what is running during the boot or shutdown sequence. For example an older SuSE scheme would be:
/etc/init.d/
boot.d/
rc0.d/ # runlevel 0
rc1.d/ # runlevel 1
rc2.d/ # runlevel 2
rc3.d/ # runlevel 3
...
S01random # S## - Start init script ## in order 00 -> XX
S01resmgr
S02consolekit
S03haldaemon
S05network # network start
...
K01stopblktrace # KXX - Kill (stop) init script ## in order
K02atieventsd
K09cron
...
K14sshd
K15smbfs
K16apcupsd
K16auditd
K16nmb
K16portmap
K16splash_early
K17syslog
K18network # network shutdown
...
rc4.d/
rc5.d/
rc6.d/
rcS.d/
If you look at the boot/shutdown sequence for runlevel-3 in /etc/init.d/rc3.d/ you see that the network start and shutdown are controlled by S05network on boot and K18network on shutdown. So if you wanted to create a custom script to run curl on shutdown prior to the network shutting down, you would need to create an init script and create a soft-link in /etc/init.d/rc3.d and have it numbered prior to the network services (ssh, etc.) being taken down. Above if you created and numbered the soft-link to your kill script K10curlonsd (curl on shutdown), it would run after cron shutdown, but before any of the network services were taken down.
The scheme should still be the same on centos, although your /etc/init.d may be /etc/rc.d, etc., but the general approach will be the same. Let me know if you have any questions.