On Tue, Jan 29, 2013 at 1:33 PM, Stefan G. Weichinger <li...@xunil.at> wrote: > Am 29.01.2013 20:23, schrieb Canek Peláez Valdés: > >> I really believe the most important thing abount systemd unit files is >> that they are small and simple. You can also check the exit status >> from each command in the script, or even better, you can do a test >> after all the commands are done to check the status of the bridge and >> see if it was created correctly. >> >> None of this belongs in the unit service, IMO. Otherwise, you end >> creating ssh keys and user groups in unit files, and none of this >> belongs there. Clear separation between the services and the init >> system. >> >> But of course, as I said to Stefan, if it works it works. > > As I mentioned it is a first version ... just to make things work. > > If all the services/daemons/stuff work with systemd then I am able to > use it as default init-system here and I don't have switch back to > openrc to do my work (for example when I need KVM-based virtualization > on my workstation). > > I agree with your argument that unitfiles should be as small and simple > as possible, on the other hand those commands just get pulled in from > elsewhere: the complexity is just moved out of sight, right?
I don't think so, no. It's like the Model/View/Controller design pattern: The code does the same (sometimes it even grows in complexity), so we are just moving stuff around, right? No, we are clearly splitting the information we have, and how do we present it to the user, with a set of well defined interfaces in the control module on how to update the second using the first. Or with a webapp; we can mix the information with the presentation, why to split them? We are just moving it out of sight, right? No, again, we split the information on a web page from how do we present it to the user, so when something breaks, we know where it did. Imagine that systemd had a bug in its ExecStart= directive. Perhaps it works for the first 5 commands, but it fails in the 6th. Then you would have been stuck for hours (perhaps days) trying to debug your unit file, when it had nothing wrong, really. If instead you put all the logic pertaining to your service in a script, or executable, or whatever, but *clearly separated* from systemd, and you got it working, and it doesn't work with systemd, then you *know* where the problem is. I really believe the proper solution is to clearly separate this stuff. You can abuse the Type=oneshot unit files, or heck, even put everything in a single ExecStart=( command1; command2; command3; ...; commandN). That doesn't mean you should. Just my 0.02 cents. > I did quite some research to find more elegant solutions ... so far I > wasn't successful. I find more elegant to clearly split the commands your service uses from the unit file. > For now I am happy to get my itches scratched ... I am absolutely ready > to learn and improve things. Sharing my first steps here maybe helps to > motivate other gentoo-users to give systemd a try? I would not bet on that ;) too much resistance. However it is certainly getting better and better: the LWN article on The Biggest Myths about systemd had an overwhelmingly majority of comments positive to systemd, and just a handful of negative comments: http://lwn.net/Articles/534210/#Comments But that is in LWN; Gentoo is way behind, I believe. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
