Red Hat Bugzilla – Bug 661255
Providing native systemd file for upcoming F15 Feature Systemd
Last modified: 2012-03-13 14:31:30 EDT
The attached file is a native systemd file for upcoming F15 Feature 
Please read  on how to packaging and installing systemd Service files.
To learn more about Systemd daemon see .
To view old SysV with the new Systemd site by site see for your component see 
If you have any question dont hesitate to ask them on this bug report.
Created attachment 467442 [details]
Created attachment 467443 [details]
Created attachment 467446 [details]
seems to be needed, but it doesn't work - daemon refuses to start.
These services should start after network.target
I made an initial attempt, based on the varnish.service file attached above. Please consider the files attached. They may also be found here:
Created attachment 528185 [details]
systemd service/unit file for varnish
This service/unit file needs an environment config file
Created attachment 528187 [details]
environment configuration file for varnish systemd service/unit file
There is a question if that config file should not be dropped altogether and those variable set as they are and users directed to copy the unit file to /etc/systemd/system then edit it those options there and restart the daemon instead.
Same amount of work for the user but one less file installed on the system...
Created attachment 555479 [details]
varnish systemd service file with configuration environment merged in
So, something like this? http://users.linpro.no/ingvar/varnish/systemd/varnish.service_with_environment
Nope not quite let me look at this for a bit
Created attachment 555497 [details]
Native systemd service file for varnishncsa
Created attachment 555498 [details]
Native systemd service file for varnishlog
Created attachment 555499 [details]
Native systemd service file for varnish
Usage of /etc/sysconfig/foo file are no longer necessary and unit containing reference of such files wont work across distributions thus upstream wont accept the units when you submit it there.
Users should now copy the relevant unit file they want to make modification to /etc/systemd/system and add/edit any options to it there like adding additional switches to a daemon when the unit is being started.
varnishlog and varnishncsa are trivial, so those are fine.
For varnish itself, my last update ("varnish.service_with_environment") does not use sysconfig. It has all options merged into one systemd service file.
Just adding a default set of options may work, but that would be a big step backwards. I would really, really like to keep comments about what the options actually do, as unfortunately, there are a lot of users that won't read all the fine print in the man pages. It also makes the transition from configuration in sysconfig/defaults to systemd easier for the such users.
I also need the configuration to available to other scripts, like varnish_reload_vcl. Inlining the configuration environment in systemd makes it possible to let other scripts do nice and dirty things like emulating sysconfig/defaults:
. <(/bin/systemctl show varnish.service --property=Environment | tr ' ' '\n' )
As for acceptance of systemd files upstream in varnish, that will probably be me, testing it out in Fedora.
(In reply to comment #16)
> varnishlog and varnishncsa are trivial, so those are fine.
> For varnish itself, my last update ("varnish.service_with_environment") does
> not use sysconfig. It has all options merged into one systemd service file.
Which is not the problem here.
> Just adding a default set of options may work, but that would be a big step
> backwards. I would really, really like to keep comments about what the options
> actually do, as unfortunately, there are a lot of users that won't read all the
> fine print in the man pages. It also makes the transition from configuration in
> sysconfig/defaults to systemd easier for the such users.
Calling those environment variable from within a unit makes absolutely no sense in your case since you can pass those options directly to the daemon and unit files are not meant to serve as some kind of documentation for command line switches and what those switches do that's what man pages, configuration files
and upstream documentations.
> I also need the configuration to available to other scripts, like
> varnish_reload_vcl. Inlining the configuration environment in systemd makes it
> possible to let other scripts do nice and dirty things like emulating
> . <(/bin/systemctl show varnish.service --property=Environment | tr ' ' '\n' )
Both your example here above and suggestion of the unit file are just workarounds.
When unit files starts to get bloated that only highlights an underlying problem.
The underlying problem here with varnish is that it's daemon does not parse configuration file at startup so convincing upstream to fix this would be the absolute best way to proceed in this situation then the unit file could look something like these..
Description=Varnish HTTP Accelerator
ExecStart=/usr/sbin/varnishd -F /etc/varnish/varnish.conf
In that configuration file you could put the documentation and create and use a script to read it's settings.
> As for acceptance of systemd files upstream in varnish, that will probably be
> me, testing it out in Fedora.
Now if upstream is not willing to patch their daemon to support parsing a configuration file then it's better to continue to use an environment file but place it and call it from a distro agnostic place like /etc/varnish directory ( /etc/sysconfig/ is Fedora/Red Hat spesific ).
varnish-3.0.2-1.fc17 has been submitted as an update for Fedora 17.
* should fix your issue,
* was pushed to the Fedora 17 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing varnish-3.0.2-1.fc17'
as soon as you are able to.
Please go to the following url:
then log in and leave karma (feedback).
varnish-3.0.2-1.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report.