• Plesk Uservoice will be deprecated by October. Moving forward, all product feature requests and improvement suggestions will be managed through our new platform Plesk Productboard.
    To continue sharing your ideas and feedback, please visit features.plesk.com

Issue Planified Task not working anymore after upgrading Debian/updating Plesk

Kouenteen

New Pleskian
Server operating system version
Debian 12.12 (and Ubuntu 24.04.3 LTS)
Plesk version and microupdate number
Obsidian 18.0.73
Hello.

Quick summary :
I upgraded a Debian 10 server to Debian 11 and then to Debian 12 using this Plesk documentation : https://support.plesk.com/hc/en-us/...-upgrade-procedure-on-Linux-server-with-Plesk

While the server was on Debian 10 with Plesk in 18.0.70, there was a planified task on one website that previously worked.

Bash:
wget -q -O - "https://domain.tld/module/gsitemap/cron?token=297d9f7x6q3&id_shop=1"
After upgrading to Debian 12, I updated Plesk from 18.0.70 to 18.0.73.

At first, there was some dependencies issues :
Bash:
wget: error while loading shared libraries: libnettle.so.8: cannot open shared object file: No such file or directory

I have resolved them by copying all wget’s dependencies into the lib/x86_64-linux-gnu folder of the website.
Bash:
cp `ldd /usr/bin/wget | grep "=>" | awk '{print $3}'` /var/www/vhosts/domain.tld/lib/x86_64-linux-gnu

After that, the error changed into :
Bash:
The task "wget -q -O - "https://domain.tld/module/gsitemap/cron?token=297d9f7x6q3&id_shop=1"" completed with an error in 0 seconds.

The task was and is still configured at the website's level (Domains > domain.tld > Development Tools -> Planified Task).
By going into the Tools & Settings menu, then in Tools & Ressources > Planified Task > Settings, the crontab's shell is selected on /bin/bash (chrooted).

It seemed odd to me that there was no error detail anymore from the task scheduler. So I looked into the following log file and got this error right after executing the task :

Bash:
cat /var/log/plesk/panel.log

[2025-10-02 15:52:29.683] 1527389:68de839d49383 ERR [panel] Task failed: id=49445, pid=1527389, type=scheduler-run-task, error=PleskUserException: Scheduled task failed
file: /opt/psa/admin/plib/Scheduler/RunTask.php
line: 54
code: 0
trace: #0 /opt/psa/admin/plib/Db/Table/Broker/LongTasks.php(178): Scheduler_RunTask->run()
#1 /opt/psa/admin/plib/Db/Table/Broker/LongTasks.php(113): Db_Table_Broker_LongTasks->_syncStart(object of type Db_Table_Row_LongTask)
#2 /opt/psa/admin/plib/Task/Async/Executor.php(54): Db_Table_Broker_LongTasks->runTaskWithinExecutor(object of type Db_Table_Row_LongTask)
#3 /opt/psa/admin/plib/scripts/task-async-executor.php(6): Task_Async_Executor->execute()

[2025-10-02 15:52:29.704] 1527389:68de839d49383 ERR [panel] Long task executor: id=49445 completed with error: Scheduled task failed:
0: /opt/psa/admin/plib/Task/Async/Executor.php:56
    Task_Async_Executor->execute()
1: /opt/psa/admin/plib/scripts/task-async-executor.php:6

I tried to create a new website and then executing the same planified task, same error. I did plesk repair installation/all, nothing.
Even tried on another Plesk server that I upgraded from Ubuntu 20.04 to 22.04 and then 24.04, same error.

Maybe someone has an idea of what could possibly be wrong ?
I could provide more logs if necessary.

Kind regards,
 
Hello, @Kouenteen . Could you please confirm the SSH access on a subscription level in Subscriptions > example.com > Websites & Domains > Hosting & DNS > Hosting > SSH access? If it's set to "Forbidden", please change it to one of the other options (recommended /bin/bash (chrooted)).
 
Hello @Sebahat.hadzhi thank you for your fast answer.
The SSH Access for the website's user was indeed set on "Forbidden". (in /etc/passwd the user was on /bin/false)
After changing it to /bin/bash (chrooted), the user is on /opt/psa/bin/chrootsh.

Executing the planifed task is still giving me the same error.

Kind regards,
 
Thank you for the update, @Kouenteen . It think I mistakenly suggested the chrooted environment, when in fact it should not be. So, for the sake of testing could you please change the SSH access to /bin/bash, for example? Another thing you might try with /bin/bash (chrooted) is to modify your command to:


Bash:
wget -q -O - "https://domain.tld/module/gsitemap/cron?token=297d9f7x6q3&id_shop=1" --secure-protocol tlsv1

I hope that helps.
 
Thank you for your proposition, unfortunately I am getting the same error.

Bash:
[2025-10-06 08:47:25.338] 3015665:68e365fd1a96f ERR [panel] Task failed: id=49645, pid=3015665, type=scheduler-run-task, error=PleskUserException: Scheduled task failed
file: /opt/psa/admin/plib/Scheduler/RunTask.php
line: 54
code: 0
trace: #0 /opt/psa/admin/plib/Db/Table/Broker/LongTasks.php(178): Scheduler_RunTask->run()
#1 /opt/psa/admin/plib/Db/Table/Broker/LongTasks.php(113): Db_Table_Broker_LongTasks->_syncStart(object of type Db_Table_Row_LongTask)
#2 /opt/psa/admin/plib/Task/Async/Executor.php(54): Db_Table_Broker_LongTasks->runTaskWithinExecutor(object of type Db_Table_Row_LongTask)
#3 /opt/psa/admin/plib/scripts/task-async-executor.php(6): Task_Async_Executor->execute()

[2025-10-06 08:47:25.354] 3015665:68e365fd1a96f ERR [panel] Long task executor: id=49645 completed with error: Scheduled task failed:
0: /opt/psa/admin/plib/Task/Async/Executor.php:56
    Task_Async_Executor->execute()
1: /opt/psa/admin/plib/scripts/task-async-executor.php:6

Maybe it's not related to the task in particular ? What I mean is, it's a simple "wget".
While logged in as root on the server, the command can be executed no problem. Even as a normal Linux user.

Kind regards,
 
Thank you for your proposition, unfortunately I am getting the same error.

Bash:
[2025-10-06 08:47:25.338] 3015665:68e365fd1a96f ERR [panel] Task failed: id=49645, pid=3015665, type=scheduler-run-task, error=PleskUserException: Scheduled task failed
file: /opt/psa/admin/plib/Scheduler/RunTask.php
line: 54
code: 0
trace: #0 /opt/psa/admin/plib/Db/Table/Broker/LongTasks.php(178): Scheduler_RunTask->run()
#1 /opt/psa/admin/plib/Db/Table/Broker/LongTasks.php(113): Db_Table_Broker_LongTasks->_syncStart(object of type Db_Table_Row_LongTask)
#2 /opt/psa/admin/plib/Task/Async/Executor.php(54): Db_Table_Broker_LongTasks->runTaskWithinExecutor(object of type Db_Table_Row_LongTask)
#3 /opt/psa/admin/plib/scripts/task-async-executor.php(6): Task_Async_Executor->execute()

[2025-10-06 08:47:25.354] 3015665:68e365fd1a96f ERR [panel] Long task executor: id=49645 completed with error: Scheduled task failed:
0: /opt/psa/admin/plib/Task/Async/Executor.php:56
    Task_Async_Executor->execute()
1: /opt/psa/admin/plib/scripts/task-async-executor.php:6

Maybe it's not related to the task in particular ? What I mean is, it's a simple "wget".
While logged in as root on the server, the command can be executed no problem. Even as a normal Linux user.

Kind regards,
To be precise, I first switched the Planified Task "global" settings to /bin/bash.
Then, after executing the task, I am getting the same error on the concerned website for both wget commands (without and with --secure-protocol tlsv1).

But on a new Plesk website that I created, it could now execute the planified task.
By switching back the "global" Planified Task setting to /bin/bash (chrooted), the new Plesk website cannot execute the task anymore.

In every case, the concerned website (domain.tld) couldn't execute the task.
 
Thank you for the update, @Kouenteen . Just to make sure we are on the same page, could you please confirm where you are editing the setting for the shell environment from:
  • Tools & Settings > Scheduled Tasks > Settings > Crontab shell
or

  • Subscriptions > example.com > Websites & Domains > Hosting & DNS > Hosting > SSH access
or from both places? What are the current settings in both places? Do I correctly understand that you have the task in question added in Subscriptions > example.com > Websites & Domains > Dashboard > Scheduled Tasks?
 
Hello, it's my mistake I misread your message and only change the /bin/bash (chrooted) to /bin/bash in the Tool & Settings menu. Here is all I tested :

First I tested with :
Tools & Settings > Scheduled Tasks > Settings > Crontab shell > /bin/bash (chrooted)
Subscriptions > example.com > Websites & Domains > Hosting & DNS > Hosting > SSH access > Forbidden
Not working
on concerned website (domain.tld) using the wget command with or without "--secure-protocol tlsv1".
Not working on a new Plesk website using the wget command... (it's expected result)

Then I tried :
Tools & Settings > Scheduled Tasks > Settings > Crontab shell > /bin/bash (chrooted)
Subscriptions > example.com > Websites & Domains > Hosting & DNS > Hosting > SSH access > /bin/bash (chrooted)
Not working
on concerned website (domain.tld) using the wget command with or without "--secure-protocol tlsv1".
Not working on a new Plesk website using the wget command. (it's expected result)

Finally :
Tools & Settings > Scheduled Tasks > Settings > Crontab shell > /bin/bash (chrooted)
Subscriptions > example.com > Websites & Domains > Hosting & DNS > Hosting > SSH access > /bin/bash
Working
on the concerned website (domain.tld) using the wget command with or without "--secure-protocol tlsv1".
Not working on a new Plesk website using the wget command. (it's expected result)
> So it is indeed working when having SSH access enabled on the subscription, but not in chrooted mode for the subscription and no more Forbidden (/bin/false).

If I have understood correctly, in Debian 10, the SSH access could be on Forbidden (/bin/false) and the planified task could work, but on Debian 12, it seems to be working only with SSH access enabled on /bin/bash for the subscription ? Is it a new expected way of Plesk in order to make it work ? Or is it a modification from Debian 11/12 ? Maybe a problem with the website's chrooted environment ? I don't know at all.

I also found this link which describe a little bit what you asked me to apply : (Plesk for Linux) Enabling SSH Access for Website Users
 
Right, so the setting you have in Tools & Settings > Scheduled Tasks > Settings > Crontab shell are for the globally configured scheduled tasks. For the jobs configured on a subscription user level, the environment is determined from Subscriptions > example.com > Websites & Domains > Hosting & DNS > Hosting > SSH access.

About the command itself, I don't think the OS has anything to do with it.

System utilities (curl, wget, php, etc.) are not available for the subscription user either because this user does not have any shell enabled or the utility (which is used in the scheduled task) is not added to chrooted environment.

More details:

 
Hello,

The fact that is was working with no shell access for the subscription (/bin/false) on Debian 10/Plesk 18.0.70 makes me wonder what has been changed, either at the system level or at the Plesk level, to make it necessary to enable SSH access in order for scheduled tasks to work. Fortunately, I only have 2 website/60 that needs planified tasks.

Having to enable SSH access on /bin/bash (non-chrooted) in a subscription just to be able to use scheduled tasks via this website's user seems strange to me, since it worked well before. Maybe the upgrade process broke something that wouldn't have happened on a fresh install ? (On Debian or Plesk level)

Also, thank you for the link's detail. I tried to apply the second solution (using the update-chroot.sh script to re-add wgeet/rebuild the domain.tld chroot) but it's still not working (I'm getting the same ".php" error logged in /var/log/plesk/panel.log).

Kind regards,
 
Back
Top