4 ms·

And if that service file screws up how do you troubleshoot it? You end up diving in to the source code of systemd, versus fixing a bug in your script. And don'

And if that service file screws up how do you troubleshoot it? You end up diving in to the source code of systemd, versus fixing a bug in your script. And don't get me started on binary log files. As was said before, buster, your attitude is the problem. It's the same as the systemd developers and those within the community. SysVInit has served me thus far with no issues.

0x006A 12y ago
Just curious, have you ever used systemd and ran into a problem where your service file screwed up and you had yo read systemd's source code or are you making this up?
- TheSwordsman 12y ago
  Experience from a few years back. Bug was fixed and all, but left a bad taste in my mouth.
  - asdfaoeu 12y ago
    What was the bug?
- dijit 12y ago
  xl2tpd, still doesn't work. I actually had to try to figure out why, turns out systemd supercedes lsmod/modprobe etc; causing those programs to return 1 when invoked, there's no debug or anything so I was seriously weirded out. took me some time to figure out it was systemd. the firewall wrapper for iptables gives you an insecure default config and is hard to fix via config management "add a service that means port 3128 TCP, now allow incoming connections" My config management system creates files and pushes them out, I'm not in the habit of running idempotent commands repeatedly.. I'd rather check if something is correct before correcting it.
  - johnbellone 12y ago
    > My config management system creates files and pushes them out, I'm not in the habit of running idempotent commands repeatedly.. I'd rather check if something is correct before correcting it. You should be laying down a base initial configuration at the time that the machine was provisioned. The basic example of this is the sudoers file. The default setup for Ubuntu/RHEL is different enough that it was causing problems and the solution was simple - force defaults.
  - Twirrim 12y ago
    > I actually had to try to figure out why, turns out systemd supercedes lsmod/modprobe etc; causing those programs to return 1 when invoked, there's no debug or anything so I was seriously weirded out. Why on earth does it need to do that?
cbsmith 12y ago
> And if that service file screws up how do you troubleshoot it? You end up diving in to the source code of systemd, versus fixing a bug in your script. ? You end up diving in to the service file vs. the script. > And don't get me started on binary log files. Having worked with binary and plaintext log data for the better part of a decade now, I have to say that pretty much the entire set of claimed advantages of plaintext log data is very wrong, and we've wasted a ton of productivity & efficiency because of it. If you really are sure of its superiority though, just put a little stub in front that converts the binary log to a human readable format that still needs a program in order to present to the user... > SysVInit has served me thus far with no issues. Speaking of attitude... there are two ways to look at that datapoint...
andor 12y ago
And if that service file screws up how do you troubleshoot it? You end up diving in to the source code of systemd, versus fixing a bug in your script. That's a good thing, because if you find a bug, it will be fixed for everybody, not just for your one-off init script. your attitude is the problem The attitude here is to fix problems at their source. Instead of using the hammer for everything, sometimes coming up with a new tool is a better idea.
- sophacles 12y ago
  That's a good thing, because if you find a bug, it will be fixed for everybody, not just for your one-off init script. Generally I agree with this at a broad level. But, there is still the problem of: I need this running now. To do that, I need to compile and run a custom systemd, and hope that my patch gets accepted upstream, and that in a few months my distro finally adopts it and puts it in the standard package. Generally speaking I really like systemd and am excited to get some time to update my installed stuff to use it, but the above is a real concern.
  - XorNot 12y ago
    We have SysV shim layers for that though. We had them in Upstart, and we have them for SystemD. Boiled down, it can still run shell scripts that look like SysV scripts, and will be able to do so indefinitely because that's basic functionality. At the worst case though, this reduces systemd to a shim-launcher for SysV init, which is the situation you find yourself in now or when using Upstart, which tons of Ubuntu users already have been.
yrro 12y ago
> And if that service file screws up how do you troubleshoot it? You end up diving in to the source code of systemd, versus fixing a bug in your script. Surely the systemd equivalent would be delving into the source code for dash, or god help you dash... I know which one I'd prefer--not that I've ever hard to do either, fortunately!

0x006A 12y ago

Just curious, have you ever used systemd and ran into a problem where your service file screwed up and you had yo read systemd's source code or are you making this up?

TheSwordsman 12y ago
Experience from a few years back. Bug was fixed and all, but left a bad taste in my mouth.
- asdfaoeu 12y ago
  What was the bug?
dijit 12y ago
xl2tpd, still doesn't work. I actually had to try to figure out why, turns out systemd supercedes lsmod/modprobe etc; causing those programs to return 1 when invoked, there's no debug or anything so I was seriously weirded out. took me some time to figure out it was systemd. the firewall wrapper for iptables gives you an insecure default config and is hard to fix via config management "add a service that means port 3128 TCP, now allow incoming connections" My config management system creates files and pushes them out, I'm not in the habit of running idempotent commands repeatedly.. I'd rather check if something is correct before correcting it.
- johnbellone 12y ago
  > My config management system creates files and pushes them out, I'm not in the habit of running idempotent commands repeatedly.. I'd rather check if something is correct before correcting it. You should be laying down a base initial configuration at the time that the machine was provisioned. The basic example of this is the sudoers file. The default setup for Ubuntu/RHEL is different enough that it was causing problems and the solution was simple - force defaults.
- Twirrim 12y ago
  > I actually had to try to figure out why, turns out systemd supercedes lsmod/modprobe etc; causing those programs to return 1 when invoked, there's no debug or anything so I was seriously weirded out. Why on earth does it need to do that?

cbsmith 12y ago

> And if that service file screws up how do you troubleshoot it? You end up diving in to the source code of systemd, versus fixing a bug in your script. ? You end up diving in to the service file vs. the script. > And don't get me started on binary log files. Having worked with binary and plaintext log data for the better part of a decade now, I have to say that pretty much the entire set of claimed advantages of plaintext log data is very wrong, and we've wasted a ton of productivity & efficiency because of it. If you really are sure of its superiority though, just put a little stub in front that converts the binary log to a human readable format that still needs a program in order to present to the user... > SysVInit has served me thus far with no issues. Speaking of attitude... there are two ways to look at that datapoint...

andor 12y ago

And if that service file screws up how do you troubleshoot it? You end up diving in to the source code of systemd, versus fixing a bug in your script. That's a good thing, because if you find a bug, it will be fixed for everybody, not just for your one-off init script. your attitude is the problem The attitude here is to fix problems at their source. Instead of using the hammer for everything, sometimes coming up with a new tool is a better idea.

sophacles 12y ago
That's a good thing, because if you find a bug, it will be fixed for everybody, not just for your one-off init script. Generally I agree with this at a broad level. But, there is still the problem of: I need this running now. To do that, I need to compile and run a custom systemd, and hope that my patch gets accepted upstream, and that in a few months my distro finally adopts it and puts it in the standard package. Generally speaking I really like systemd and am excited to get some time to update my installed stuff to use it, but the above is a real concern.
- XorNot 12y ago
  We have SysV shim layers for that though. We had them in Upstart, and we have them for SystemD. Boiled down, it can still run shell scripts that look like SysV scripts, and will be able to do so indefinitely because that's basic functionality. At the worst case though, this reduces systemd to a shim-launcher for SysV init, which is the situation you find yourself in now or when using Upstart, which tons of Ubuntu users already have been.

yrro 12y ago

> And if that service file screws up how do you troubleshoot it? You end up diving in to the source code of systemd, versus fixing a bug in your script. Surely the systemd equivalent would be delving into the source code for dash, or god help you dash... I know which one I'd prefer--not that I've ever hard to do either, fortunately!