Hey folks, I have a bigger problem within ISPConfig, which hasn't had an impact yet, but now becomes a problem... First things first: My server is a small cloud-node with Ubuntu 18.04 LTS running ISPConfig 3.2 now. My clients have customer-accounts, but they are locked so my admin-account is the only one that can make changes in there. The Problem: Now let's say I wanna create a cronjob for client x with website y. Website y already got a user in there let's name him web44 (so i can copy-paste stuff... ). Now I open the cronjob-window, place stars everywhere, set the site (a laravel-app in that case) and give it the following command: Code: php [web_root]/artisan schedule:run I would suspect for ISPConfig to do it's job and it tries, but after saving I find this in the cron-protocolls: Code: Mon Oct 26 14:03:23 CET 2020 usermod: user web44 is currently used by process 713 Mon Oct 26 14:03:23 CET 2020 failed to execute usermod -d /var/www/clients/client9/web44/. -s /usr/sbin/jk_chrootsh web44 Mon Oct 26 14:03:23 CET 2020 failed to modify user web44 Beeing curious about that ominous process 713, i started up putty and checked via top which process that is... Code: 713 web44 20 0 585300 44820 37584 S 0.0 1.1 0:00.63 php-fpm7.4 Killing that process does nothing since it's been restarted and even a reboot doesn't help. Funny enough - when I ssh into that site I can use crontab -e to manually place the command and it works like a charm. Well... Having a way to set up cronjobs is cool, but I would like to manage them from within ISPConfig... Anyone has an idea on where to look into? Greetings
As far as I know that usermod error doesn't cause any problems in 3.2, but what does the /etc/passwd entry for web44 look like? Setting the shell to jk_chrootsh would indicate you set this cronjob to run inside Jailkit. Do you have php installed in that jail? Does the /etc/cron.d/ispc_web44 cronjob get created? What does the file contain? The 'crontab' command is not installed inside a jail, which would indicate your shell user is running in the base system, not the same jail that your cronjob is running in.
