[systemd-devel] How to get used to systemd vs init

Chad ccolumbu at gmail.com
Tue Jun 23 16:14:19 PDT 2015


On 6/23/2015 1:41 PM, Ronny Chevalier wrote:
> On Tue, Jun 23, 2015 at 10:16 PM, Chad <ccolumbu at gmail.com> wrote:
>> On 6/23/2015 1:01 PM, Reindl Harald wrote:
>>>
>>>
>>> Am 23.06.2015 um 21:45 schrieb Chad:
>>>> The new systemd way would be to type (23 total characters, no tab
>>>> complete):
>>>> systemctl restart httpd
>>>> Maybe I could tab complete systemctl, but I don't currently have a
>>>> CentOS 7 system to test on.
>>>
>>> maybe you should just install CentOS inside a VM and test it
>>>
>>> [root at srv-rhsoft:~]$ systemctl restart h
>>> halt-local.service               haveged.service home.mount
>>> hostapd-guest.service
>>> httpd-lounge-worker.service      hybrid-sleep.target
>>> halt.target                      hibernate.target
>>> hostapd-guest-interface.service  hostapd.service httpd.service
>>>
>>>
>>>> The real issue is that I have to know (in the above example) that it is
>>>> httpd not http.
>>>> With so many systems, distros, and services it is hard to remember every
>>>> service name exactly (and some names are very long). For example ntpd
>>>> has a d, but nfs does not.
>>>> Tab completion fixes this issue for me.
>>>>
>>>> How can I use tab completion with systemd?
>>>
>>> as like for any other software - hit the TAB key
>>>
>>>> #####
>>>> 2. How to find all possible services:
>>>>
>>>> The init way:
>>>> ls -l /etc/init/d
>>>>
>>>> The systemd way:
>>>> ls -l /lib/systemd/system/*.service /etc/systemd/system/*.service
>>>>
>>>> This seems WAY harder and I have to remember 2 locations instead of 1
>>>
>>> nobody but you installs systemd-units in /etc/ and so you have only one
>>> location AND customized ones - with sysvinit you
>>> had no way to override /etc/init.d/httpd without doing the work after each
>>> update again
>>>
>> Harald,
>> Thank you for your reply and time.
>>
>> I will make some time at some point to install CentOS 7 again, I just don't
>> have one installed right now.
>>
>> #1 I did not know you could tab complete that way! i.e. as part of a command
>> argument, not just as part of a path.
>> Guess I learned something new after 20 years :)
>>
>> #2 I can see the advantages of having a local override just like /usr/bin
>> has /usr/local/bin.
>> Out of curiosity is there a reason the team did not follow the local pattern
>> with something like: /lib/systemd/local/system?
>> It is easy enough to create an alias on systems I use often, it will just
>> take time to learn/memorize the new paths, I am so used to /etc/init.d.
>>
> See http://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/
> for why /lib/ is not used anymore.
>
> Anyway, /usr is considered to be vendor specific (what your distro
> provides you) and you should not modify it. /etc, in the other hand,
> is entirely for you. If you want to override a unit configuration, you
> do not modify /usr/lib/systemd/system/foobar.service but you put your
> version in /etc/systemd/system/foobar.service. Then you reload the
> units via systemctl daemon-reload. systemctl also provides a simple
> tool to do this:
>
> systemctl edit --full foobar.service
>
> It will copy the unit in /etc and open your editor. When you save and
> quit, it will automatically run systemctl daemon-reload. You can also
> only modify just one directive of a unit file by using:
>
> systemctl edit foobar.service
>
> It will create /etc/systemd/system/foobar.service.d/override.conf and
> open your editor. In this file you just have to put the
> lines/directives that you want to modify from the original one,
> without having to edit the entire unit.
>
>> ^C
>>
>> _______________________________________________
>> systemd-devel mailing list
>> systemd-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/systemd-devel
I guess I am used to /usr/local/bin, /usr/local/src, /lib/local, etc. So I wondered why /usr/lib/systemd for system 
files and /etc/systemd for local files as opposed to something like /usr/lib/local/systemd or maybe 
/usr/local/lib/systemd. I don't have strong feelings about it and I did not know any of the history until I read your 
reply and the link you sent. I know that as a group developers normally have a reason for what they do so  I was curios 
why the move away from the local dir standard. I use /etc/<service> all the time as you know tons of stuff follows that 
path, so that one is no big deal.

^C




More information about the systemd-devel mailing list