Heads Up: FESCo is considering to block packages providing sysvinit services without systemd unit

[Ian Kent]

On Fri, 2011-11-11 at 14:15 +0100, Lennart Poettering wrote:
> On Thu, 10.11.11 11:24, Ian Kent (raven at 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.

OK, so all I really need is an After=, that's good.

> 
> > > [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).

I was hoping this would be straight forward.

I have do have a foreground option but I need to encode the log level in
stderr messages which I think will be straight forward as all the
logging code is in a single source file and the log functions are
specific to level.

> 
> > > PIDFile=/run/autofs.pid

What about the pid file.
Do I need to continue to pass the pid file option to autofs or will
systemd do all the pid file handling?

> > > 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.

I agree and that's why we still have a single config file against
complains about having two different types of configuration in the same
location.

Sounds like retaining the sourcing of the config file is the most
sensible option.

> 
> > > [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.

Oh, I wasn't aware it was compiled in these days.
That removes the module name problem for Fedora at least.

Not sure the module is auto-loadable via /dev/autofs because the
miscellaneous node is registered (which causes it to be created) by the
kernel module and IIRC the minor number is dynamically allocated by the
miscella but maybe there's something I don't know about miscellaneous
devices.  

I still need to rename the module at some point, since the old autofs
module has now been removed I can do that, but it will potentially cause
quite a disruption and providing a backward compatible mechanism in
kernel has proven to be problematic.

Anyway, I'll start work on the logging changes and add a unit file and
see how we go. Should autofs install the unit file into the systemd area
or what should do?

Ian