4 ms·

I'd argue that one of the biggest things that made sysvinit so ugly was that distro maintainers didn't enforce any type of startup script hygiene. Take a look a

I'd argue that one of the biggest things that made sysvinit so ugly was that distro maintainers didn't enforce any type of startup script hygiene. Take a look at BSD-style init scripts some time. They're beautiful in their simplicity and readability. They source a common set of functions, have well-defined variables to control execution, and end up with a length about that of systemd units, without sacrificing the power of shell scripting. Systemd threw the baby out with the bathwater, and just makes diagnosing boot problems all that more difficult when you have to start tracing through magic symlinks.

alwaysdownvoted 10y ago
You nailed it. I rarely make use of the BSD scripts provided but I like them as simple examples of how various services are intended to be run. I find there is a certain amount of uniformity and consistency and arguably coherence to the rc.d system.
INTPenis 10y ago
I actually came from FreeBSD to Debian 8 years ago and the funny thing is that I don't remember editing rc scripts anywhere near as often as I edited sysvinit scripts on Debian. But that could easily be explained by the average complexity of services increasing along with my career path into Linux and Devops. I don't remember any clear differences between sysvinit and rc, the scripting is still left up to the user which means code style can diverge from whatever the maintainers had in mind. Systemd, albeit a binary blob, at least eliminates that from the equation and breaks down services into a limited number of types that it handles equally every time. I actually liked upstart too. :) I might sound mad for saying that but as a user of Linux upstart gave me just what I wanted. Bottom line is that I think discussions about scripting style have no place in the context of service management. Services should be dealt with in a simple way like upstart or systemd. If you want to add more complexity you can write a start script for the service but that should not be the norm.
- woodman 10y ago
  > scripting is still left up to This is commonly provided by the port maintainer - I haven't conducted a survey but I'm pretty confident that service scripts in FreeBSD ports rarely make it into rc.d without a deliberate freebsdization.
  - JdeBP 10y ago
    I have read all of the rc scripts that come with base FreeBSD and PC-BSD, and some of the NetBSD ones too. Coding style with Mewburn rc is nowhere near as divergent as it is with van Smoorenburg rc.
  - INTPenis 10y ago
    Yes I think Ports played a big role in keeping me out of rc scripts on FreeBSD. Ports just had everything you needed. But again, packages could play the same role on Linux but the reason they don't always do that is because of custom services, in-house developed, or proprietary purchased.
- JdeBP 10y ago
  > I don't remember any clear differences between sysvinit and rc van Smoorenburg rc and Mewburn rc are noticably different. * https://news.ycombinator.com/item?id=11550802 https://news.ycombinator.com/item?id=11550802 They are both rc, by the way. Don't conflate init and rc. > If you want to add more complexity you can write a start script for the service but that should not be the norm. In some fields, it appears that it is. * http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/systemd-house-of-horror/ http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/sy...
  - INTPenis 10y ago
    Java is notorious, even with systemd. The biggest problem with java is knowing when the service is started. And that's actually a problem with other clustered services like wsrep in mariadb for example. You need to get an OK from the service, by checking logs or APIs, before you know that the restart worked. So services like that will always require an added layer of abstraction. But that's not the norm, far from it.
    - JdeBP 10y ago
      On the contrary, and as I already said, in some fields it appears that it is. Moreover, as demonstrated, those services do not require all of that extra layering. Indeed, it actively breaks functionality. Ironically, MariaDB is not one of those fields, and your chosen example is actually a counterexample. The push in MariaDB is to use systemd's "notify" readiness notification protocol and actually get rid of the wrapper shell scripts completely. * http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/unix-daemon-readiness-protocol-problems.html http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/un... * https://mariadb.atlassian.net/browse/MDEV-5713 https://mariadb.atlassian.net/browse/MDEV-5713 * https://github.com/MariaDB/server/pull/26 https://github.com/MariaDB/server/pull/26 * https://github.com/MariaDB/server/pull/83 https://github.com/MariaDB/server/pull/83 * https://github.com/MariaDB/server/commit/20c2ae39db3dd0ec4c337a9b0bd2bf4481b61e49 https://github.com/MariaDB/server/commit/20c2ae39db3dd0ec4c3... As in MySQL and PostgreSQL. * http://bugs.mysql.com/bug.php?id=65809 http://bugs.mysql.com/bug.php?id=65809 * http://www.postgresql.org/message-id/E1aQnE5-0003Cj-CN@gemulon.postgresql.org http://www.postgresql.org/message-id/E1aQnE5-0003Cj-CN@gemul... * http://postgresql.nabble.com/PATCH-better-systemd-integration-td5874210.html http://postgresql.nabble.com/PATCH-better-systemd-integratio...
Freaky 10y ago
The Design and Implementation of the NetBSD rc.d system - http://www.mewburn.net/luke/talks/auug-2003/ http://www.mewburn.net/luke/talks/auug-2003/
vidarh 10y ago
Why in the world would you need to "start tracing through magic symlinks" with Systemd? If you mean to figure out what was actually executed for a unit "systemctl cat [service name]" will tell you the full path of each file systemd processed for that service and what content was pulled from it.
- Sanddancer 10y ago
  Because I had a situation where systemd broke a symlink causing a unit to be permanently disabled. Thus, I needed to look through the filesystem to find the offending mislinked magic and deleted unit files and repair them.

alwaysdownvoted 10y ago

You nailed it. I rarely make use of the BSD scripts provided but I like them as simple examples of how various services are intended to be run. I find there is a certain amount of uniformity and consistency and arguably coherence to the rc.d system.

INTPenis 10y ago

I actually came from FreeBSD to Debian 8 years ago and the funny thing is that I don't remember editing rc scripts anywhere near as often as I edited sysvinit scripts on Debian. But that could easily be explained by the average complexity of services increasing along with my career path into Linux and Devops. I don't remember any clear differences between sysvinit and rc, the scripting is still left up to the user which means code style can diverge from whatever the maintainers had in mind. Systemd, albeit a binary blob, at least eliminates that from the equation and breaks down services into a limited number of types that it handles equally every time. I actually liked upstart too. :) I might sound mad for saying that but as a user of Linux upstart gave me just what I wanted. Bottom line is that I think discussions about scripting style have no place in the context of service management. Services should be dealt with in a simple way like upstart or systemd. If you want to add more complexity you can write a start script for the service but that should not be the norm.

woodman 10y ago
> scripting is still left up to This is commonly provided by the port maintainer - I haven't conducted a survey but I'm pretty confident that service scripts in FreeBSD ports rarely make it into rc.d without a deliberate freebsdization.
- JdeBP 10y ago
  I have read all of the rc scripts that come with base FreeBSD and PC-BSD, and some of the NetBSD ones too. Coding style with Mewburn rc is nowhere near as divergent as it is with van Smoorenburg rc.
- INTPenis 10y ago
  Yes I think Ports played a big role in keeping me out of rc scripts on FreeBSD. Ports just had everything you needed. But again, packages could play the same role on Linux but the reason they don't always do that is because of custom services, in-house developed, or proprietary purchased.
JdeBP 10y ago
> I don't remember any clear differences between sysvinit and rc van Smoorenburg rc and Mewburn rc are noticably different. * https://news.ycombinator.com/item?id=11550802 https://news.ycombinator.com/item?id=11550802 They are both rc, by the way. Don't conflate init and rc. > If you want to add more complexity you can write a start script for the service but that should not be the norm. In some fields, it appears that it is. * http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/systemd-house-of-horror/ http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/sy...
- INTPenis 10y ago
  Java is notorious, even with systemd. The biggest problem with java is knowing when the service is started. And that's actually a problem with other clustered services like wsrep in mariadb for example. You need to get an OK from the service, by checking logs or APIs, before you know that the restart worked. So services like that will always require an added layer of abstraction. But that's not the norm, far from it.
  - JdeBP 10y ago
    On the contrary, and as I already said, in some fields it appears that it is. Moreover, as demonstrated, those services do not require all of that extra layering. Indeed, it actively breaks functionality. Ironically, MariaDB is not one of those fields, and your chosen example is actually a counterexample. The push in MariaDB is to use systemd's "notify" readiness notification protocol and actually get rid of the wrapper shell scripts completely. * http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/unix-daemon-readiness-protocol-problems.html http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/un... * https://mariadb.atlassian.net/browse/MDEV-5713 https://mariadb.atlassian.net/browse/MDEV-5713 * https://github.com/MariaDB/server/pull/26 https://github.com/MariaDB/server/pull/26 * https://github.com/MariaDB/server/pull/83 https://github.com/MariaDB/server/pull/83 * https://github.com/MariaDB/server/commit/20c2ae39db3dd0ec4c337a9b0bd2bf4481b61e49 https://github.com/MariaDB/server/commit/20c2ae39db3dd0ec4c3... As in MySQL and PostgreSQL. * http://bugs.mysql.com/bug.php?id=65809 http://bugs.mysql.com/bug.php?id=65809 * http://www.postgresql.org/message-id/E1aQnE5-0003Cj-CN@gemulon.postgresql.org http://www.postgresql.org/message-id/E1aQnE5-0003Cj-CN@gemul... * http://postgresql.nabble.com/PATCH-better-systemd-integration-td5874210.html http://postgresql.nabble.com/PATCH-better-systemd-integratio...

Freaky 10y ago

The Design and Implementation of the NetBSD rc.d system - http://www.mewburn.net/luke/talks/auug-2003/ http://www.mewburn.net/luke/talks/auug-2003/

vidarh 10y ago

Why in the world would you need to "start tracing through magic symlinks" with Systemd? If you mean to figure out what was actually executed for a unit "systemctl cat [service name]" will tell you the full path of each file systemd processed for that service and what content was pulled from it.

Sanddancer 10y ago
Because I had a situation where systemd broke a symlink causing a unit to be permanently disabled. Thus, I needed to look through the filesystem to find the offending mislinked magic and deleted unit files and repair them.