[HEADS-UP] systemd for F14 - the next steps

Toshio Kuratomi a.badger at gmail.com
Fri Jul 23 11:15:49 UTC 2010


On Fri, Jul 23, 2010 at 01:49:12AM +0200, Lennart Poettering wrote:
> On Thu, 22.07.10 19:41, Toshio Kuratomi (a.badger at gmail.com) wrote:
> 
> > > if [ $1 -eq 1 ] ; then
> > >         # For new installations, hook unit file into the appropriate places via symlinks
> > >         /usr/bin/systemd-install enable --realize=reload %{unit name}.service > /dev/null 2>&1 || :
> > > else
> > >         # For old installations, just reload the configuration, don't change symlinks
> > >         /bin/bin/systemd-install realize --realize=reload %{unit name}.service > /dev/null 2>&1 || :
> > > fi        
> > > 
> > My impression from the documentation is that systemd-install enable will
> > cause the service to be enabled on the next reboot.  Is that not
> > correct?
> 
> Yes, unless you aks the init system to reload.
> 
So we don't want to do systemd-install enable in most spec files.

What systemd doesn't provide is an equivalent of the chkconfig add command.
I'm not sure if we don't need that in the systemd world or if it's an
oversight that we need to have added into systemd.  What do you think?

Basically what we're trying to replicate is:

* User can install a service
* That does not enable the service to start, even on the next reboot; other
  service asks for the socket, etc.
* However, the init system knows that the service is available for the user
  to explicitly turn on.

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20100723/53e74ebb/attachment.bin 


More information about the devel mailing list