Creating startup scripts for server applications

[Huecuva]

So I read a Teamspeak server tutorial (http://debian-tutorials.blogspot.ca/201 ... ebian.html) that located the startup script in a folder called /etc/init.d/. Right now, I'm following a vnc server tutorial (https://www.digitalocean.com/community/ ... n-debian-8) that says to create the script at /usr/local/bin/ instead. What is the difference between these locations? Obviously locating startup scripts at either location works....unless the scripts for each of those applications needs to be located in those particular places? If not, is one preferred over the other? Does it matter? I like to try to keep things tidy and put all custom startup scripts in the same location if that's possible. It makes them easier to back up that way.

Can anyone shed some light on this mystery?

Thanks.

[orythem27]

So I read a Teamspeak server tutorial (http://debian-tutorials.blogspot.ca/201 ... ebian.html) that located the startup script in a folder called /etc/init.d/

This tutorial is from the sysvinit era which is too old.

Right now, I'm following a vnc server tutorial (https://www.digitalocean.com/community/ ... n-debian-8) that says to create the script at /usr/local/bin/ instead.

Do not conclude too soon, read the whole article.
(Hint: Create the script at /usr/local/bin/, then what?)

[Huecuva]

This tutorial is from the sysvinit era which is too old.

Well, I followed it when I set up my TeamSpeak server. It works.

Do not conclude too soon, read the whole article.
(Hint: Create the script at /usr/local/bin/, then what?)

And then...make it executable? Both tutorials go over that. It doesn't matter where the script is located, you still need to chmod +x it. It appears as though executable scripts located in either /etc/init.d or /usr/local/bin will execute on boot, Maybe the script has to be located at /usr/local/bin in order for a service to be created for it? Maybe that tutorial is too specific to that DigitalOcean virtual server hosting service and I shouldn't be following it at all? I don't know, man. This is why I'm asking.

If the /etc/init.d thing is considered old, can my teamspeak script simply be moved to /usr/local/bin (or wherever other boot script location if any) and still work properly?

[steve_v]

If the /etc/init.d thing is considered old, can my teamspeak script simply be moved to /usr/local/bin (or wherever other boot script location if any) and still work properly?

I haven't looked into the state of sysv init script backwards-compatibility in stretch (are sysv scrips are still supported?), but from jessie on the 'native' systemd way to do it is with a unit file.
That DigitalOcean article describes a systemd unit file launching a script in /usr/local/bin, which is fine, if a little messy. Looks like everything is there to me.
If you want to put the script somewhere else, change the unit file accordingly.

[Huecuva]

So it's the service that's executing the script and it doesn't matter where the script is as long as the service is properly pointed at it. That makes more sense now. If a script is located in /etc/init.d then it just executes automatically anyway? I'm using Jessie, by the way, and that script at /etc/init.d works perfectly. I guess if I were to move the script I would need to make a systemd file similar to the one for vnc to run the TS3 server? Maybe the first line would have to be changed from #!/bin/sh to #!/bin/bash instead?

If that systemd file is messy, how would you go about doing that instead? What is a unit file?

EDIT:

I found this tutorial here which seems to be for creating these unit files you speak of: https://linuxconfig.org/how-to-automati ... temd-linux. Maybe I should do it this way instead? I'm beginning to think I should rewrite my ts3 script as well. It seems like the sysv init script method is actually simpler. Why was it changed?

Everything else I found in my 5 minutes of googling was at least a year old. One thread was over 7 years old. Not very useful.

[steve_v]

If a script is located in /etc/init.d then it just executes automatically anyway?

If it has the corresponding symlinks in /etc/rc[x].d according to sysv spec.

I'm using Jessie, by the way, and that script at /etc/init.d works perfectly.

Jessie supports sysv style scripts.

I guess if I were to move the script I would need to make a systemd file similar to the one for vnc to run the TS3 server?

I guess so. Or just use sysv style scrips if you already have them.

Maybe the first line would have to be changed from #!/bin/sh to #!/bin/bash instead?

Only if it specifically needs bash.

If that systemd file is messy, how would you go about doing that instead?

Eliminate the external startup script, if possible.

What is a unit file?

Systemds equivalent of shell scripts and symlinks in sysv.

It seems like the sysv init script method is actually simpler.

It is. I also happen to like bash.

Why was it changed?

Don't ask. Apparently there were "reasons".
Personally I think it was a pretty rubbish idea putting so much "not-inits-job" functionality in PID1, but my stuff is still working, and systemd hasn't actually taken down the system yet, so ¯\_(ツ)_/¯.

[Huecuva]

The TS3 server tutorial I followed never mentioned anything about the /etc/rc[x].d folder. Maybe that was done automatically or something.

So there's a way to launch the application directly from the systemd file without needing a separate startup script? Would that be possible in the example on that digitalocean article with all the parameters in that startup script? If not, I can just make the script and use the systemd file to launch it. It's not that big a deal, I just like to keep things as tidy as possible, as I mentioned.

EDIT: After examining both of those unit file related scripts a little more closely, I have discerned that the one on LinuxConfig.org is in fact calling the application executable direction from the systemd file. If I were include options after that line, would it then launch the application with those options? ie:

Code: Select all

ExecStart=/usr/bin/vncserver -localhost

. Would that work? If that syntax is correct, then I'm pretty sure I can make the unit file just start the VNC server at boot without all those other options. I've connected to the server over my LAN from my phone and it all seemed to work fine without those color depth and geometry parameters, so I'm not sure how necessary they really are. As for the ability to start, stop and restart the service...how useful is that? Is there some benefit to being able to do that with a VNC server? I can see it being convenient if you ever do need it, but would you ever actually need it?