Cron is trying (and failing) to open env file: /etc/environment
Clash Royale CLAN TAG#URR8PPP
I'm using Devuan ASCII (which is more or less Debian 9, Stretch). Now, my /var/log/auth.log has a bunch of these entries:
Jan 6 09:45:01 mybox CRON[20951]: pam_env(cron:session): Unable to open env file: /etc/environment: No such file or directory
Jan 6 09:45:01 mybox CRON[20951]: pam_unix(cron:session): session opened for user root by (uid=0)
which apparently get generated when I su.
- Why is cron/pam_env/pam_unix trying to open that file in the first place, rather than checking whether it exists?
- If they legitimately expect it, why isn't it there?
- What should I do about this?
debian cron environment-variables pam devuan
asked Jan 7 at 11:17
einpoklumeinpoklum
2,12941952
add a comment |
I'm using Devuan ASCII (which is more or less Debian 9, Stretch). Now, my /var/log/auth.log has a bunch of these entries:
Jan 6 09:45:01 mybox CRON[20951]: pam_env(cron:session): Unable to open env file: /etc/environment: No such file or directory
Jan 6 09:45:01 mybox CRON[20951]: pam_unix(cron:session): session opened for user root by (uid=0)
which apparently get generated when I su.
- Why is cron/pam_env/pam_unix trying to open that file in the first place, rather than checking whether it exists?
- If they legitimately expect it, why isn't it there?
- What should I do about this?
debian cron environment-variables pam devuan
asked Jan 7 at 11:17
einpoklumeinpoklum
2,12941952
add a comment |
I'm using Devuan ASCII (which is more or less Debian 9, Stretch). Now, my /var/log/auth.log has a bunch of these entries:
Jan 6 09:45:01 mybox CRON[20951]: pam_env(cron:session): Unable to open env file: /etc/environment: No such file or directory
Jan 6 09:45:01 mybox CRON[20951]: pam_unix(cron:session): session opened for user root by (uid=0)
which apparently get generated when I su.
- Why is cron/pam_env/pam_unix trying to open that file in the first place, rather than checking whether it exists?
- If they legitimately expect it, why isn't it there?
- What should I do about this?
debian cron environment-variables pam devuan
asked Jan 7 at 11:17
einpoklumeinpoklum
2,12941952
I'm using Devuan ASCII (which is more or less Debian 9, Stretch). Now, my /var/log/auth.log has a bunch of these entries:
Jan 6 09:45:01 mybox CRON[20951]: pam_env(cron:session): Unable to open env file: /etc/environment: No such file or directory
Jan 6 09:45:01 mybox CRON[20951]: pam_unix(cron:session): session opened for user root by (uid=0)
which apparently get generated when I su.
- Why is cron/pam_env/pam_unix trying to open that file in the first place, rather than checking whether it exists?
- If they legitimately expect it, why isn't it there?
- What should I do about this?
debian cron environment-variables pam devuan
debian cron environment-variables pam devuan
asked Jan 7 at 11:17
einpoklumeinpoklum
2,12941952
asked Jan 7 at 11:17
einpoklumeinpoklum
2,12941952
edited Jan 7 at 12:05
einpoklum
asked Jan 7 at 11:17
einpoklumeinpoklum
2,12941952
asked Jan 7 at 11:17
einpoklumeinpoklum
2,12941952
asked Jan 7 at 11:17
einpoklumeinpoklum
2,12941952
2,12941952
add a comment |
add a comment |
2 Answers
2
active
oldest
votes
Answering all of your questions
- Why is cron/pam_env/pam_unix trying to open that file in the first place?
See BUG #646015. In some cases (like locale related stuff) this file is deprecated. But it is still used system-wide, and log is made whenever it is missing.
- If they legitimately expect it, why isn't it there?
Cause maybe the bug isn't fixed after all. Steve Langasek (BUG #646015) said it is, and new systems should create that file using postinst scripts the same way old systems being upgraded should already have that file.
- What should I do about this?
- Run
dpkg-reconfigure libpam-modulesand see if it will create the file through itspostinstscript. - If that does not work, create the file manually with
touch /etc/environment
It's also interesting to report your issue to the Devuan Project with details of the problem and your setup since this issue was resolved before the Debian/Devuan fork happened.
edited Jan 7 at 13:34
terdon♦
129k32253428
answered Jan 7 at 12:08
nwildnernwildner
14.2k14176
add a comment |
An inelegant but perfectly valid solution is to give those modules what they want: As root, execute
touch /etc/environment
and to make sure the permissions are right, just in case:
chmod 644 /etc/environment
answered Jan 7 at 11:25
einpoklumeinpoklum
2,12941952
2
Note that this behavior is completely normal. Thepam_envis expected to look for/etc/environmentand that's the default way that the/etc/environmentfile is read, at least on Linux systems.
– terdon♦
Jan 7 at 11:37
I have it here:cat /etc/environmentQT_QPA_PLATFORMTHEME=qt5ct
– Rui F Ribeiro
Jan 7 at 11:41
@terdon: Looking for it is fine, assuming it exists is not fine. It's either a bug inpam_envor an issue with Debian.
– einpoklum
Jan 7 at 12:04
Sounds more like a bug of the specific distro. That is a standard file and it exists in Debian. But is this actually a problem? Does it cause any issue other than a message in the log?
– terdon♦
Jan 7 at 12:06
add a comment |
Your Answer
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "106"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f492972%2fcron-is-trying-and-failing-to-open-env-file-etc-environment%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
Answering all of your questions
- Why is cron/pam_env/pam_unix trying to open that file in the first place?
See BUG #646015. In some cases (like locale related stuff) this file is deprecated. But it is still used system-wide, and log is made whenever it is missing.
- If they legitimately expect it, why isn't it there?
Cause maybe the bug isn't fixed after all. Steve Langasek (BUG #646015) said it is, and new systems should create that file using postinst scripts the same way old systems being upgraded should already have that file.
- What should I do about this?
- Run
dpkg-reconfigure libpam-modulesand see if it will create the file through itspostinstscript. - If that does not work, create the file manually with
touch /etc/environment
It's also interesting to report your issue to the Devuan Project with details of the problem and your setup since this issue was resolved before the Debian/Devuan fork happened.
edited Jan 7 at 13:34
terdon♦
129k32253428
answered Jan 7 at 12:08
nwildnernwildner
14.2k14176
add a comment |
Answering all of your questions
- Why is cron/pam_env/pam_unix trying to open that file in the first place?
See BUG #646015. In some cases (like locale related stuff) this file is deprecated. But it is still used system-wide, and log is made whenever it is missing.
- If they legitimately expect it, why isn't it there?
Cause maybe the bug isn't fixed after all. Steve Langasek (BUG #646015) said it is, and new systems should create that file using postinst scripts the same way old systems being upgraded should already have that file.
- What should I do about this?
- Run
dpkg-reconfigure libpam-modulesand see if it will create the file through itspostinstscript. - If that does not work, create the file manually with
touch /etc/environment
It's also interesting to report your issue to the Devuan Project with details of the problem and your setup since this issue was resolved before the Debian/Devuan fork happened.
edited Jan 7 at 13:34
terdon♦
129k32253428
answered Jan 7 at 12:08
nwildnernwildner
14.2k14176
add a comment |
Answering all of your questions
- Why is cron/pam_env/pam_unix trying to open that file in the first place?
See BUG #646015. In some cases (like locale related stuff) this file is deprecated. But it is still used system-wide, and log is made whenever it is missing.
- If they legitimately expect it, why isn't it there?
Cause maybe the bug isn't fixed after all. Steve Langasek (BUG #646015) said it is, and new systems should create that file using postinst scripts the same way old systems being upgraded should already have that file.
- What should I do about this?
- Run
dpkg-reconfigure libpam-modulesand see if it will create the file through itspostinstscript. - If that does not work, create the file manually with
touch /etc/environment
It's also interesting to report your issue to the Devuan Project with details of the problem and your setup since this issue was resolved before the Debian/Devuan fork happened.
edited Jan 7 at 13:34
terdon♦
129k32253428
answered Jan 7 at 12:08
nwildnernwildner
14.2k14176
Answering all of your questions
- Why is cron/pam_env/pam_unix trying to open that file in the first place?
See BUG #646015. In some cases (like locale related stuff) this file is deprecated. But it is still used system-wide, and log is made whenever it is missing.
- If they legitimately expect it, why isn't it there?
Cause maybe the bug isn't fixed after all. Steve Langasek (BUG #646015) said it is, and new systems should create that file using postinst scripts the same way old systems being upgraded should already have that file.
- What should I do about this?
- Run
dpkg-reconfigure libpam-modulesand see if it will create the file through itspostinstscript. - If that does not work, create the file manually with
touch /etc/environment
It's also interesting to report your issue to the Devuan Project with details of the problem and your setup since this issue was resolved before the Debian/Devuan fork happened.
edited Jan 7 at 13:34
terdon♦
129k32253428
answered Jan 7 at 12:08
nwildnernwildner
14.2k14176
edited Jan 7 at 13:34
terdon♦
129k32253428
edited Jan 7 at 13:34
terdon♦
129k32253428
edited Jan 7 at 13:34
terdon♦
129k32253428
129k32253428
answered Jan 7 at 12:08
nwildnernwildner
14.2k14176
answered Jan 7 at 12:08
nwildnernwildner
14.2k14176
answered Jan 7 at 12:08
nwildnernwildner
14.2k14176
14.2k14176
add a comment |
add a comment |
An inelegant but perfectly valid solution is to give those modules what they want: As root, execute
touch /etc/environment
and to make sure the permissions are right, just in case:
chmod 644 /etc/environment
answered Jan 7 at 11:25
einpoklumeinpoklum
2,12941952
2
Note that this behavior is completely normal. Thepam_envis expected to look for/etc/environmentand that's the default way that the/etc/environmentfile is read, at least on Linux systems.
– terdon♦
Jan 7 at 11:37
I have it here:cat /etc/environmentQT_QPA_PLATFORMTHEME=qt5ct
– Rui F Ribeiro
Jan 7 at 11:41
@terdon: Looking for it is fine, assuming it exists is not fine. It's either a bug inpam_envor an issue with Debian.
– einpoklum
Jan 7 at 12:04
Sounds more like a bug of the specific distro. That is a standard file and it exists in Debian. But is this actually a problem? Does it cause any issue other than a message in the log?
– terdon♦
Jan 7 at 12:06
add a comment |
An inelegant but perfectly valid solution is to give those modules what they want: As root, execute
touch /etc/environment
and to make sure the permissions are right, just in case:
chmod 644 /etc/environment
answered Jan 7 at 11:25
einpoklumeinpoklum
2,12941952
2
Note that this behavior is completely normal. Thepam_envis expected to look for/etc/environmentand that's the default way that the/etc/environmentfile is read, at least on Linux systems.
– terdon♦
Jan 7 at 11:37
I have it here:cat /etc/environmentQT_QPA_PLATFORMTHEME=qt5ct
– Rui F Ribeiro
Jan 7 at 11:41
@terdon: Looking for it is fine, assuming it exists is not fine. It's either a bug inpam_envor an issue with Debian.
– einpoklum
Jan 7 at 12:04
Sounds more like a bug of the specific distro. That is a standard file and it exists in Debian. But is this actually a problem? Does it cause any issue other than a message in the log?
– terdon♦
Jan 7 at 12:06
add a comment |
An inelegant but perfectly valid solution is to give those modules what they want: As root, execute
touch /etc/environment
and to make sure the permissions are right, just in case:
chmod 644 /etc/environment
answered Jan 7 at 11:25
einpoklumeinpoklum
2,12941952
An inelegant but perfectly valid solution is to give those modules what they want: As root, execute
touch /etc/environment
and to make sure the permissions are right, just in case:
chmod 644 /etc/environment
answered Jan 7 at 11:25
einpoklumeinpoklum
2,12941952
answered Jan 7 at 11:25
einpoklumeinpoklum
2,12941952
answered Jan 7 at 11:25
einpoklumeinpoklum
2,12941952
answered Jan 7 at 11:25
einpoklumeinpoklum
2,12941952
2,12941952
2
Note that this behavior is completely normal. Thepam_envis expected to look for/etc/environmentand that's the default way that the/etc/environmentfile is read, at least on Linux systems.
– terdon♦
Jan 7 at 11:37
I have it here:cat /etc/environmentQT_QPA_PLATFORMTHEME=qt5ct
– Rui F Ribeiro
Jan 7 at 11:41
@terdon: Looking for it is fine, assuming it exists is not fine. It's either a bug inpam_envor an issue with Debian.
– einpoklum
Jan 7 at 12:04
Sounds more like a bug of the specific distro. That is a standard file and it exists in Debian. But is this actually a problem? Does it cause any issue other than a message in the log?
– terdon♦
Jan 7 at 12:06
add a comment |
2
Note that this behavior is completely normal. Thepam_envis expected to look for/etc/environmentand that's the default way that the/etc/environmentfile is read, at least on Linux systems.
– terdon♦
Jan 7 at 11:37
I have it here:cat /etc/environmentQT_QPA_PLATFORMTHEME=qt5ct
– Rui F Ribeiro
Jan 7 at 11:41
@terdon: Looking for it is fine, assuming it exists is not fine. It's either a bug inpam_envor an issue with Debian.
– einpoklum
Jan 7 at 12:04
Sounds more like a bug of the specific distro. That is a standard file and it exists in Debian. But is this actually a problem? Does it cause any issue other than a message in the log?
– terdon♦
Jan 7 at 12:06
2
2
Note that this behavior is completely normal. The
pam_env is expected to look for /etc/environment and that's the default way that the /etc/environment file is read, at least on Linux systems.– terdon♦
Jan 7 at 11:37
Note that this behavior is completely normal. The
pam_env is expected to look for /etc/environment and that's the default way that the /etc/environment file is read, at least on Linux systems.– terdon♦
Jan 7 at 11:37
I have it here:
cat /etc/environment QT_QPA_PLATFORMTHEME=qt5ct– Rui F Ribeiro
Jan 7 at 11:41
I have it here:
cat /etc/environment QT_QPA_PLATFORMTHEME=qt5ct– Rui F Ribeiro
Jan 7 at 11:41
@terdon: Looking for it is fine, assuming it exists is not fine. It's either a bug in
pam_env or an issue with Debian.– einpoklum
Jan 7 at 12:04
@terdon: Looking for it is fine, assuming it exists is not fine. It's either a bug in
pam_env or an issue with Debian.– einpoklum
Jan 7 at 12:04
Sounds more like a bug of the specific distro. That is a standard file and it exists in Debian. But is this actually a problem? Does it cause any issue other than a message in the log?
– terdon♦
Jan 7 at 12:06
Sounds more like a bug of the specific distro. That is a standard file and it exists in Debian. But is this actually a problem? Does it cause any issue other than a message in the log?
– terdon♦
Jan 7 at 12:06
add a comment |
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f492972%2fcron-is-trying-and-failing-to-open-env-file-etc-environment%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown