On Thu, 12.05.11 15:28, Michal Hlavinka (mhlavink@xxxxxxxxxx) 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. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
