having to upgrade varnish isn't helping with the anger issues.
I AM NOW FULL OF RAGE.
having to upgrade varnish isn't helping with the anger issues.
I AM NOW FULL OF RAGE.
AM NOW DEBUGGING SYSTEMD, AND HAVING TO LEARN THE INTERNALS.
ALL OF THE RAGE
not kidding, we fixed it with:
EnvironmentFile=-/etc/default/varnish
ExecStart=/bin/bash -c "/bin/echo ${DAEMON_OPTS} && /usr/sbin/varnishd ${DAEMON_OPTS}"
Because otherwise systemd would randomly eat parts of ${DAEMON_OPTS}. oh yes, we *also* had to make DAEMON_OPTS a single line, because *something* didn't like '\' continuation chars.
systemd is the worst software I've ever had to use, and I've used AIX, HP-UX, Solaris, and 16-bit Windows Payroll software.
systemd parses and interprets ${VARIABLE} different than shells do.
in every shell that has ever existed, ${VARIABLE} ensures that only VARIABLE is expanded, even if VAR also exists.
systemd instead passes the entirety of VARIABLE as a single argument.
so argv and argc were wrong
ARGV AND ARGC WERE FUCKING WRONG!
I think the thing that pisses me off the most, is I was doing the work the maintainers *should* have done in the first place.
It was normal for many releases to edit a file, and it would be pulled in. The old file is still necessary, because of the reload process. They should have ensured that method still works.
wow. I sure did trigger a lot of responses to this thread.
birdsite's systemdsucks quoted me about 4 times, so did about 8 other people. my notifications on both platforms are pretty much out of control :)
the moral of the story: use software written by people that think, instead of systemd.
@phessler I'm still at a complete loss why so many linux distributions accepted it as their default init system.
Maybe it's just us old crusty *nix types that saw it for what it was ?
@phessler Do you mean it behaves exactly as written in the doc and illustrated by an example ?
--------------------------8<--------------------------
Example:
Environment="ONE=one" 'TWO=two two'
ExecStart=/bin/echo $ONE $TWO ${TWO}
This will execute /bin/echo with four arguments: "one", "two", "two", and "two two".
--------------------------8<--------------------------
https://www.freedesktop.org/software/systemd/man/systemd.service.html
@smortex it already supports single and double quotes! And they work exactly the way it does in shell.
You can even embed the single quotes in the variable, as you can see just 5 lines below your example.
It's broken, it's flawed, and it is absolutely wrong.
@ikey shell-like substitution is pretty simple. $VARIABLE gets expanded, sure. ${VARIABLE} gets expanded.
But ${VARIABLE} is never expanded to be a single argument, in any shell-like construction I've ever heard of.
The point of the feature is to take shell env variables, and I specifically used the "pull from a file" option. *That* should have shell-like behaviour.
If they used $'VARIABLE' to quote it, fine. ${V} should be a syntax error, instead of the current behaviour.
@ikey I'm a *BSD user and developer. I only use Linux under duress (aka, at work).
Besides, I've seen too many horror stories of dealing with Lennart, that I won't even bother to fix it for them. If someone else were to fix it, I wish them luck.
This is poor implementation and design. Documenting this behaviour doesn't excuse it.
@phessler if it was any other situation I'd probably argue against that - but truth be known I've encountered similar upstream situations personally and been met with the wall of nope.
FWIW, as a Linux distro developer, I've wanted to use BSD for a long time. My problem has been mostly drivers, as there is a lower barrier, higher cadence, and higher tolerance, within the Linux kernel tree, it gets the drivers first. Regardless of sacrifice..
@ikey I'm not specifically against systemd for hating-systemd's sake. I'm against it because nearly every time I look at it, it has horrible behaviours and activity.
If those behaviours are fixed, I wouldn't care.