systemd questions

[Lennart Poettering]

On Mon, 16.05.11 14:32, Michal Hlavinka (mhlavink at redhat.com) wrote:

> 
> > > 2) does systemd have support for conditions in service files? It seem
> > > it's not supported right now. Is there any plan for this?
> > 
> > I am not entirely sure what you understand by "condition",
> 
> for example condition based on string/variable in file, so:
> a) EnvironmentFile=/etc/sysconfig/something; 
> ExecStart=[ $MODE = master ] && /usr/sbin/xyz_master || /usr/sbin/xyz_slave
> 
> or
> 
> b) ExecStart=grep -q something /etc/sysconfig/something && /usr/sbin/xyz_master 
> || /usr/sbin/xyz_slave

I think it would be nicer to split this into two services and make
"systemctl enable xyz-master.service" resp. "systemctl enable
xyz-slave.service" the official way to enable one of them (or both). I
think this is easier to understand for the user, because that way all
services are normalized and they do not reverse their mode of operation
completely based on configuration. The fact that upstream already split
up the stuff into two binaries for you is a pretty strong indication
that having two service files for them is a good idea, too.

> so following question: is there going to be any standard place for those 
> scripts? I'm using /usr/libexec/<package>/script_file

Well, I think we should try to minimize the amount of scripts:
i.e. ask yourself the question whether we really really want them. For
example, in the case above I would say "no, we don't", and just solve
this with two service files and nothing else. For the places where you
really really want to keep them $(pkglibexecdir) sounds like a good
solution (i.e. like you suggested).

> > > 5) in old initscripts, there was /etc/init.d/halt with section for ups
> > > shutdown. With that script gone, was that functionality ported to
> > > systemd
> > > somehow?
> > 
> > Well, any such code is just inherently broken. It *cannot* work.
> 
> but it does work for more than a decade

It has been racy for more than a decade then.

> > A number of kernel subsystems hook into the shutdown code of the
> > kernel. For example storage code syncs meta data to disk after the
> > reboot() syscall is invoked. If you however turn off power before
> > reaching reboot(), then this step is omitted which might trigger
> > data loss.
> 
> when ups recieves command for shutdown, it does not shutdown power 
> immediately, but after 30 seconds. Given that this command should be executed 
> after umount, synced disks,... when everything is ready for power off...
> 30 seconds proved to be enough time for this.

This is not the case and never has been the case. The root disks
traditionally could not be unmounted and hence MD/DM/MP and so on could
not be disassembled before going down.

Delaying shutdown by 30s is hack, not a fix for a race.

> > UPS code like that needs to sit in the kernel itself to properly
> > work. Adding userspace kludges which invokes this from userspace is a
> > recipe for desaster. 
> 
> If *you* wan't to write kernel drivers for tons of UPS models using 
> serial/usb/network/... connections with tons of protocols (with incomplete 
> documentation)... it's your freedom to do so ;)

Well, what can I say. I don't maintain UPS stuff, I don't use UPS
stuff. I am just pointing you to the fact that the current approach here
is racy, but sorry, I won't fix this for you.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.