4

I got some trouble in order to understand how profile.d works. As far as I know, the scripts get executed whenever a user logs in. Currently, I'm running CentOS 6.10 on my Server and got the following weird behavior:

In /etc/profile.d I got a script called logchk.sh which is meant to send an email to the admin email address via /bin/mail. If someone logs in via ssh user@serveradress this script is properly executed and the email is sent. However, it depends on the login method if the script is executed or not. What works is the following

  • ssh user@serveradress regardless of the host system regardless of the user
  • git pull user@repoadress does trigger the e-mail script but only for some users, regardless of the host system

What doesn't work is the following

  • git pull user@repoadress for some users
  • connecting via filezilla using ssh as protocol

So depending on who is connecting to the server, git pull or FileZilla does not trigger the script while for other users the script is triggered. All users use the bash shell and the behavior is the same regardless if the user has root rights or not.

So in summary I don't understand why the script is triggered for some users and for others it isn't since it's a global configuration. If anyone could provide me with some detail about when exactly the scripts in /etc/profile.d get triggered, I would be happy.

2
  • Could it be that your script fails in some cases? Maybe it relies on some PATH being set? Also, in openSUSE /etc/profile is responsible for executing the scripts in /etc/profile.d, so you could reduce your question to: "When exactly does /etc/profile get executed?"
    – U. Windl
    Jan 28, 2023 at 20:26
  • I think PATH shouldn't be the issue and yes indeed it depends on /etc/profile
    – CrownUpKid
    Jan 29, 2023 at 12:19

1 Answer 1

6

All about bash

Let's start with this bit from the bash man page:

When bash is invoked as an interactive login shell, or as a non- interactive shell with the --login option, it first reads and executes commands from the file /etc/profile, if that file exists. After reading that file, it looks for ~/.bash_profile, ~/.bash_login, and ~/.profile, in that order, and reads and executes commands from the first one that exists and is readable. The --noprofile option may be used when the shell is started to inhibit this behavior.

[...]

When an interactive shell that is not a login shell is started, bash reads and executes commands from ~/.bashrc, if that file exists. This may be inhibited by using the --norc option. The --rcfile file option will force bash to read and execute commands from file instead of ~/.bashrc.

And also:

Bash attempts to determine when it is being run with its standard input connected to a network connection, as when executed by the historical remote shell daemon, usually rshd, or the secure shell daemon sshd. If bash determines it is being run non- interactively in this fashion, it reads and executes commands from ~/.bashrc, if that file exists and is readable. It will not

All about ssh

When you ssh into a remote server without specifying a command...

ssh [email protected]

...this starts a login shell, so you get /etc/profile services.

On the other hand, when you run a command -- either explicitly, as in ssh [email protected] somecommand, or implicitly, by using git or rsync or some other tool that operates over an ssh connection -- you start a non-interactive shell, so you don't get /etc/profile services. As we see from the third man page excerpt above, bash will still read your ~/.bashrc file, despite it being a non-interactive shell.

All about dotfiles

The specific configuration of dotfiles I'm referring to in this section is specific to Fedora (and probably most RHEL derivatives), but may also hold true for other distributions.

When you start a login shell, bash reads /etc/profile. This script typically contains code to source the scripts from /etc/profile.d. So when someone runs ssh user@serveraddress, this start an interactive login shell, which we know causes bash to read /etc/profile, hence it runs your logchk.sh script.

When you start an interactive non-login shell or when you start a non-interactive shell via a network connection like ssh, bash reads your ~/.bashrc file. The default .bashrc file created for user accounts include:

if [ -f /etc/bashrc ]; then
        . /etc/bashrc
fi

And /etc/bashrc also sources script from /etc/profile.d.

So if someone has the default .bashrc file, then when they run a command over ssh (e.g., by running git pull user@repoaddress), this will also execute your logchk.sh script. However, if they have replaced or modified the default ~/.bashrc file in their account so that it no longer sources /etc/bashrc, then they won't run scripts from /etc/profile.d (unless they have explicitly decided to do so).

This would explain why you see different behavior for some of your users.

1
  • The default sourcing of /etc/bashrc was the missing information. I didn't know about it at all. I checked the dotfiles and this was the issue
    – CrownUpKid
    Jan 30, 2023 at 6:40

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .