What is daily 05:35:01 su: pam_unix(su:session): session opened for user cpanelusername by (uid=0)

[lgiparadise]

What causes
su: pam_unix(su:session): session opened for user cpanelusername by (uid=0)
each day at 5:35 am EDT?

What is the purpose of this?

On 3 different cloudlinux 6 servers, the following is loggeed in /var/log/secure each day at 5:35:

Jan 12 05:35:01 servername su: pam_unix(su:session): session opened for user cpanelusername by (uid=0)
Jan 12 05:35:01 servername su[1978341]: pam_unix(su:session): session closed for user cpanelusername

This Behavior Started March 20, 2019
################### Logwatch ###################
Processing Initiated: Thu Mar 21 03:27:04 2019
Date Range Processed: yesterday
( 2019-Mar-20 )
su-l:
Sessions Opened:
root -> cpanelusername: 1 Time(s)
root -> cpanelusername2: 1 Time(s)

Packages Updated:
lvemanager-4.1.2-1.el6.cloudlinux.noarch
cagefs-6.1-31.el6.cloudlinux.x86_64
alt-php-config-1-32.el6.noarch
cagefs-safebin-6.1-31.el6.cloudlinux.x86_64
lve-utils-3.1.2-1.el6.cloudlinux.x86_64
alt-python27-cllib-1.5.1-1.el6.cloudlinux.x86_64

This Behavior Changed May 31, 2019
################### Logwatch ###################
Processing Initiated: Sat Jun 1 03:12:05 2019
Date Range Processed: yesterday
( 2019-May-31 )
su:
Sessions Opened:
root -> cpanelusername: 1 Time(s)

Packages Updated:
cagefs-6.1.2-1.1.el6.cloudlinux.x86_64
cagefs-safebin-6.1.2-1.1.el6.cloudlinux.x86_64
alt-python27-cllib-1.5.5-1.el6.cloudlinux.x86_64

[lgiparadise]

With further digging to find the cause of this log entry, the above behavior can be eliminated by removing the following cloudlinux cron job

/etc/cron.d/cldiag-cron
35 5 * * * root /usr/bin/flock -n /var/run/cloudlinux_cldiag.cronlock /usr/bin/cldiag --cron-check

Question:

1.) What is /usr/bin/cldiag --cron-check doing to cause the
su: pam_unix(su:session): session opened for user cpanelusername by (uid=0) line in /var/log/secure each day at 05:35?
What is the purpose of this?

(cpanelusername is the name of a cpanel account on the system, replaced for the forum post here with cpanelusername.)

2.) Is there a way to control which cpanelusername is used for this daily cloudlinux check ?

[skhristich]

Hello,
Thank you for reaching out! These are typical system messages. You can try restarting systemd-logind.service to correct them.

systemctl restart systemd-logind.service

Please let us know if you have any questions. Thanks in advance!

[lgiparadise]

Thanks very much for the reply.
Is there a way to change which cpanel account username cloudlinux performs this daily test on?

[skhristich]

Hello,
This /usr/bin/cldiag runs for all users and in this case, an error occurred on the user cpanelusername.
That is, you cannot cancel for one user. more about diagnostics can be found here: https://docs.cloudlinux.com/command-line_tools/#cldiag. If you have any other questions, feel free to ask here. Thank you for contacting us.

[lgiparadise]

Thanks very much.

It seems too odd to be a coincidence that the behavior changed on the same day on all three of my cloudlinux 6 servers.

Before March 20, 2019, there were none of these additional Jan 12 05:35:01 servername su: pam_unix(su:session): session opened for user cpanelusername by (uid=0)
Jan 12 05:35:01 servername su[1978341]: pam_unix(su:session): session closed for user cpanelusername
lines in /var/log/secure when the 5:35 cron ran.

Beginning on March 20 each of the three cloudlinux6 servers began inserting the lines at 5:35 for two cpanel usernames per server and did so every day from March 20 when the following packages were updated

lvemanager-4.1.2-1.el6.cloudlinux.noarch

cagefs-6.1-31.el6.cloudlinux.x86_64

alt-php-config-1-32.el6.noarch

cagefs-safebin-6.1-31.el6.cloudlinux.x86_64

lve-utils-3.1.2-1.el6.cloudlinux.x86_64

alt-python27-cllib-1.5.1-1.el6.cloudlinux.x86_64

Beginning March 20, server1 had

root -> cpanelusername: 1 Time(s)

root -> cpanelusername2: 1 Time(s)

Server2 had

root -> cpanelusername4: 1 Time(s)

root -> cpanelusername7: 1 Time(s)

Server3 had

root -> cpanelusername3: 1 Time(s)

root -> cpanelusername14: 1 Time(s)

Then on May 31, each of the three cloudlinux6 servers changed the behavior to inserting the line for one cpanel username per cloudlinux server each day from the 5:35 cron and continued to do so until the current day after the following pacakages were updated on that day

cagefs-6.1.2-1.1.el6.cloudlinux.x86_64

cagefs-safebin-6.1.2-1.1.el6.cloudlinux.x86_64

alt-python27-cllib-1.5.5-1.el6.cloudlinux.x86_64

After May 31 server1 has

root -> cpanelusername: 1 Time(s)

Server2 has

root -> cpanelusername7: 1 Time(s)

Server3 has

root -> cpanelusername14: 1 Time(s)

Its not the first or last cpanel username created.

I cant see the commonality between the cpanelusername on each server used for the nightly "test" (?)

I did a quick look at the /usr/bin/cldiag --cron-check script but the action where cloudlinux does the su to an individual cpanel account must be in one of the includes ?

Very curious how cloudlinux chooses which cpanel username to check or what exactly would create the

Jan 12 05:35:01 servername su: pam_unix(su:session): session opened for user cpanelusername by (uid=0)

Jan 12 05:35:01 servername su[1978341]: pam_unix(su:session): session closed for user cpanelusername

log entry since its occurring on three different cloudlinux6 servers, with the behavior beginning and then changing on the same day for all three of the servers.

Id like to understand exactly what the 5:35 script is intended to do that would generate the su to cpaneluser line in /var/log/secure.

It seems to choose exactly one cpanel account to test and Im curious how it chooses which cpanelusername to test with.

[skhristich]

Hello,
To help you with this question we need a little bit more information, please create a ticket here https://cloudlinux.zendesk.com/hc/en-us/requests/new and technical experts will help you asap.
If you have any other questions, feel free to ask here. Thank you for contacting us.

[lgiparadise]

OK, will copy and paste this thread into a ticket. Thanks very much.

[lgiparadise]

Before I opened a ticket to take a techs time, I did a bit more digging.

You correctly referred me to https://docs.cloudlinux.com/command-line_tools/#cldiag before in this thread -- I just missed the link to the docs https://(https://docs.cloudlinux.com..._tools/#cagefs -- dont know how I missed it now that I see it right there!

> --check-cagefs
> All checks for CageFS are described separately in this docs section https://docs.cloudlinux.com/command-.../#sanity-check and their start from cagefsctl utility is completely equivalent to the start from cldiag and is designed only for a better experience.
>
> This checker includes a set of CageFS sub-checkers, failure of one (or more) of them causes general checker failure.

https://](https://docs.cloudlinux.co..._tools/#cagefs then has this note which is exactly the behavior which began on March 20, so now I know that this is an intentional behavior.

> 5. Check cagefs users can enter cagefs - chooses two users in the system with enabled CageFS (the first and the second ones in the unsorted list) and tries to log in to CageFS under their credentials and see what happens. It runs su -l "$USER" -s /bin/bash -c "whoami" and compares the output with the $USER and su command retcode estimation.

The changed behavior on May 31 doesnt seen to be reflected in this documentation yet, and Im also curious when it refers to "the unsorted list" which list this is referring to. I wonder if I can change which cpanelusername is used for the check by just reordering "the unsorted list" referrred to here.

Thanks again for your time.](https://docs.cloudlinux.com/command-line_tools/#cagefs)

[skhristich]

Hello,
Happy to hear it and thanks for following up!
If you have any other questions, feel free to ask here.
Thank you for contacting us.