Difference Between Starting a Command Using Init.D Script and Service Start

ubuntu 14.04 /etc/init.d/ vs /etc/init/ start service at startup

The scripts in /etc/init.d/ are scripts that control services. Controlling means that they take care of starting, stopping and similar actions.

They are not automatically executed at startup. Instead, you must assign scripts to runlevels, which is done with the update-rc.d command on Debian-based systems (which Ubuntu is).

For example, to add your supervisor service to all default runlevels, you would execute

sudo update-rc.d supervisor defaults

Also, you're asking for the difference between /etc/init.d and /etc/init:

• /etc/init.d contains the service scripts,
• /etc/init contains configuration for these scripts (descriptions. dependencies, post-/pre-actions). However IIRC, /etc/init is specific to SysV init.

init program in shell script

When a Unix OS is starting up it will run all the scripts in /etc/init.d, among them this one, with the "start" argument. The script then invokes /usr/sbin/sshd which forks a background process and terminates. The background process will again fork and its child will become a demon process. The demon process writes its PID into /var/run/sshd.pid and begins servicing. Upon shutdown of the OS, this script will again be called with the "stop" argument. It will gather the demon's PID from the file and terminate it gracefully (without switch kill sends SIGTERM as if 'kill -15 $pid').

Difference between Systemctl and service command

service operates on the files in /etc/init.d and was used in conjunction with the old init system. systemctl operates on the files in /lib/systemd. If there is a file for your service in /lib/systemd it will use that first and if not it will fall back to the file in /etc/init.d.
Also If you are using OS like ubuntu-14.04 only service command will be available.

So if systemctl is available ,it will be better to use it

Systemd + Sys V init.d script: start works, but stop does not

You'll notice the top of your script loads /lib/lsb/init-functions. You can read the code in there and the related code in /lib/lsb/init-functions.d to understand the related code you are pulling in.

A summary is that your script likely being converted to a systemd .service in the background and is subject to a whole host of documented incompatibilities with systemd

There is inherit extra complexity and potential problems when you ask systemd to emulate and support the file formats used by the legacy Upstart and sysVinit init systems.

Since you are writing new init script from scratch, consider writing a systemd .service file directly, removing all the additional complexity of involving additional init systems.

A minimal .service file to go in /etc/systemd/system/ could look like:

[Unit]
Description=Foo

[Service]
ExecStart=/usr/sbin/foo-daemon

[Install]
WantedBy=multi-user.target

More details in man systemd.service. Some additional learning now will save you some debugging later!

How to run a command as a specific user in an init script?

On RHEL systems, the /etc/rc.d/init.d/functions script is intended to provide similar to what you want. If you source that at the top of your init script, all of it's functions become available.

The specific function provided to help with this is daemon. If you are intending to use it to start a daemon-like program, a simple usage would be:

daemon --user=username command

If that is too heavy-handed for what you need, there is runuser (see man runuser for full info; some versions may need -u prior to the username):

/sbin/runuser username -s /bin/bash -c "command(s) to run as user username"

chef won't start my init.d service

This has to do with the assumption on what the script support as command.

Quoting chef doc about service resource about the supports property (emphasis on last line is mine):

supports Ruby Type: Hash

A list of properties that controls how the chef-client is to attempt
to manage a service: :restart, :reload, :status. For :restart, the
init script or other service provider can use a restart command; if
:restart is not specified, the chef-client attempts to stop and then
start a service. For :reload, the init script or other service
provider can use a reload command. For :status, the init script or
other service provider can use a status command to determine if the
service is running; if :status is not specified, the chef-client
attempts to match the service_name against the process table as a
regular expression, unless a pattern is specified as a parameter
property. Default value: { :restart => false, :reload => false,
:status => false } for all platforms (except for the Red Hat platform
family, which defaults to { :restart => false, :reload => false,
:status => true }.)

when status is true, the provider try to call it, if it returns 0 the service is supposed to be running.

According to the link you gave, the script only support start and hence return 0 when called with parameter status.

One way to fix this is using a more precise definition of the service like this:

service 'disable-transparent-hugepages' do
  supports :restart => false, :start => true, :stop => false, :reload => false, :status => false
  action :start
end

Another way would be to fix the init script to implement the status command, returning 0 if the file have the proper content and 1 if not.

Something along this line as status case would do I think (untested):

status)
if [ -d /sys/kernel/mm/transparent_hugepage ]; then
  thp_path=/sys/kernel/mm/transparent_hugepage
elif [ -d /sys/kernel/mm/redhat_transparent_hugepage ]; then
  thp_path=/sys/kernel/mm/redhat_transparent_hugepage
else
  return 0
fi

re='^(0|no)$'
return [[ $(cat ${thp_path}/khugepaged/defrag) =~ $re ]]
;;

My opinion:

As it is not exactly a real service, I would go to manage those files directly instead of using a pseudo service for this.

Unix script on startup in /etc/init.d not working

When bash scripts are run, they are not automatically ran from the same directory that contains them.

You will either need to update your scripts to change directory to that which holds the scripts before starting the jar:

#!/bin/bash
cd /var/lib/myapp/
java -jar myapp-1.0.0RC.jar &

Or, refer to the jar file with a full path:

#!/bin/bash
java -jar /var/lib/myapp/myapp-1.0.0RC.jar &

How can I modify init script to make it start after delay or event?

I found out a solution (event vagrant-mounted):

cat << EOF > /etc/init/supervisor-launcher.conf
description "Supervisor Launcher"
start on vagrant-mounted
script
  /usr/sbin/service supervisor start
end script
EOF

---

Related Topics