1

I have one CentOS based Amazon Linux AMI and I was trying to setup custom service, in which a small bash script (which creates a dummy file in a particular location) will be called on boot.

I followed this tutorial https://unix.stackexchange.com/a/20361 and created a custom service script myscript like below, and copied it into /etc/init.d folder with 777 permission and root as the owner;

#!/bin/bash
# chkconfig: 2345 20 80
# description: Description comes here....

Source function library.

. /etc/init.d/functions

start() { echo -n "Starting myscript... " su user touch /data/startfile return 0 }

stop() { echo -n "Stopping myscript... " su user touch /data/stopfile return 0 }

case "$1" in start) start ;; stop) stop ;; restart) stop start ;; status) ;; *) echo "Usage: $0 {start|stop|status|restart}" esac

exit 0

After rebooting the machine, when I checked /data/ directory, I can see two files startfile as well as stopfile. If the service is starting automatically, startfile is expectable, but I wonder about stopfile. Can somebody please explain why this is happening?

Thanks

Jeff Schaller
  • 67,283
  • 35
  • 116
  • 255
Alfred
  • 143
  • 2
    The Stackexchange thread that you followed to create the service is nine years old. Centos 7 adopted systemd in 2015, and Centos 6 is obsolete now. You should not use init scripts but learn how to create a systemd service (very simple example: https://www.suse.com/support/kb/doc/?id=000019672). Apart from that, I agree that you should check the timestamps of the two files. – berndbausch Jan 25 '21 at 11:51

1 Answers1

1

Your initscript would have been called when you asked the system to reboot: that’s probably when the stopfile was created.

The startfile would have been created as expected during system boot.

Checking the timestamps on the files should allow you to confirm this: stopfile should be timestamped between the time you asked for the reboot and the time the system actually rebooted, and startfile should be timestamps after the system started booting again.

Stephen Kitt
  • 434,908