What do you do if your server boots to a graphical user interface (GUI), but you need it to boot to the command-line interface (CLI) for security and performance reasons? In days past, you would have edited the /etc/inittab file so that, instead of booting to runlevel 5 (the GUI), it booted to runlevel 3 (the CLI). However, with the advent of the systemd system manager, you must do something a bit different.
First, you no longer use the runlevel term. Instead, you refer to boot choices as targets. The two primary targets for this scenario are multi-user.target (the CLI) and graphical.target (the GUI). The multi-user.target may be loosely associated with the legacy runlevel 3 concept, while the graphical.target is similar to runlevel 5.
It's possible to switch targets manually, and you can also configure automatic or default boot targets. This article aims to explain both options.
Identify the current target
It's probably clear when you boot the system which target is the default. However, to confirm the default, use the systemctl command along with the get-default subcommand:
$ sudo systemctl get-default
The result will likely display either the multi-user.target or graphical.target.
Change targets manually
You can switch between targets on the fly by using the isolate subcommand. Perhaps you have a long checklist of administrative tasks, and it would be simplest for you to accomplish these in a GUI, but your server boots to the CLI. You can switch to the GUI, perform your tasks, and then switch the system back to the more efficient CLI.
Here's the command to launch the GUI from the multi-user.target:
$ sudo systemctl isolate graphical.target
Switch back by specifying the multi-user.target with this command:
$ sudo systemctl isolate multi-user.target
Those commands are useful for the current runtime, but what about configuring a default for when the system boots?
[ Free online course: Red Hat Enterprise Linux technical overview. ]
Set a default target
The default target represents the interface presented when the system first boots. Booting a server to a CLI for efficiency and security is common. The CLI consumes far fewer resources and contains less software to patch and worry over. Newer administrators or those migrating from another server platform may not be comfortable enough with Bash to work effectively at the command line. End-user workstations rarely boot to the CLI because the user typically needs graphics-based software, such as productivity suites and web browsers. For these users, the performance hit is worth the convenience.
Use the following systemctl command to configure the default startup target as the CLI:
$ sudo systemctl set-default multi-user.target
Use the graphical.target argument to set the GUI as the default.
Try it
Try the following exercise if you have a systemd-based distribution available, such as Red Hat Enterprise Linux (RHEL).
Check the current default target:
$ sudo systemctl get-default
Switch to the opposite target (for example, if your system boots to the GUI, switch to the CLI):
$ sudo systemctl set-default multi-user.target
Reboot and confirm the appropriate target launched:
$ sudo systemctl reboot
Manually switch targets:
$ sudo systemctl isolate graphical.target
Configure the system back to the original target:
$ sudo systemctl set-default graphical.target
Reboot and then confirm the default target:
$ sudo systemctl reboot
If you don't have access to a system to experiment with, I encourage you to create a simple lab environment for these types of learning opportunities.
Understand target files
Targets are managed by .target files that simply group units and dependencies into a convenient format. It's really the .unit files that define exactly what services and other features start when the target is initiated. Enabling and disabling services and daemons adds and removes these components from the startup options:
$ sudo systemctl enable sshd
$ sudo systemctl disable sshd
Wrap up
This article covers the mechanics of identifying, switching, and setting targets on the system. These targets are managed via .target files. You can configure automatic startup options by using the set-default subcommand or manually switch targets with the isolate subcommand. I encourage you to walk through the exercise above; hands-on experience is essential for day-to-day administration and certification exams such as the Red Hat Certified System Administrator (RHCSA).
저자 소개
Damon Garn owns Cogspinner Coaction, LLC, a technical writing, editing, and IT project company based in Colorado Springs, CO. Damon authored many CompTIA Official Instructor and Student Guides (Linux+, Cloud+, Cloud Essentials+, Server+) and developed a broad library of interactive, scored labs. He regularly contributes to Enable Sysadmin, SearchNetworking, and CompTIA article repositories. Damon has 20 years of experience as a technical trainer covering Linux, Windows Server, and security content. He is a former sysadmin for US Figure Skating. He lives in Colorado Springs with his family and is a writer, musician, and amateur genealogist.
유사한 검색 결과
Red Hat Enterprise Linux now supported for Microsoft SQL Server on Azure VMs with SQL IaaS Agent extension
Red Hat Enterprise Linux is ready for AWS M9g instances, powered by Graviton5
The Overlooked Operating System | Compiler: Stack/Unstuck
Linux, Shadowman, And Open Source Spirit | Compiler
채널별 검색
오토메이션
기술, 팀, 인프라를 위한 IT 자동화 최신 동향
인공지능
고객이 어디서나 AI 워크로드를 실행할 수 있도록 지원하는 플랫폼 업데이트
오픈 하이브리드 클라우드
하이브리드 클라우드로 더욱 유연한 미래를 구축하는 방법을 알아보세요
보안
환경과 기술 전반에 걸쳐 리스크를 감소하는 방법에 대한 최신 정보
엣지 컴퓨팅
엣지에서의 운영을 단순화하는 플랫폼 업데이트
인프라
세계적으로 인정받은 기업용 Linux 플랫폼에 대한 최신 정보
애플리케이션
복잡한 애플리케이션에 대한 솔루션 더 보기
가상화
온프레미스와 클라우드 환경에서 워크로드를 유연하게 운영하기 위한 엔터프라이즈 가상화의 미래