Stack Exchange Network

Stack Exchange network consists of 175 Q&A communities including Stack Overflow, the largest, most trusted online community for developers to learn, share their knowledge, and build their careers.

Visit Stack Exchange
3 deleted 1 characters in body
source | link

I can't really answer as such but I think I can point you in the right direction. I found this in the Arch Wiki page of systemd:

polkit is necessary for power management. If you are in a local systemd-logind user session and no other session is active, the following commands will work without root privileges. If not (for example, because another user is logged into a tty), systemd will automatically ask you for the root password.

[list of various systemctl commands]

systemctl suspend

This suggests to me the following possibilities:

  1. You have another user logged in. Perhaps you have logged in via a tty?

  2. cron runs its commands using /bin/sh. By default, on Arch this is a symlink to /bin/bash. This would mean that cron is starting a non-interactive bash shell which then detects that there is another user session running (yours)\, so it does not have the right to run systemctl despite running as your user.

So, if your problem is that your logged in user means that the shell thatbecause cron starts is not allowed to run systemctl because you are already logged in, you might be able to get around that by playing with polkit but I have no experience there so I can't help.

I can't really answer as such but I think I can point you in the right direction. I found this in the Arch Wiki page of systemd:

polkit is necessary for power management. If you are in a local systemd-logind user session and no other session is active, the following commands will work without root privileges. If not (for example, because another user is logged into a tty), systemd will automatically ask you for the root password.

[list of various systemctl commands]

systemctl suspend

This suggests to me the following possibilities:

  1. You have another user logged in. Perhaps you have logged in via a tty?

  2. cron runs its commands using /bin/sh. By default, on Arch this is a symlink to /bin/bash. This would mean that cron is starting a non-interactive bash shell which then detects that there is another user session running (yours)\, so it does not have the right to run systemctl despite running as your user.

So, if your problem is that your logged in user means that the shell that cron starts is not allowed to run systemctl, you might be able to get around that by playing with polkit but I have no experience there.

I can't really answer as such but I think I can point you in the right direction. I found this in the Arch Wiki page of systemd:

polkit is necessary for power management. If you are in a local systemd-logind user session and no other session is active, the following commands will work without root privileges. If not (for example, because another user is logged into a tty), systemd will automatically ask you for the root password.

[list of various systemctl commands]

systemctl suspend

This suggests to me the following possibilities:

  1. You have another user logged in. Perhaps you have logged in via a tty?

  2. cron runs its commands using /bin/sh. By default, on Arch this is a symlink to /bin/bash. This would mean that cron is starting a non-interactive bash shell which then detects that there is another user session running (yours), so it does not have the right to run systemctl despite running as your user.

So, if your problem is because cron is not allowed to run systemctl because you are already logged in, you might be able to get around that by playing with polkit but I have no experience there so I can't help.

2 added 217 characters in body
source | link

I can't really answer as such but I think I can point you in the right direction. I found this in the Arch Wiki page of systemd:

polkit is necessary for power management. If you are in a local systemd-logind user session and no other session is active, the following commands will work without root privileges. If not (for example, because another user is logged into a tty), systemd will automatically ask you for the root password.

[list of various systemctl commands]

systemctl suspend

This suggests to me the following possibilities:

  1. You have another user logged in. Perhaps you have logged in via a tty?

  2. I'm not sure what kind of shell cron launches to run your crontabsruns its commands using /bin/sh. It may well beBy default, on Arch this is a login shell which means that when cron triessymlink to suspend, there are 2 active login shells, cron/bin/bash's and your's. The factThis would mean that cron runsis starting a non-interactive bash shell which then detects that there is another user session running (yours)\, so it does not have the right to run systemctl despite running as your user makes no difference if it starts a login shell.  

So, if your problem is that your logged in user means that the shell that cron starts is not allowed to run systemctl, you might be able to get around that by playing with polkit but I have no experience there.

I can't really answer as such but I think I can point you in the right direction. I found this in the Arch Wiki page of systemd:

polkit is necessary for power management. If you are in a local systemd-logind user session and no other session is active, the following commands will work without root privileges. If not (for example, because another user is logged into a tty), systemd will automatically ask you for the root password.

This suggests to me the following possibilities:

  1. You have another user logged in. Perhaps you have logged in via a tty?

  2. I'm not sure what kind of shell cron launches to run your crontabs. It may well be a login shell which means that when cron tries to suspend, there are 2 active login shells, cron's and your's. The fact that cron runs as your user makes no difference if it starts a login shell.  

So, if your problem is that your logged in user means that the shell that cron starts is not allowed to run systemctl, you might be able to get around that by playing with polkit but I have no experience there.

I can't really answer as such but I think I can point you in the right direction. I found this in the Arch Wiki page of systemd:

polkit is necessary for power management. If you are in a local systemd-logind user session and no other session is active, the following commands will work without root privileges. If not (for example, because another user is logged into a tty), systemd will automatically ask you for the root password.

[list of various systemctl commands]

systemctl suspend

This suggests to me the following possibilities:

  1. You have another user logged in. Perhaps you have logged in via a tty?

  2. cron runs its commands using /bin/sh. By default, on Arch this is a symlink to /bin/bash. This would mean that cron is starting a non-interactive bash shell which then detects that there is another user session running (yours)\, so it does not have the right to run systemctl despite running as your user.

So, if your problem is that your logged in user means that the shell that cron starts is not allowed to run systemctl, you might be able to get around that by playing with polkit but I have no experience there.

1
source | link

I can't really answer as such but I think I can point you in the right direction. I found this in the Arch Wiki page of systemd:

polkit is necessary for power management. If you are in a local systemd-logind user session and no other session is active, the following commands will work without root privileges. If not (for example, because another user is logged into a tty), systemd will automatically ask you for the root password.

This suggests to me the following possibilities:

  1. You have another user logged in. Perhaps you have logged in via a tty?

  2. I'm not sure what kind of shell cron launches to run your crontabs. It may well be a login shell which means that when cron tries to suspend, there are 2 active login shells, cron's and your's. The fact that cron runs as your user makes no difference if it starts a login shell.

So, if your problem is that your logged in user means that the shell that cron starts is not allowed to run systemctl, you might be able to get around that by playing with polkit but I have no experience there.