Alpine Linux /etc/init.d daemon script

[nicedevil007]

Hey guys, I recently installed blockly under Alpine Linux to have the smallest LXC container possible for using this tool. Unfortunately the package didn't come with an /etc/init.d script that I can enable to run it as a daemon after a reboot or with the service command.

Because I'm realy not used to write those scripts by myself, is there anyone that can help out? There is no systemd available on alpine linux.

Maybe as a starter that just leads to "blocky crashed":

#!/sbin/openrc-run
pidfile="/run/$RC_SVCNAME.pid"

command="/usr/bin/blocky"
command_args="--config /root/config.yml"
command_background="yes"

start_stop_daemon_args="--quiet"
retry="SIGTERM/20"

depend() {
        use net
}

[kwitsch]

I'm really not familiar with lxc, but the the first things I would check are:

• is the binary executable on the executing user?
• has the executing user read privilege on the config file?
• is there a need to set cap 'cap_net_bind_service=+ep'?
• create a designated blocky user and add "command_user" to your init script

[nicedevil007]

I'm really not familiar with lxc, but the the first things I would check are:

• is the binary executable on the executing user?
• has the executing user read privilege on the config file?
• is there a need to set cap 'cap_net_bind_service=+ep'?
• create a designated blocky user and add "command_user" to your init script

for starting with blocky I just used the root user. Making it more complicated is part 2 of my session with it :)
So yes root is able to run the script (it is the user that can run it manually and is the same for the initscript)

will try to find out if there is anything to your suggestion of cap_net_bind_service=+ep

[ThinkChaos]

I think you need a start function, and a couple others.
Found this guide which seems good.

[nicedevil007]

I tried a new version now... The issue is that blocky always sends everything to the console output so it is not running in the background.

#!/bin/sh
### BEGIN INIT INFO
# Provides:          blocky
# Required-Start:    $remote_fs $network
# Required-Stop:     $remote_fs $network
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: Start script for Blocky
### END INIT INFO

# Benutzer, unter dem Blocky ausgeführt werden soll
#USER="blockyservice"
USER="root"

# Blocky-Startbefehl
START_COMMAND="/usr/bin/blocky --config /root/config.yml"

# Funktion zum Starten von Blocky
start_blocky() {
    su -c "${START_COMMAND}" -s /bin/sh $USER
}

# Funktion zum Stoppen von Blocky
stop_blocky() {
    pkill -f "${START_COMMAND}"
}

case "$1" in
    start)
        start_blocky
        ;;
    stop)
        stop_blocky
        ;;
    restart)
        stop_blocky
        sleep 1
        start_blocky
        ;;
    *)
        echo "Verwendung: $0 {start|stop|restart}"
        exit 1
        ;;
esac

exit 0

[ThinkChaos]

Not sure what's the best practice for these scripts, but I think using another tool to daemonize blocky would work.
Something like nohup blocky &.

[kwitsch]

Isn't the purpose of a container to run precisely one application? O.o
Wouldn't be the correct way to keep blocky in the foreground but run the container detached?

Sorry if I confuse something I'll only use Docker and trying to get my head around lxc. 😅

[ThinkChaos]

Yeah most containers just run a single binary as the entrypoint, which would be a solution here too I think, but some people like to have integration with an init system, and even run multiple processes that integrate as a single "app" (think db + app).
There's also a technical reason for having an init system: PID1 has responsibilities that most apps, blocky included, don't and shouldn't implement. See this blog post for details.

[kwitsch]

My question was more like: is implementing an init system in this scenario necessary(especially if the goal is to be as small as possible)?

There's also a technical reason for having an init system: PID1 has responsibilities that most apps, blocky included, don't and shouldn't implement. See this blog post for details.

Not completely true. If blocky is compiled with the "static" tag(as it is done for Docker container binaries) blocky implements a process reaper.

[ThinkChaos]

Ah sorry misunderstood. And you're right, I just completely forgot about the reaper.