On 07/31/2015 08:52 PM, Linda Walsh wrote:
A wonderful benefit -- used to be the scripts were all in /etc/init.d/xxx but now, they can all be put in private, non-standard locations to obfuscate how systemd runs.
This is the real crux of the issue. With sysvinit, we all knew to look in /etc/rc.d/rcfoo and to look for yastisms/base configs in /etc/sysconfig. With systemd (which I like, and concur it is just issues such as this that leave a bad taste in my mouth) all scripts/services were to live in /lib/systemd/system with configured services linked below the various /etc/systemd/system locations (e.g. multi-user.target.wants) i.e.: ls -1 /etc/systemd/system/multi-user.target.wants avahi-daemon.service cronie.service cups.path dhcpd4.service dovecot.service httpd.service mysqld.service named.service netctl@rlf_network\x2dstatic.service nmbd.service ntpd.service nut-server.service org.cups.cupsd.path postfix.service remote-fs.target smbd.service spamassassin.service sshd.service vsftpd.service systemd is well behaved and reasonably manageable in that setup (That was with Arch). The additional difficulties suse faces is the extended /etc/sysconfig interface that systemd was loosely shoehorned into and vice versa. That opens up a whole host of new locations where fragmented bits and pieces of configs, services, scripts, etc.. can find themselves stored. When, as in Linda's case, we fail to conform to standard locations or explain changes from the prior logical setup to a new setup/config that seems to have no relation to where standard files are placed regarding systemd, we are only screwing the users out of easy/sane management of their system. This after they have presumably taken the time to learn where and how the duct-tape and bailing-wire of systemd fits together. It is frustrating to take time to learn the proper placement of config/service files for a new system only to find out "somebody took it up themselves move/place/hide a config in a non-standard location anyway". Head scratching?? Why do we have these suggested standards if nobody takes the time to follow them, ... or follow them consistently. systemd works and works well when fully implemented the way Freedesktop.org recommends. (Archlinux is the poster-child for this implementation) openSuSE has several additional challenges in deciding how/where to interface with the sysconfig layout. It would seem that the systemd standard locations for services/etc should control and then via reference or source any information needed from elsewhere. That would at least provide a road-map for the systemd implementation that conforms with the freedesktop recommendations. Having worked though systemd implementation with Arch and now openSuSE, the cleaner and simpler and more consistently you stick to the systemd recommendations, the easier it is for all. -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org