Essential Tools practice questions

cal

Why it fails: Shows calendar, not current date/time.

timedatectl

Why it fails: Shows time and date but not in that exact format.

date -Iseconds

Why it fails: date -Iseconds outputs date and time in ISO 8601 format (e.g., 2023-10-05T14:30:00+00:00) with a 'T' separator and timezone, not the requested 'YYYY-MM-DD HH:MM:SS' format.

hwclock

Why it fails: Displays hardware clock, not current date/time.

fdisk -l /dev/sda

Why it fails: fdisk -l /dev/sda is wrong for checking disk space usage because it only displays the partition table, including start/end sectors, partition types, and sizes of each partition in bytes. It does not query the filesystem or report how much space is actually consumed or available on any mounted filesystem, so it cannot show usage.

parted /dev/sda print

Why it fails: parted /dev/sda print is wrong for this purpose because it prints the partition layout, such as partition numbers, start and end points, sizes, and file system types, but it never examines the filesystem to report used or free space. Like fdisk, it is a partition management tool, not a filesystem usage reporting tool, so it gives capacity, not consumption.

The file is empty.

Why it fails: An empty file would have a size of 0 bytes in the ls -l output. The /etc/shadow file contains password hashes and account-expiration data, one line per user, so it is normally many bytes and clearly non-empty. Even if the file were empty, it would still show a permission string; emptiness is an attribute of file size, not of access permissions, so this does not explain the observed permission display.

The file is a symbolic link.

Why it fails: A symbolic link appears with an 'l' as the first character in the long listing, and its permissions are shown as lrwxrwxrwx with a '->' pointing to its target. The /etc/shadow file is a regular file, as evidenced by the '-' type character in its ls -l output. Also, symlink permissions are generally ignored by the kernel; access is determined by the target file's permissions, so calling it a symlink would not explain why root can read it.

The file is a character device.

Why it fails: A character device node would show a 'c' as the first character in ls -l, would normally reside in /dev, and would have major and minor device numbers instead of a byte size. The /etc/shadow file is a regular file in /etc, not a device node, and cannot be created by mknod on a standard filesystem. Character devices correspond to hardware or virtual serial/terminal devices, not to password-storage files, so this option does not explain the listing.

The configuration file is missing. Copy config.ini to /root.

Why it fails: The configuration file is not missing; it already exists in /opt/scripts, which is why the script runs correctly when launched manually. Copying config.ini to /root might accidentally match cron's default working directory, but that only masks the symptom and leaves the script dependent on wherever cron happened to start. The proper fix is to reference the file as /opt/scripts/config.ini (or explicitly cd into the script's directory) so the script always finds it regardless of cron's environment. Copying configuration files can additionally cause stale or incorrect settings to be used later.

The cron job runs as a different user. Change the cron job to run as the developer's user.

Why it fails: The cron job is already running as root; changing it to run as the developer's user does not alter cron's minimal PATH or its default working directory, which are the actual failure points. The developer user might not even have read access to /opt/scripts or the encryption keys the backup script uses. Since root is a privileged account, command resolution is no better with the developer identity — relative paths still fail. The root cause is the environment cron provides, not the user account under which the job runs.

The script is not executable. Run chmod +x /opt/scripts/backup.sh.

Why it fails: The script already executes successfully when run manually, so the executable bit is already set; if it were not, the manual run would fail immediately. Many cron entries also invoke scripts with an explicit interpreter such as /bin/sh /opt/scripts/backup.sh, which bypasses the need for the execute permission entirely. Therefore running chmod +x would have no effect on the cron failure mode. The real issue is cron's restricted PATH and a different current working directory, both of which execute permissions cannot alter.

The home directory path in /etc/passwd has a typo. Change it to /home/john.

Why it fails: The home directory field in /etc/passwd simply holds the path string; it is not a symlink or a mount point. You can verify with `grep john /etc/passwd`, which will show `/home/john` exactly. A typo in that field would cause the shell to look in a nonexistent directory, but here the path is correct, so editing it would not resolve the reported 'No such file or directory' error.

The home directory is missing the .bashrc file. Copy default files from /etc/skel.

Why it fails: The `.bashrc` file is a user-specific shell configuration script that resides *inside* the home directory; its presence or absence does not affect the home directory's existence or accessibility. The kernel's path resolution only cares about the directory itself, not its contents. Skipping `/etc/skel` is irrelevant here—those defaults are only used when creating new users with `useradd`; copying them into an existing home directory would not fix an ownership or permission problem.

The user's shell is invalid. Change shell to /bin/bash.

Why it fails: The login shell is defined in the `/etc/passwd` shell field, and you can verify it with `grep john /etc/passwd` which shows `/bin/bash`. An invalid shell entry would cause a different symptom, such as 'User's shell not found' or a failed login at the PAM stage, not a filesystem-level 'No such file or directory' when accessing the home directory. Since the shell is already `/bin/bash`, changing it would have no effect on the reported problem.

Copy the file to a temporary location, edit, and then overwrite

Why it fails: This method preserves a single pre-edit snapshot at most, but once you overwrite the original, the temporary copy is the only fallback. If the edit is wrong and the temp file is lost, moved, or on a different filesystem, you cannot roll back. It also records no metadata such as timestamp, author, or the exact set of changes, so it is not a traceable change-management process.

Use 'ls -l' to check the file size before and after editing

Why it fails: The `ls -l` output only shows metadata like size and modification time; it says nothing about which lines or values actually changed. Two different contents can have the same size, and the same content can differ in size due to whitespace, so size is not a content checksum. It gives you no ability to revert or compare previous states, making it useless for ensuring correct configuration.

Edit the file in place with a backup using 'sed -i.bak'

Why it fails: `sed -i.bak` creates a single `.bak` copy of the original before applying the substitution, but it does not record what was changed or produce a series of versions. You get only one previous state, not per-edit history, so if you make multiple edits over time you cannot revert to an intermediate state. The backup also lacks metadata about when and why the change was made, which is essential for auditing configuration changes.

lvextend -L +100%FREE /dev/vg/lv && resize2fs /dev/vg/lv

Why it fails: The `-L` flag expects a concrete size suffix such as `+10G` or `+500M`; it cannot accept a percentage expression like `+100%FREE`, so this lvextend invocation will be rejected by LVM before any change occurs. Even if the extension somehow succeeded, `resize2fs` cannot resize an XFS filesystem and would fail with an unsupported filesystem error. The correct approach uses `-l +100%FREE` for the LVM extension and `xfs_growfs` for the XFS filesystem growth.

lvextend -l +50%FREE /dev/vg/lv && xfs_growfs /dev/vg/lv

Why it fails: Using `-l +50%FREE` allocates only half of the available free physical extents to the logical volume, leaving the volume group still containing unallocated space and the LV smaller than it should be. Consequently, `xfs_growfs` will only enlarge the filesystem to fill that half-grown volume, so the administrative goal of using all free space is not achieved. A complete expansion requires `+100%FREE` (or an exact number of extents) so that no free space remains in the volume group.

lvresize -L +100%VG /dev/vg/lv && resize2fs /dev/vg/lv

Why it fails: The `-L` option with `+100%VG` is doubly invalid: percentage expressions belong with `-l` (for extents), and a percentage of the VG refers to the entire volume group's total size rather than to the free space within it, so even conceptually it does not allocate all remaining space. In addition, `resize2fs` is the wrong filesystem tool for XFS, which requires `xfs_growfs`. The correct command would be `lvresize -l +100%FREE /dev/vg/lv` followed by `xfs_growfs /dev/vg/lv`.

zgrep file.gz

Why it fails: zgrep is designed for searching compressed files with regular expressions: it decompresses a gzip file on the fly and passes the stream to grep, printing only lines that match the given pattern. Running 'zgrep file.gz' incorrectly treats 'file.gz' as the search pattern (with stdin as input) instead of the target file, and even with a proper pattern, zgrep would never show the complete file contents—only matching lines.

gunzip file.gz

Why it fails: gunzip performs permanent decompression: it reads the compressed file, writes the uncompressed data to a new file without the .gz suffix, and then removes the original .gz file. After running 'gunzip file.gz', the archive is gone, replaced by a regular file 'file' on disk—you are not just viewing contents but modifying the filesystem, which defeats the purpose of inspection.

gzip -d file.gz

Why it fails: gzip -d is exactly equivalent to gunzip (the -d flag means 'decompress'), so it also writes the decompressed output to disk and deletes the source .gz file. It will overwrite any existing file with the same name, which can be destructive; it does not stream to stdout, so it is not a viewing tool.

find /var -type f -size +100M -mtime -7 -ls | sort -k7 -n

Why it fails: -ls output has size in bytes, not human-readable, and sort -n may not order correctly with different units.

find /var -type f -size +100M -mtime -7 -exec ls -lh {} \; | sort -k5 -h

Why it fails: -exec option spawns ls for each file, but sorting may not work as expected because the output is interleaved and sort -k5 may not match the size column reliably.

find /var -type f -size +100M -mtime -7 -printf '%s %p\n' | sort -n -r | head -20

Why it fails: Output is numeric bytes, not human-readable.

Run 'command', press Ctrl+Z, then type 'bg' and logout

Why it fails: Same issue: SIGHUP will terminate background jobs on logout.

Run 'command &' and then exit

Why it fails: & runs in background but SIGHUP will terminate it on logout.

Run 'command & disown' then logout

Why it fails: disown removes job from shell's job table but does not protect against HUP if nohup not used? Actually disown can prevent SIGHUP if done correctly, but it's less reliable than nohup.

inotifywait -m /var/log

Why it fails: `inotifywait -m /var/log` monitors file system events in real-time; it does not show current open file descriptors.

lsof +D /var/log | grep -E '(REG|DIR).*[0-9]+[w]'

Why it fails: `lsof +D /var/log | grep -E '(REG|DIR).*[0-9]+[w]'` attempts to filter for write descriptors, but the pattern incorrectly expects the write mode after the file type. In `lsof` output, the mode is in the FD column before the type, so this grep does not work.

fuser -v /var/log

Why it fails: `fuser -v /var/log` shows processes using files, not file descriptors. It indicates access mode (e.g., 'F' for write) but does not list individual descriptors.

The 'notifempty' directive may cause delays in rotation.

Why it fails: The `notifempty` directive does not affect rotation timing at all; it simply tells logrotate to skip the rotation step when the log file is empty. The interval is controlled by directives such as `hourly` or `weekly`, and delays are normally associated with `delaycompress`, not `notifempty`. Therefore, this option describes a non-existent problem.

The 'compress' directive uses bzip2 by default, which is not installed.

Why it fails: logrotate's `compress` directive uses gzip by default, not bzip2; you would need an explicit `compresscmd /bin/bzip2` to switch. Additionally, gzip is part of the base RHEL installation, so a missing compression tool is highly unlikely. Because neither bzip2 nor its presumed absence is relevant, this cannot be the reason the rotation failed.

The 'weekly' directive uses cron syntax incorrectly.

Why it fails: `weekly` is a standard logrotate frequency keyword and does not use cron syntax. The logrotate program interprets `weekly` directly by checking the timestamp in its own state file to determine whether more than seven days have elapsed. Thus, the configuration is valid, and this option misidentifies a correct directive as the cause of failure.

The -user root argument is invalid; it should be -uid 0.

Why it fails: The -user root expression is perfectly valid in find; it matches files owned by the user named root, which is synonymous with UID 0. GNU find resolves user names via getpwnam(), so -user root is the conventional and portable form. Specifying -uid 0 is equivalent but not required, and changing this argument would have no effect on the outcome described in the scenario.

The find command requires the -type f argument to search for files only.

Why it fails: The find utility searches directories and prints all entries that match the given predicates, whether they are regular files, directories, symlinks, or device nodes. Adding -type f would restrict results to only regular files, but its absence does not cause an error or suppress output. The command already produces many default results; the issue is the modifier on -mtime, not the absence of a file-type filter.

The -mtime 0 argument is incorrect; it should be -mtime -1 to find files modified in the last 24 hours.

Why it fails: The correct issue is that -mtime 0 matches files whose age rounds to exactly 0 days (i.e., between 24 and 48 hours old, depending on rounding), not files modified in the last 24 hours. To capture files with a modification time less than one day ago, the proper expression is -mtime -1. The minus sign is crucial because it indicates 'less than 1 day old', whereas a bare 0 selects files exactly 24 hours ago, which typically matches no files unless the timestamps align precisely.

Set the service to be started by the network target using systemctl add-wants.

Why it fails: systemctl add-wants is not a recognized systemctl subcommand, so this command would fail outright. The proper way to express a boot-time dependency is to set WantedBy=network.target (or, more typically, WantedBy=multi-user.target) in the service's [Install] section and then run systemctl enable; systemctl will create the appropriate symlink in the corresponding .wants directory. Additionally, network.target is a passive target that reflects network configuration state rather than a desired boot target, making it a poor choice for enabling httpd.

Run systemctl start httpd after enabling it.

Why it fails: Running systemctl start httpd after enabling it will start the service for the current session, but it does not repair an invalid or missing [Install] section. The systemctl enable step would already have failed if the unit file lacks an [Install] section, because enable works by reading WantedBy= to create persistent symlinks. Starting the service manually only calls start, which never writes boot-time activation links; it is useful only as an immediate action, and the correct boot-persistence action is to verify and fix the [Install] section and then enable.

Create a symlink in /etc/rc.d/rc3.d/ for the service.

Why it fails: Creating a symlink in /etc/rc.d/rc3.d/ is a SysVinit-era technique that systemd ignores on RHEL 7 and later; those directories are legacy compatibility shims for rc scripts, not for systemd unit files. The correct equivalent would be to place a symlink in /etc/systemd/system/multi-user.target.wants/ pointing to the httpd.service unit, but the supported method is systemctl enable, which handles the symlink and unit dependency configuration automatically. Manually editing rc3.d does not create the .wants dependency systemd requires, so the service will not be launched at boot.

tar -cjvf /srv/reports /backup/reports.tar.bz2

Why it fails: Here the argument order is reversed: /srv/reports becomes the name of the archive being created and /backup/reports.tar.bz2 becomes the path to archive. That would write an archive file literally named reports inside the /srv directory and try to add a nonexistent backup path, producing an error and no usable backup.

tar -xjvf /backup/reports.tar.bz2 /srv/reports

Why it fails: The -x flag extracts an archive instead of creating one, so this command would attempt to unpack files from /backup/reports.tar.bz2 into the current working directory. Since the archive does not exist yet, tar exits with an error. Extraction is the opposite operation of what the administrator was asked to perform.

tar -tzvf /backup/reports.tar.bz2 /srv/reports

Why it fails: The -t flag tells tar to list the table of contents of an existing archive rather than create one. Running this against a path that has not yet been archived produces an error or merely lists the archive's contents, and nothing is written to /backup. It fails the core requirement of creating a compressed archive of the directory.

find /var/log -amin -120

Why it fails: This command is incorrect because `-amin` measures access time (`atime`), not modification time. Access time is updated whenever a file is read, opened, or otherwise accessed, which can happen without any change to the file's content. On modern Linux systems with `relatime` (or `noatime`), accesses may not even update atime reliably, so files modified in the last 120 minutes could be excluded while files merely read are included.

find /var/log -mtime -0.08

Why it fails: The `-mtime` predicate works in 24-hour day increments, not minutes. Although GNU find technically accepts fractional values, `-0.08` is interpreted as a tiny fraction of a day (about 1.9 hours) and is rounded or handled in a way that does not reliably represent a 120-minute window. More importantly, this syntax is non-portable, ambiguous, and not the intended method for fine-grained sub-day searches—`-mmin` exists specifically for this purpose.

find /var/log -cmin -120

Why it fails: The `-cmin` predicate checks inode change time (`ctime`), which is updated whenever file metadata—such as permissions, ownership, link count, or name—changes, not necessarily when the file's content is modified. Even a simple `chmod` or `chown` updates ctime, so this command would return files that were never modified in the last two hours. It is therefore not equivalent to looking for content modification, unlike `-mmin`.

set

Why it fails: The `set` builtin, when invoked without arguments, prints all shell variables and functions for the current shell, which is a verbose dump that is not a focused diagnostic for a specific issue like lost `ls` color output. Although `LS_COLORS` might appear in that listing if it is set, finding it would require grepping through countless lines of variables, and `set` also does not distinguish between exported and non-exported variables. For a quick check, it is far less direct than listing the environment.

declare

Why it fails: The `declare` builtin (synonym `typeset`) is primarily used to declare variables and set attributes, and with no arguments it lists the current shell's variables plus their attributes, much like `set` but with some annotations. It is not the standard tool for inspecting environment variables that child processes like `ls` would see, and it does not indicate whether a variable was exported, so even if `LS_COLORS` is visible, it may not be in the environment. This makes it an unsuitable first diagnostic for color output problems.

alias

Why it fails: The `alias` command only displays shell aliases, such as `ls='ls --color=auto'`, not environment variables like `LS_COLORS`, so it is not the right tool to inspect the data that `ls` actually reads from the environment. An alias could be the cause if it was removed or defined without `--color`, but the user's issue is specifically about missing color output, which is governed by both the alias/option and the `LS_COLORS` variable. To rule out environmental causes, one must check `env` rather than `alias`.

netstat -tulpn

Why it fails: netstat -tulpn is the classic tool for displaying listening sockets, but it belongs to the deprecated net-tools package, which is not installed by default in modern RHEL systems. Even on systems where it exists, the command combines TCP and UDP listeners (-u) and offers no advantage over ss, while pulling in a legacy dependency that may be missing in a minimal or security-hardened environment. In a RHEL administration context, relying on netstat is therefore a portability and compliance risk, not a correct first-line diagnostic.

nmap -sT localhost

Why it fails: nmap -sT localhost is an external TCP connect scan that probes open ports from the perspective of a network client, not a local socket diagnostic. It performs a full three-way handshake, which creates connection records in system logs and may trigger intrusion detection, and it only tells you whether a port is reachable, not which process owns the listening socket or whether it is actually in the LISTEN state. Since the task is to 'list all' local TCP listeners with their processes, nmap cannot provide the required PID or program name and is the wrong tool entirely.

lsof -i TCP:1-65535

Why it fails: lsof -i TCP:1-65535 lists open files related to TCP sockets across the entire port range, but it does not restrict output to listening sockets—you will also see established connections, TIME-WAIT sockets, and other TCP file descriptors. To isolate listeners you would need an extra filter such as -sTCP:LISTEN, and lsof's file-descriptor-centric view makes the output noisier and less directly focused than ss. Additionally, without sudo, lsof hides process details for sockets owned by other users, and the tool may not be installed by default on all RHEL systems.

man -k color

Why it fails: man -k color searches only the man-db whatis database, which stores just the one-line NAME summary from each manual page, not the full text. It returns a list of pages whose title or synopsis mentions 'color', but the ls manual page's NAME section may not even contain 'color', since the color option is discussed in the OPTIONS section. You would still have to open a page and then search inside it, so this command does not directly reveal where --color is documented.

man ls | grep color

Why it fails: Piping man output to grep is unreliable because raw man pages, when rendered on a terminal, contain control sequences such as backspaces and underlining for emphasis. grep interprets those escape characters as part of the lines, so matches may be missed or the output becomes cluttered with formatting artifacts. Additionally, grep prints entire lines, but man page descriptions are wrapped and may span multiple lines, so you get only fragments without context. Unlike the pager's interactive / search, grep cannot let you jump between matches.

man color

Why it fails: This command asks man to display a manual page whose name is literally 'color', meaning it will look for a file like color.1, color.2, or similar in the manual page search path. No such standalone page exists because the color options for ls are documented within the ls(1) manual page itself. If no match is found, man will error out with something like 'No manual entry for color', possibly suggesting 'apropos color', but that still won't show you where in the ls page the option is explained.

kill -15 3456

Why it fails: SIGTERM (signal 15) is the default and polite termination request; it asks process 3456 to exit cleanly and run its cleanup routines, but the process has already ignored this signal. A hung process that is stuck in an uninterruptible sleep or a busy loop may never return to user space to handle SIGTERM, so the request remains pending and the process survives.

kill -19 3456

Why it fails: SIGSTOP (signal 19) is a job-control signal that halts process 3456's execution immediately, leaving it in a stopped state (similar to Ctrl+Z) but still present in memory and the process table. It does not remove the process; it can be resumed with SIGCONT (signal 18), so it stops the hang temporarily but does not fulfill the requirement to terminate the process.

kill -1 3456

Why it fails: SIGHUP (signal 1) originally notifies a process that its controlling terminal has hung up, and many daemons interpret it as an instruction to reload configuration files. For a process that is already hung, SIGHUP is often caught by a handler or ignored altogether, so it neither guarantees termination nor clears the stuck state, leaving the administrator without a resolved process.