I'm reopening because I read correct objections of Guillaume (who works at Varnish btw) about the correct way to launching varnish with systemd.

Why this is not a bug? I don't think varnish use a systemd activation logic so foreground may not be the suitable option here.

Running things in the forground is completely normal for systemd. If you're expecting stdout feedback from running systemctl start, you're doing things very, very wrong.

I agree, foreground is the preferred way of running daemons with systemd, because we avoid a fork, but systemd doesn't means always foreground.
systemd needs to know when a daemon has been started for ordering, so a correct way of knowing that is important.

The feedback from systemctl is not the real topic here, but we can expect one because it has been conceived that way. As you may know «systemctl start» wait the service to be started before returning and let's people know about errors. Why is this very² wrong?

@Guillaume, do you know why varnish doesn't fail (return !=0) when started with a wrong configuration file in foreground mode?

So the real issue here is that varnish fails, but doesn't want to tell anyone that it failed? What?

I guess the issue is that the systemd unit should be adapted to the way varnish tell it has failed to start.

As varnish is providing services on the network, without sd_notify and if they respect systemd recommendation on the forking code, type=forking may be the appropriate solution.
Like we do with nginx...

I closed this because I hadn't even considered that it would exit 0 after a failure. I still can't fathom it.

Hi, returning 0 after a failure would be pretty stupid, I heartily agree, and varnish doesn't do that.

Ironically, my main argument here is that with "type=simple" running "systemctl start varnish" will return 0 no matter what. You need to run "systemctl status" afterwards to check.

Using "type=forking" would allow systemd to bubble the failure up during the start operation.

So we're back to wanting errors shown in stdout, and back to not a bug...

I really don't care about stdout, only about the exit code.

I hadn't even considered that you would want "systemctl start varnish" to exit 0 after a failure. I still can't fathom it. ;-)

You should care about proper startup, which Type=simple cannot guarantee.

> I hadn't even considered that you would want "systemctl start varnish" to exit 0 after a failure. I still can't fathom it. ;-)

What. systemctl is a command that manages systemd units in the systemd service hierarchy. It returns success when it correctly communicates the start command to the service manager -- if you want to know about internal service manager states in a script, you'll need to query the service manager...

systemctl show varnish.service -q -p ActiveState

will return after a failure,

ActiveState=failed

If the service manager itself is having issues with type=simple, please explain what those issues are, and if not, file an upstream bugreport with systemd and watch them not care.

So: https://www.freedesktop.org/software/systemd/man/systemd.service.html

> "Type=simple services are really easy to write, but have the major disadvantage of systemd not being able to tell when initialization of the given service is complete."

That seems like a pretty big step back to me, specially when we have the option to avoid it.

varnishd supports forking and systemd has Type=forking ("Many traditional daemons/services background (i.e. fork, daemonize) themselves when starting. Set Type=forking in the service's unit file to support this mode of operation."), that's not a fringe option or a hack, that's the a perfectly valid, common option.

I do get the KISS mindset, but here, refusing to use the provided and supported feature leads to more cumbersome code: if you have a service needing varnish to be started Type=forking will block until the fork happens, with Type=simple you have to reinvent the wheel and provide your own waiting loop, for every single service depending on varnishd.

Then that is a significantly different argument from "I care about the shell exit code of running `systemctl start varnish.service`"

Not really, "systemctl start" should return 0 once started correctly. That's the whole thing. You can focus on the "once started" part or on the "started correctly" one, the point is that "Type=simple" is a "nice" way to make a service out of a non-forking process, but it's counter-productive to use when you have forking capabilities.

Hmm, let's see:

"
I would like to report a bug. The varnish package installs a downstream Arch Linux-specific systemd unit file (since upstream did not provide one), which uses Type=simple. This is wrong and it should use Type=forking in order to ensure that the service is blocked until varnish has properly started, thereby allowing proper systemd service dependency ordering.

An alternative would be to use Type=notify or Type=dbus, but these won't work as varnish does not actually implement such an interface.

Currently it is impossible for a service to specify
Requires=varnish.service
After=varnish.service

and actually know with any degree of confidence that varnish is truly available.
"

I have no idea where "meaning that the user don't get any feedback in case the configuration is wrong and varnishd fails to start" came from, nor why "Ironically, my main argument here is that with "type=simple" running "systemctl start varnish" will return 0 no matter what. You need to run "systemctl status" afterwards to check." matters, if the issue is entirely related to blocking the service manager state.

If that's what it takes to get a fix, sure, thank you for writing the proper bug report.

Should be fixed in varnish-5.2.1-2. The unit is now Type=forking.

Thanks a lot!