On Thu, 10.11.11 11:24, Ian Kent (ra...@themaw.net) wrote:
> On Wed, 2011-11-09 at 11:01 +0000, "Jóhann B. Guðmundsson" wrote:
> >
> > Now taking a quick look at the autofs service which I assume you are
> > referring too I'm not seeing anykind of massive rewrite in order for the
> > daemon ( which generally is an exception that a rule ) to work in
> > systemd unit so from a quick and convertion on top of my head while
> > writing this, here's a unit file which you can start as your base point
> > to work on.
> >
> > ### autofs.service ###
> >
> > [Unit]
> > Description=Automounts filesystems on demand
> > Requires=ypbind.service
>
> What happens if ypbind is not installed or is not enabled?
Requires= pulls in ypbind.service if autofs.service is requested,
regardless whether the former is enabled or not. If ypbind.service is
not available, then starting auofs.service will fail.
If you use Wants= instead here, then we'll still pull in ypbind if
autofs is requested, but will not fail if ypbind fails, and start autofs
nonetheless.
> The problem with this has always been people that use NIS need it to be
> started before automount but using it is not a requirement since other
> map sources may be used (and commonly are nowadays) like files or
> ldap.
In systemd ordering dependencies and requirement dependencies are fully
orthogonal. That means After=/Before= can be used independently from
Requires=/Wants=. You can have either without the other, though most
often they are used together.
If all you want to express is that if both ypbind and autofs are enabled
the latter shall be started after the former, then place an
After=ypbind.service and that's it. That ensures that autofs does not
pull in ypbind, but ensures the right ordering if both are pulled in by
other means.
> > After=network.target ypbind.service
>
> So maybe this is all that's needed, but how is the conditional ypbind
> dependency handled?
After= only has an effect if both units are being started. It's a NOP if
ypbind.service isn't also started.
> > [Service]
> > Type=forking
>
> Right, but the documentation in a previous post talked about a
> requirement to run in the foreground and log to stdout .....
Hmm? There is no requirement for that.
It's much nicer if daemons do not double-fork when used within systemd,
since it simplifies things quite a bit and makes things more robust. But
that means that your service needs to support some other kind of
notification to tell systemd when it is fully initialized (for example:
the sd_notify() API, or by taking a name on the bus), or needs to be
written in a way that thre's no need to communicate the finished
initialization to systemd at all (i.e. not listen on any sockets, or
hand over listening to systemd via socket activation).
> > PIDFile=/run/autofs.pid
> > EnvironmentFile=-/etc/sysconfig/autofs
>
> I don't think I need this either and sourcing it in the exiting init
> file is redundant. The daemon will read the configuration file itself.
>
> > ExecStart=/usr/sbin/automount ${OPTIONS} --pid-file /run/autofs.pid
>
> Oh, except for the daemon start options, mmm, maybe it's time to split
> the configuration into daemon configuration and init configuration. Is
> there a better way to do this just for the daemon start options that is
> easy for users to change?
My recommendation to simplify things for the user is to have a single
location for configuration and not split things up between options
passed on the command line and options configured in a config file.
> > [Install]
> > WantedBy=multi-user.target
> >
> > The load module and check section has been drop since loading modules in
> > systemd unit is frowned upon and rightly so since kmods these days can
> > be autoloaded on use and those that cant should drop an conf file for
> > that module load into /etc/modules-load.d/ directory.
> >
> > If yours cant be autoloaded on use here's a conf file that loads that
> > module.
> >
> > ### autofs.conf ###
> >
> > # Load autofs module at boot
> > autofs4
Unnecessary, as systemd loads that anyway, and this module is actually
auto-loadable via /dev/autofs. You may assume that autofs is always
accessible, and in fact it is nowadays compiled into the Fedora kernel,
and not a kmod.
Lennart
--
Lennart Poettering - Red Hat, Inc.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
