5 ms·

… you’re mourning SysV init scripts? why?

by op00to 3y ago

BirAdam 3y ago
Because it will one day be “invented” again as a “scriptable init”
cellularmitosis 3y ago
I mourn it. I've been typing '/etc/init.d/apache2 restart' for about twenty years now. Why change it? Would it really be that hard to have a symlink from /etc/init.d/apache2 to /bin/systemctl and teach systemctl to do the right thing?
- viraptor 3y ago
  There's a generic wrapper which existed for many years "service apache2 restart" will work regardless of the init type. You can also put "systemctl $1 apache2" in /etc/init.d/apache2 and keep using it. It's really not a big issue.
- kaba0 3y ago
  Be the change you want to see.
yjftsjthsd-h 3y ago
If nothing else, sysv scripts were conceptually really simple to the point that you look at it and think "oh, it's just a shell script; I could actually just sit down and reimplement the whole system in a weekend". In fact, much of my personal dislike of systemd is that it started getting popular right as I was having that revelation and got to watch a pile of shell scripts that I could just pop open in my editor get replaced with an all-encompassing black box (yes, I know it's open source, but "you could go find the source and try to read C" is not the same as "vi /etc/init.d/foo".
- ilyt 3y ago
  That's a lie https://news.ycombinator.com/item?id=36513889#36514362 https://news.ycombinator.com/item?id=36513889#36514362 > In fact, much of my personal dislike of systemd is that it started getting popular right as I was having that revelation and got to watch a pile of shell scripts that I could just pop open in my editor get replaced with an all-encompassing black box (yes, I know it's open source, but "you could go find the source and try to read C" is not the same as "vi /etc/init.d/foo". That theoretically is a disadvantage but practically ~90% of the systemd scripts are "point at binary, pick user, group and work dir" and entirely trivial to understand; distro ones often are a bit fancier with limiting app capabilities but those are far harder to do in init script in the first place. For vast majority of apps it's literally just 'here is binary, run it' And more important part is that I DON'T NEED TO EDIT ORIGINAL if I just want to add something. I can take 100% stock distro .service file, add Restart=always RestartSec=60s and now any time app dies it will auto-restart. Or add proxy environment, or anything else, via just override files, no need to litter our repositories with modified init scripts that just have like 3 lines changed.
  - yjftsjthsd-h 3y ago
    > That's a lie Oh, well now that you've called me a liar I suppose I have no choice but to agree with you. (/s) Here, let's have a worked example! https://git.alpinelinux.org/aports/tree/main/nginx/nginx.initd https://git.alpinelinux.org/aports/tree/main/nginx/nginx.ini... In that entire file, there is exactly one function that exceeds 3 lines; the "upgrade" command, which AFAIK doesn't exist in systemd-land. > That theoretically is a disadvantage but practically ~90% of the systemd scripts are "point at binary, pick user, group and work dir" and entirely trivial to understand; distro ones often are a bit fancier with limiting app capabilities but those are far harder to do in init script in the first place. Partially true; I'll happily agree that 90% of daemons are the simple case. Of course, that's true regardless of the service manager in play; 90% of systemd service files are trivial, and 90% of initscripts are trivial. I'll also agree that there's an advantage to making the easy stuff common; if I were actually writing initscripts for a distro I'd have them start by including a library (probably `. /etc/init.d/_common.sh` or something like that) and then most of them would also just define the ~3 needed variables and use the default function implementations. And it would still be easier to follow than a compiled version.

… you’re mourning SysV init scripts? why?

by op00to 3y ago

… you’re mourning SysV init scripts? why?

BirAdam 3y ago

Because it will one day be “invented” again as a “scriptable init”

cellularmitosis 3y ago

I mourn it. I've been typing '/etc/init.d/apache2 restart' for about twenty years now. Why change it? Would it really be that hard to have a symlink from /etc/init.d/apache2 to /bin/systemctl and teach systemctl to do the right thing?

viraptor 3y ago
There's a generic wrapper which existed for many years "service apache2 restart" will work regardless of the init type. You can also put "systemctl $1 apache2" in /etc/init.d/apache2 and keep using it. It's really not a big issue.
kaba0 3y ago
Be the change you want to see.

yjftsjthsd-h 3y ago

If nothing else, sysv scripts were conceptually really simple to the point that you look at it and think "oh, it's just a shell script; I could actually just sit down and reimplement the whole system in a weekend". In fact, much of my personal dislike of systemd is that it started getting popular right as I was having that revelation and got to watch a pile of shell scripts that I could just pop open in my editor get replaced with an all-encompassing black box (yes, I know it's open source, but "you could go find the source and try to read C" is not the same as "vi /etc/init.d/foo".

ilyt 3y ago
That's a lie https://news.ycombinator.com/item?id=36513889#36514362 https://news.ycombinator.com/item?id=36513889#36514362 > In fact, much of my personal dislike of systemd is that it started getting popular right as I was having that revelation and got to watch a pile of shell scripts that I could just pop open in my editor get replaced with an all-encompassing black box (yes, I know it's open source, but "you could go find the source and try to read C" is not the same as "vi /etc/init.d/foo". That theoretically is a disadvantage but practically ~90% of the systemd scripts are "point at binary, pick user, group and work dir" and entirely trivial to understand; distro ones often are a bit fancier with limiting app capabilities but those are far harder to do in init script in the first place. For vast majority of apps it's literally just 'here is binary, run it' And more important part is that I DON'T NEED TO EDIT ORIGINAL if I just want to add something. I can take 100% stock distro .service file, add Restart=always RestartSec=60s and now any time app dies it will auto-restart. Or add proxy environment, or anything else, via just override files, no need to litter our repositories with modified init scripts that just have like 3 lines changed.
- yjftsjthsd-h 3y ago
  > That's a lie Oh, well now that you've called me a liar I suppose I have no choice but to agree with you. (/s) Here, let's have a worked example! https://git.alpinelinux.org/aports/tree/main/nginx/nginx.initd https://git.alpinelinux.org/aports/tree/main/nginx/nginx.ini... In that entire file, there is exactly one function that exceeds 3 lines; the "upgrade" command, which AFAIK doesn't exist in systemd-land. > That theoretically is a disadvantage but practically ~90% of the systemd scripts are "point at binary, pick user, group and work dir" and entirely trivial to understand; distro ones often are a bit fancier with limiting app capabilities but those are far harder to do in init script in the first place. Partially true; I'll happily agree that 90% of daemons are the simple case. Of course, that's true regardless of the service manager in play; 90% of systemd service files are trivial, and 90% of initscripts are trivial. I'll also agree that there's an advantage to making the easy stuff common; if I were actually writing initscripts for a distro I'd have them start by including a library (probably `. /etc/init.d/_common.sh` or something like that) and then most of them would also just define the ~3 needed variables and use the default function implementations. And it would still be easier to follow than a compiled version.