Good Morning,
Working through the certification program I come to a chapter that could lead me to having an unworkable computer; turning off the graphics. Figured Id check with an expert before taking off my training wheels. The examples used in this course are Ubuntu, Suse, and something else that isnt Manjaro. It reads that I can stop the GUI with the systemctl utility and most systems work with telinit command as in:
sudo systemctl stop gdm (or, sudo telinit 3) [an aside question; what is the 3 for after telinit?]
And to restart the GUI from console with:
sudo systemctl start gdm (or sudo telinit 5) [again, what is the 5?]
So from here my questions are 
Does this work and should I do it to continue my training, or would you recommend a different approach? My concern is getting to a position where I can’t get out. Once the GUI is gone I won’t be able to do much if these commans dont work to restore it.
Thankyou for taking the time to read and offer instruction
I don’t qualify as expert - I skipped directly to systemd
The number refers to runlevels (old init system) and roughly 3 is terminal and 5 is gui.There are subtle differences - I cannot remember them.
For example - if you edit the grub commandline and add the number three (3) you will boot directly to console skipping the display manager.
gdm is the display manager with gnome and stopping this on xfce will have no effect as xfce uses lightdm as display manager.
Unless you disable the display manager it will launch on next reboot.
It’s one of the UNIX System V runlevels. A runlevel is a preconfigured state of operation that the Linux kernel knows how to interpret if passed as a boot-time parameter in the form of a number.
The idea of the runlevels goes back to AT&T Unix System V, and every runlevel starts and stops a number of services by way of init scripts, so that when you switch to a different runlevel, sysvinit will start executing a number of scripts which ─ depending on their name ─ will either start or stop a number of services.
These scripts are usually stored in a directory called /etc/rc/rc.d/, and they are then called upon via symbolic links in the directories /etc/rc/rc.{0..6}/, whereby each /etc/rc/rc.${NUMBER}/ directory corresponds to each of the seven System V runlevels.
The seven runlevels are defined as follows… 
0 = complete shutdown
1 = single-user maintenance mode: root account only, no networking, no GUI
2 = multi-user mode: no networking, no GUI
3 = multi-user mode: networking but no GUI
4 = the same as 3, but generally unused
5 = multi-user mode: networking and GUI
6 = reboot
Notes:
-
The kernel also recognizes “S” as a synonym for runlevel 1.
-
Different distributions may have different setups for the runlevels. For instance, back when SUSE was still using
sysvinit, they had runlevel 4 as the one that had the GUI, and runlevel 5 was the one that was left unused. -
In a traditional
sysvinitsystem, booting up in runlevel 1 will only mount the root filesystem, but no other partitions/filesystems. However, switching to runlevel 1 from within any other runlevel will not unmount any mounted filesystems. -
In
systemd-based systems, booting up in single-user maintenance mode will mount anything that’s needed for booting, because if you have for instance/usron a separate partition ─ as I have ─ then you need to have the faculties for mounting/usrembedded in theinitramfs, and then this mount is executed in very early userspace, beforesystemdis started, just as with the mounting of/dev.
Switching between runlevels is accomplished by way of the telinit command, executed with superuser privileges ─ i.e. via sudo or while logged in as root. This command is still supported in distributions based upon systemd for compatibility reasons, but systemd doesn’t use the traditional sysvinit runlevels. Instead, systemd uses .target files, whereby each .target file specifies which services it needs to have available before it can be executed. This is due to systemd's dependency-based system initialization ─ something that traditional sysvinit never had.
For instance, switching to runlevel 1 in a systemd-based GNU/Linux system can be accomplished by issuing the command…
sudo systemctl isolate rescue.target
Now, in Arch, Manjaro and other Arch-derivatives, there is no preconfigured equivalent for runlevel 3 due to the dependency-based nature of systemd's .target files. However, you can execute pure non-graphical tasks and programs from within a character-based virtual console, also known as a tty.
As an example, say that you are running Plasma as your graphical desktop environment ─ just as an example ─ and you wish to switch to tty3, then from within Plasma, you simply press Ctrl+Alt+F3.
You don’t even need to log out of Plasma in order to do that, because UNIX is a multi-user platform and supports concurrent login sessions. However, in order to do something as incisive as a major update in Manjaro, I always recommend completely logging out of the GUI session ─ you have to be looking at the login screen again ─ and then switching to a tty and running the update with pacman or pamac from there, so that no shared libraries will be in use that are going to be overwritten by the update process.
The exact key combination for switching to a character-based virtual console will depend on which graphical environment you’ve got running. For instance, with KDE Plasma, the Plasma session will run at tty1, and so you still have tty{2..6} available for pure character-mode logins. XFCE and GNOME run at different ttys, but the Ctrl+Alt+Functionkey combination always works.
Switching back to the GUI is similar, except that you don’t need to press the Ctrl key for that. So ─ again, with Plasma as the example ─ pressing Alt+F1 will switch you back to your running Plasma session, or to your sddm login screen. Do however keep in mind that switching back and forth does not log you out of any tty sessions you have open.
If you need to be in the equivalent of runlevel 3 however ─ i.e. without the GUI running anywhere ─ then the only way to really do it in a systemd-based system is to log out of the GUI completely, switch to a tty, log in there, and shut down the display manager. You can later on restart the display manager in order to get back to the equivalent of runlevel 5.
Or just put a 3 at boot options …
ex:
/etc/default/grub
…
GRUB_CMDLINE_LINUX="3"
I’m not sure there would be a difference between runlevel 3 and runlevel 5 in systemd-based distributions. Runlevel 3 corresponds to multi-user.target, but as I understand it, this will in turn trigger the starting of desktop.target.
I could of course be wrong… 
Huh? It is not that way, no.
I’ve used it multiple times, and it is included even in some guides I posted here.
Ex:
If you can spare a reboot go ahead and try it yourself … if you use the grub method described in the guide the edited options vanish after reboot/shutdown.
These changes are not permanent.
Just reboot.
with systemd based init systems:
systemctl poweroff
or
systemctl reboot
with the older init systems (it will work also on systemd systems):
shutdown -h now
to poweroff
shutdown -r now
to reboot
as long as you don’t disable the display manager
as in:
systemctl disable lightdm | gdm | whatever_other_display_manager
all will be as before after a reboot - the display manager will start again
The big four at this moment are RedHat, SuSE, Debian (Ubuntu, Linux Mint), and Archlinux (Manjaro).
Distrowatch is a great site to stay informed about the various distributions. They have a weekly column.
It is a 99.9% certainty that a distribution has a forum and documention, which is best viewed before taking action.
Along with Manjaro’s, there is the helpful archlinux wiki. Here’s the page on runlevel’s/targets.
There is a series about systemd at opensource·com. This particular one is, “Understanding systemd at startup on Linux” and discusses runlevels/targets.
With all but a few distributions (i.e., slackware), you’ll be getting to know systemd and its’ components. systemd started out as a replacement for sysV init system (PID 1), but is much more today. There are some stubs and aliases for commands to smooth the educational curve, but underneath it’s all systemd. As far as archlinux goes, it looks like telinit was removed in 2020.
There are two man pages that are good starting place for anything systemd:
- man systemd.index
- man systemd.directives
As mentioned by others, the commands, as shown, are not changing configuration files and are not permanent. Plus when you reboot, you can display the Grub Menu and Edit the kernel cmdline.
You mentioned gdm. That is Gnome’s display manager. I’m running XFCE, and lightdm is the display manager.
When I ran command 1 below, the display manager was also stopped.
One thing I wasn’t sure of, was the display manager the only difference between the two targets, so I executed commands 5 and 6 below, and it looks like it is. The graphical target is the multi-user plus the display manager. So perhaps only commands 7 and 8 are okay. Here again, should we be using display-manager or lightdm or gdm. Is there a difference
Ahhh, the answer to that last question. display-manager and lightdm or gdm would be the same thing because display-manager is symlink to the actual service, see 9 below.
1. systemctl isolate multi-user.target
2. systemctl isolate graphical.target
3. systemctl status display-manager
4. journalctl -b0 # Use to be syslog, now journal.
5. systemctl list-dependencies multi-user.target
6. systemctl list-dependencies graphical.target
7. systemctl stop display-manager (replace display-manager with gdm or lightdm)
8. systemctl start display-manager
9. stat $(locate display-manager) or stat /etc/systemd/system/display-manager.service
- Tip: When typing press Tab for command completion (hints) at any point.
- Note: You have 7 virtual terminals (Ctrl-Alt-F1 thru F6, with F7 being the graphical terminal.
Good luck on your certification program!
yes n fact I am using XFCE not Gnome (which I didn’t know to associate with “gdm” found the hieroglyphs of the cli) so good catch. Thanks.