12.2. Hints on Special Software Packages

12.2.1. Package bash and /etc/profile

  1. /etc/profile

  2. ~/.profile

  3. /etc/bash.bashrc

  4. ~/.bashrc

Users can make personal entries in ~/.profile or in ~/.bashrc. To ensure the correct processing of these files, it is necessary to copy the basic settings from /etc/skel/.profile or /etc/skel/.bashrc respectively into the home directory of the user. It is recommended to copy the settings from /etc/skel following an update. Execute the following shell commands to prevent the loss of personal adjustments:

mv ~/.bashrc ~/.bashrc.old
cp /etc/skel/.bashrc ~/.bashrc
mv ~/.profile ~/.profile.old
cp /etc/skel/.profile ~/.profile

The personal adjustments then need to be copied back from the files *.old.

12.2.2. cron Package

The cron tables are now located in /var/cron/tabs. /etc/crontab serves as a system-wide cron table. Enter the name of the user who should run the command directly after the time table (see File 12.1. “Example of an Entry in /etc/crontab”, here root is entered). Package-specific tables, located in /etc/cron.d, have the same format. See man cron.

Example 12.1. Example of an Entry in /etc/crontab

1-59/5 * * * * root test -x /usr/sbin/atrun && /usr/sbin/atrun

/etc/crontab cannot be processed with crontab -e. It must be loaded directly into an editor, modified, then saved.

A number of packages install shell scripts to the directories /etc/cron.hourly, /etc/cron.daily, /etc/cron.weekly, and /etc/cron.monthly, whose instructions are controlled by /usr/lib/cron/run-crons. /usr/lib/cron/run-crons is run every fifteen minutes from the main table (/etc/crontab). This guarantees that processes that may have been neglected can be run at the proper time.

The daily system maintenance jobs have been distributed to various scripts for reasons of clarity. Apart from aaa_base, /etc/cron.daily contains, for instance, the components backup-rpmdb, clean-tmp, or clean-vi.

12.2.3. Log Files: the Package logrotate

There are a number of system services (daemons), which, along with the kernel itself, regularly record the system status and specific events to log files. This way, the administrator can regularly check the status of the system at a certain point in time, recognize errors or faulty functions, and troubleshoot them with pinpoint precision. These log files are normally stored in /var/log as specified by FHS and grow on a daily basis. The logrotate package helps control the growth of these files.

12.2.3.1. Changing to logrotate

The old settings listed below are adopted when updating from a version older than SUSE LINUX 8.0:

  • Entries from /etc/logfile not associated with a particular package are moved to /etc/logrotate.d/aaa_base.

  • The variable MAX_DAYS_FOR_LOG_FILES from the former rc.config file is mapped as dateext and maxage in the configuration file. Refer to man logrotate.

12.2.3.2. Configuration

Configure logrotate with the file /etc/logrotate.conf. In particular, the include specification primarily configures the additional files to read. SUSE LINUX ensures that individual packages install files in /etc/logrotate.d (e.g., syslog or yast).

Example 12.2. Example for /etc/logrotate.conf

# see "man logrotate" for details
# rotate log files weekly
weekly

# keep 4 weeks worth of backlogs
rotate 4

# create new (empty) log files after rotating old ones
create

# uncomment this if you want your log files compressed
#compress

# RPM packages drop log rotation information into this directory
include /etc/logrotate.d

# no packages own lastlog or wtmp - we'll rotate them here
#/var/log/wtmp {
#    monthly
#    create 0664 root utmp
#    rotate 1
#}

# system-specific logs may be also be configured here.

logrotate is controlled through cron and it is called daily by /etc/cron.daily/logrotate.

[Important]Important

The create option reads all settings made by the administrator in /etc/permissions*. Ensure that no conflicts arise from any personal modifications.

12.2.4. Man Pages

For some GNU applications (such as tar) the man pages are no longer maintained. For these commands, use the --help option to get a quick overview or the info pages, which provide more in-depth instructions. info is GNU's hypertext system. Read an introduction to this system by entering info info. Info pages can be viewed either via Emacs, by entering emacs -f info, or directly in a console with info. You can also use tkinfo, xinfo, or the SUSE help system to view info pages in a convenient way.

12.2.5. The Command ulimit

With the ulimit (user limits) command, it is possible to set limits for the use of system resources and to have these displayed. ulimit is especially useful for limiting the memory available for applications. With this, an application can be prevented from using too much memory on its own, which could bring the system to a standstill.

ulimit can be used with various options. To limit memory usage, use the options listed in Table 12.1. “ulimit: Setting Resources for the User”.

Table 12.1. ulimit: Setting Resources for the User

-mmaximum size of physical memory
-vmaximum size of virtual memory
-smaximum size of the stack
-cmaximum size of the core files
-adisplay of limits set

System-wide settings can be made in /etc/profile. There, creating core files must be enabled, needed by programmers for debugging. A normal user cannot increase the values specified in /etc/profile by the system administrator, but he can make special entries in his own~/.bashrc.

Example 12.3. ulimit: Settings in ~/.bashrc

# Limits of physical memory:
ulimit -m 98304
 
# Limits of virtual memory:
ulimit -v 98304

Details of memory must be specified in KB. For more detailed information, see man bash.

[Important]Important

Not all shells support ulimit directives. PAM (for instance, pam_limits) offers comprehensive adjustment possibilities if you depend on encompassing settings for these restrictions.

12.2.6. The free Command

The free command is somewhat misleading if your goal is to find out how much RAM is currently being used. The relevant information can be found in /proc/meminfo. These days, users, who have access to a modern operating system such as Linux, should not really need to worry much about memory. The concept of available RAM dates back to before the days of unified memory management. The slogan free memory is bad memory applies well to Linux. As a result, Linux has always made the effort to balance out caches without actually allowing free or unused memory.

Basically, the kernel does not have direct knowledge of any applications or user data. Instead, it manages applications and user data in a page cache. If memory runs short, parts of it will be either written to the swap partition or to files, from which they can initially be read with the help of the mmap command (see man mmap).

Furthermore, the kernel also contains other caches, such as the slab cache, where the caches used for network access are stored. This may explain differences between the counters in /proc/meminfo. Most, but not all of them, can be accessed via /proc/slabinfo.

12.2.7. The File /etc/resolv.conf

Domain name resolution is handled through the file /etc/resolv.conf. Refer to Section 14.6. “DNS — Domain Name System” about this.

This file is updated by the script /sbin/modify_resolvconf exclusively, with no other program having permission to modify /etc/resolv.conf directly. Enforcing this rule is the only way to guarantee that the system's network configuration and the relevant files are kept in a consistent state.

12.2.8. Settings for GNU Emacs

GNU Emacs is a complex work environment. More information is available at http://www.gnu.org/software/emacs/. The following sections cover the configuration files processed when GNU Emacs is started.

On start-up, Emacs reads several files containing the settings of the user, system administrator, and distributor for customization or preconfiguration. The initialization file ~/.emacs is installed to the home directories of the individual users from /etc/skel. .emacs, in turn, reads the file /etc/skel/.gnu-emacs. If a user wants to customize the program, the .gnu-emacs should be copied to the home directory and the desired settings should be specified there:

cp /etc/skel/.gnu-emacs ~/.gnu-emacs

.gnu-emacs defines the file ~/.gnu-emacs-custom as custom-file. If users make settings with the customize options, these are saved to ~/.gnu-emacs-custom.

With SUSE LINUX, the emacs package installs the file site-start.el in the directory /usr/share/emacs/site-lisp. The file site-start.el is loaded before the initialization file ~/.emacs. Among other things, site-start.el ensures that special configuration files distributed with Emacs add-on packages (such as psgml) are loaded automatically. Configuration files of this type are located in /usr/share/emacs/site-lisp, too, and always begin with suse-start-. The local system administrator can specify system-wide settings in default.el.

More information about these files is available in the Emacs info file under Init File: info:/emacs/Init File. Information about how to disable loading these files (if necessary) is also provided at this location.

The components of Emacs are split in several packages:

  • The base package emacs.

  • Usually, emacs-x11 should be installed. This package contains the program with X11 support.

  • emacs-nox contains the program without X11 support.

  • emacs-info: online documentation in info format.

  • emacs-el contains the uncompiled library files in Emacs Lisp. These are not required at run-time.

  • Numerous add-on packages that can be installed if needed: emacs-auctex (for LaTeX), psgml (for SGML and XML), gnuserv (for client and server operation), and others.