How can I make a Red Hat Software Collection persist after a reboot/logout?

Solution Verified - Updated -


  • Red Hat Enterprise Linux 6.2 EUS and later
  • Red Hat Enterprise Linux 7.0 and later
  • Red Hat Software Collections 1.0 and later


  • When I reboot or logout of my machine, all my enabled software collections are disabled, and do not persist.


Enabling SysV init services to persist after a reboot

The first problem is making SysV services like MySQL daemon from RHSCL enabled after rebooting -- this task is pretty straightforward; you only need to enable the correct SysV service. For example, mysql55 collection creates a new SysV init script called mysql55-mysqld under /etc/init.d, which you can handle the same as another SysV service files, only using the whole prefixed name. For example:

# chkconfig mysqld off
# chkconfig mysql55-mysqld on

A daemon from Red Hat Software Collections should now be started after next reboot, instead of daemon from the core-system. However, software collections will be properly enabled only for daemon processes, not for processes that interact with these daemons and are run by users (like mysql CLI, mysqldump utility, etc.). The usual way to enable software collections for whole sessions is to run a new bash wrapped with "scl enable" call, for example like that:

$ scl enable mysql55 bash

Enabling userspace environment automatically after logout/reboot

The second problem is enabling software collections for users after reboot, i.e. to allow them to work with a collection without calling "scl enable" all the time. This task is a bit more tricky, since Software collections weren't primarily design for such usage. The following is considered to be a work-around only, because we don't have a supported way to do it correctly now.

How the software collection concept works: The difference between running python from a software collection and core system's python is only in environment variables defined at a time you run python command. These variables are set using "scl enable python33 ..." call, which basically executes a bash script located in /opt/rh/python33/enable.

Generally, you are able to execute bash scripts that change environment of all users using files under /etc/profile.d/, so what you need is to enable desired collections here. The tricky part comes when you realize, that pure running "scl enable ..." in /etc/profile.d/ doesn't work, because you cannot influence environment of the parent's process. For such a task we'd have to use a feature, that has been added into scl-utils recently, and is part of RHEL-6 since scl-utils-20120927-9.el6:

With that package, you can enable userspace environment automatically by creating a new file under /etc/profile.d with the following content (example for python33 collection):

$ cat /etc/profile.d/
source scl_source enable python33

With such file all users will have python 3.3 collection enabled by default in shell.

NOTE: However, there is a side effect with this approach in that you cannot disable the collections thereafter. Also, shebang in the script affects which interpreter will be used.

This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.


The script above is syntactically and semantically wrong.
It shoud be:

source /opt/rh/python33/enable
export X_SCLS="`scl enable python33 'echo $X_SCLS'`"

Can you elaborate what is wrong with the script in the article? I've been using that exact form for multiple applications installed from Software Collections and it works like a charm, it also properly sets the X_SCLS variable.

cat /etc/init.d/httpd24-httpd

We have to re-enable SCL environment, because /sbin/service clears almost all environment variables. Since X_SCLS is cleared as well, we lose information about other collections enabled.

. /opt/rh/httpd24/service-environment for sclname in $HTTPD24_HTTPD_SCLS_ENABLED ; do . /opt/rh/$sclname/enable export X_SCLS="$X_SCLS $sclname" done

Thanks for pointing it out. Is it possible to update the article?
Also can you explain the purpose of X_SCLS env var?

For additional information, about Software Collections please view our Packaging Guide:


Does this still apply in 2020? I would like to have php 7.2 scl enabled on boot disallowing the native php install which is 5.*.

I'm curious about the '#!/bin/bash' line. If I look at any of the other /etc/profile.d/*.sh scripts that are delivered with RHEL (e.g.,,, etc.) they do not have a hash bang at the top and when I have written my own .sh files for profile.d I have not included it. Does this just get ignored or does it have a purpose here. Doesn't /etc/profile and /etc/bashrc just source these files with '.'?