On Mon, 16.05.11 14:32, Michal Hlavinka (mhlavink@xxxxxxxxxx) 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. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
