systemd questions

[Lennart Poettering]

On Thu, 12.05.11 15:28, Michal Hlavinka (mhlavink at redhat.com) wrote:

> Hi,

Heya,

> I'm working with nut upstream to test sysv->systemd changes, but I found some 
> problems and they've came up with a few questions too.
> 
> 1) does systemd support alternative to "service sthd configtest" or other 
> special actions?

Additional SysV verbs continue to work with the systemd SysV
compatibility. However, in the long run we'd like people to use
service-specific tools for service-specific operations.

> 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", but if you do
understand the same thing as we do, then we support a pretty flexible
set of condition checks:

ConditionPathExists=
ConditionPathIsDirectory=
ConditionDirectoryNotEmpty=
ConditionKernelCommandLine=
ConditionVirtualization=
ConditionSecurity=

The latter two are for checking whether we are run in a virtualized
environment (kvm, vmware, ...), resp with a specific secureity framework
enabled (selinux, ...).

See systemd.unit(5) for details.

> 3) in which cases I should ommit [Install] section in service file?

[Install] is used for "systemctl enable" and "systemctl disable". If you
have no such sections these commands will become NOPs. Which is
desirable in two cases: a) you always expect the user to manually create
.wants/ symlinks with ln -s or b) your package hard-enables the service file in
question, because it is such a core component of the system that there
is no point in ever disabling it. One example for such a service is
udev, but of course most services do not qualify as this, and should
hence include [Install].

> 
> 4) Is there any difference between 
> a) A.service: After=B.service
> and
> b) B.service: Before=A.service
> or both a) and b) are required?

a) implies b) and b) implies a). One of those lines is sufficient,
specifying both doesn't hurt. It's probably a good idea to place the
order line in the "small" service, relative to the "big" service, and
leave out the other direction, to simplify things.

> We have service A and service B. Service B requires service A, but it can 
> require service A from different host (depends on configuration). So we've 
> added After=A in service B and also Before=B in service A, but it did not 
> help. Expected result was B is started and if A is configured to start too, it 
> should be started before B. Actual result is that B is started before A if 
> both of them should start (when using systemctl start B.service
> A.service).

As you already filed a bug about currently "systemctl start A.service
B.service" starts those services in the order you specify them on the
cmdline, in two separate transaction. We should probably fix this to
start them in a single transaction.

> 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. 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. 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. The point of UPS is to prevent data loss after all,
and if you turn off the power before the kernel dealt with reboot() you
invite data loss. (And no, just adding random sleeps, is not a fix, it
just delays the problem.)

(That all said you may drop binaries into /lib/systemd/system-shutdown
which are executed right before invoking reboot(). But if you package
anything that drops binaries into that dir for UPS uses, then I will
personally track you down and tell you mom how bad you are!)

Lennart

-- 
Lennart Poettering - Red Hat, Inc.