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

Ronny Chevalier chevalier.ronny at gmail.com
Tue Jun 23 16:25:35 PDT 2015


On Wed, Jun 24, 2015 at 1:07 AM, Chad <ccolumbu at gmail.com> wrote:
> Mr. Chevalier,
> Thank you for your time and reply.
>
> On 6/23/2015 1:30 PM, Ronny Chevalier wrote:
>>
>> On Tue, Jun 23, 2015 at 9:45 PM, Chad <ccolumbu at gmail.com> wrote:
>>>
>>> I am sure this is the wrong place to send this e-mail, but I could not
>>> find
>>> another place to send it.
>>
>> Hi,
>>
>> It is the good place :)
>
> Great, thanks.
>
>>> I want to learn and use systemd, but have run into a few problems on my
>>> way.
>>> Please don't see this as an attack on systemd, I want to learn something
>>> new, but change is hard.
>>>
>>> I am an old school kind of sysadmin and I am planning on moving from
>>> CentOS
>>> 6 to CentOS 7, but I am having trouble with systemd. I am hoping you know
>>> some shortcuts/tricks to help me learn the new way.
>>>
>>> #####
>>> 1. I can't spell. With init I don't have to know how to spell things
>>> because
>>> I have tab complete. I use tab complete for almost every command I type.
>>> For
>>> example:
>>> /e<tab> gets -> /etc/
>>> /etc/in<tab>  gets -> /etc/init
>>> /etc/init.<tab>  gets -> /etc/init.d/
>>> /etc/init.d/ht<tab gets -> /etc/init.d/httpd
>>> /etc/init.d/httpd restart
>>> So I entered 19 characters and got 25 with tab complete.
>>>
>>> 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.
>>>
>>> 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?
>>
>> If you use either bash or zsh, systemd provides shell completion for them.
>>
>> You could do something like:
>>
>> systemctl start htt<tab>
>> systemctl st<tab>
>>
>> or else, and it will complete it.
>
> I use bash. This is a cool trick that systemd has over init.d. I know not
> all programs can do that shell completion, for example /etc/init.d/httpd
> res<tab> does not work (I try it all the time out of tab completion habit!).
>>
>>
>>>
>>> #####
>>> 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.
>>
>> There is:
>>
>> systemctl list-unit-files
>>
>> It lists all the units installed on your system. In systemd a unit is
>> a configuration file that can describe a service, a mount point, a
>> device,... So a service is a subtype of unit, see "man 5 systemd.unit"
>> for more information.
>>
>> So if you want to only display the services, you just have to specify the
>> type
>>
>> systemctl list-unit-files --type=service
>
> Ok, so that is a lot more to remember than ls -l /etc/init.d, but I can
> learn it.
>>
>>
>>> #####
>>> 3. List all services and their start levels:
>>>
>> In systemd world, start levels equivalent are the targets (see man 5
>> systemd.target). A target is a synchronisation point between multiple
>> units. For example, there is sysinit.target which is the
>> synchronization point for early boot services. This way a unit can ask
>> to be started only after a specific target, for example.
>>
>>> The init way (all services):
>>> chkconfig --list
>>>
>>> The init way (only active services. I use this a lot):
>>> chkconfig --list | grep :on
>>>
>>> The systemd way (all services):
>>> systemctl list-unit-files --type=service
>>>
>>> The systemd way (only active services, I don't know how to do this).
>>> systemctl ???
>>>
>> With systemctl you can provide a filter according to the current state
>> of a unit. If you want to list all the active service, you can do:
>>
>> systemctl --state=active --type=service list-units
>
> Ok, again more to type and remember, but memorization is not out of the
> question.
>>
>>
>>> #####
>>> 4. What about the many programs that rely on /etc/init.d/<service>
>>> status/start/stop/restart
>>> I have many services that are monitored by nagios or cron jobs (like
>>> logrotate) that rely on /etc/init.d/<service> status/start/stop/restart.
>>> I don't want to change them because right now they work on every server
>>> and
>>> I don't want to have to maintain 2 versions of the code or hunt them all
>>> down.
>>
>> There is systemd-sysv-generator which creates wrapper .service for
>> sysv scripts automatically at boot. But you need to specify additional
>> headers if you want to use ordering. See man systemd-sysv-generator.
>
> That is what I am looking for (systemd-sysv-generator), but does that mean
> systemd will not use the .service files and the system will go back to
> running all start-up scripts in order via init.d style S01-S99?
> I don't really care that much as boot time does not matter (I rarely reboot
> and always have a secondary server that can take the load. I run all
> clusters or active/backup.)

No, systemd-sysv-generator will read init scripts and generates
equivalent services (a systemd unit). Then systemd will load this
services like it loads every other units and infer what needs to be
started first according to the configuration in the units. The
priority of the S01-S99 is also respected, unless the script used LSB
headers to specify the ordering.

>
>>> Is there some trick/3rd party script to create /etc/init.d
>>> wrappers/scripts
>>> to make all the services work with the old path?
>>> Something like:
>>> ln -s /lib/systemd/system/<service>.service /etc/init.d/<service>
>>> Or maybe a shell script like:
>>> service=`basename "$0"`
>>> systemctl $1 $service
>>>
>>> So I would like to move forward with systemd (and will eventually have to
>>> if
>>> I want modern/supported OSs), but systemd seems harder to deal with and
>>> will
>>> break a lot of my existing scripts/cronjobs/monitors.
>>>
>>>
>>> Thank you all for your work on FOSS, you are making the world a better
>>> place!!
>>>
>>> --
>>>
>>> ^C
>>> Chad Columbus
>>> 20 years of application development and sysadmin
>>> Currently maintaining about 30 CentOS 6 servers.
>>> Have maintained over 1,000 linux servers over the years.
>>>
>>> _______________________________________________
>>> systemd-devel mailing list
>>> systemd-devel at lists.freedesktop.org
>>> http://lists.freedesktop.org/mailman/listinfo/systemd-devel
>
>


More information about the systemd-devel mailing list