[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: does /etc/profile get sourced also when .profile exists ?

From: Greg Wooledge
Subject: Re: does /etc/profile get sourced also when .profile exists ?
Date: Mon, 26 Jul 2021 16:46:46 -0400

On Mon, Jul 26, 2021 at 03:54:53PM -0400, Jeffrey Walton wrote:
> One case to watch out for is Systemd (maybe it was present in SysV,
> too)... Systemd does not source /etc/profile, even on systems like
> CentOS.

Well, I mean, neither does sysvinit.  They're not shells, so why would
either one of them read /etc/profile?

> The significance is, Red Hat and CentOS say to setup Software
> Collections (SCL) in /etc/profile. So you install Apache, Python and
> PHP from SCL and you enable the updated packages from /etc/profile per
> the vendor. But Systemd does not follow the vendor's practices.

Are you talking about login shells, here?

> It
> uses random paths, and uses the wrong version of the software when it
> executes your scripts.

Oh, it sounds like you're talking about *services* (daemons).

Daemons do not read /etc/profile either.  I don't know what Red Hat
instructions you were reading, but either those instructions were
incorrect, or you misunderstood what they're saying.

Daemons under systemd are configured by unit files, which are declarative
text files that give instructions for how to start the daemon.  Daemons
do NOT read /etc/profile, and they never have, not even under the days
of sysvinit.  /etc/profile is for interactive login shells.

If you have (let's say) two separate versions of PHP-fpm installed,
and you want to use the one in /opt/frobozz/bin instead of the one in
/usr/sbin, then you would change the systemd unit file to run
/opt/frobozz/bin/php-fpm instead of /usr/sbin/php-fpm.

Nothing you do in /etc/profile has any effect on this, nor should it.

Now, you also used the word "scripts", which is a strange word in this
context.  I'm not sure what you mean by it.

If you're still writing a shell script to launch your service, and then
telling systemd to run your shell script, which launches your service,
then (a) you're doing it wrong, and (b) your shell script *still* does
not read /etc/profile, because /etc/profile is only for interactive
shells.  Not scripts.

If you really need a shell script to launch your service, and you want
to configure a PATH variable so that it runs the correct version of things
where you have multiple copies, then simply set the PATH variable inside
the script.  That's how it should be done.

Do not rely on some external file like /etc/profile and hope that it
will contain a proper PATH for your service.  It won't be read, and even
if it were read, it would have the proper PATH for an interactive user,
not for your service.

If you don't want to set PATH inside your script, another reasonable
course of action would be to set it in the systemd unit file that
runs your script.  This is acceptable.

Of course, the best answer is to drop the intermediary script, and let
the systemd unit file invoke your service directly, with or without
a PATH variable in the environment.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]