New answers tagged

0

I'd use a wrapper for the script. i.e.: #!/bin/bash RUNAS=user1 if [ "${USER}" == "root" ] then # use sudo to change user sudo -u $RUNAS -H /usr/local/bin/php /path/to/script.php else # run as the current user /usr/local/bin/php /path/to/script.php fi otherwise you could just add sudo to the cron-task: 15 15 * * * root sudo -u user1 -H ...


0

use something like this if you want to avoid the script from being run as root: 15 15 * * * anotheruser /usr/local/bin/php /path/to/script.php In your version the script IS INDEED run as root. The cron line does explicitly say so. I guess your systems administrator and you had a misunderstanding and he meant this: if php-fpm or apache-mod-php ...


3

Processes run as a UID. The mapping to names like root is just for human convenience. So when 'ps' looks at the process and sees it running as UID 0, it consults the /etc/passwd file and finds what username matches it. Depending on how it searches the file it might return root or your new abc user. But both usernames are really the same account - UID 0. ...


0

It it literally trying to email root@ with no domain which is obviously invalid (thus the error domain "" is syntactically invalid). There are several steps exim4 should be taking in order to get from your invalid email address to a valid one. First, exim4 checks to see if you should be allowed to submit an unqualified email. From the documentation, ...


2

On systemd systems, you may have to configure this via systemd rather than system V init scripts The below steps are tested and working on Ubuntu 16.04 LTS. And this is your culprit for redirected init scripts: /lib/lsb/init-functions.d/40-systemd 1. Edit your php-fpm pool configuration e.g. /etc/php/7.0/fpm/pool.d/www.conf and configure root as the ...


3

I finally found a solution. It turned out Ubuntu was using systemd to start and restart PHP-FPM and was therefor ignoring the init.d files. If you experience issues with adjustments to init.d files being ignored and you're on Ubuntu 15.04 or later, big chance that service has a systemd service file as well. So the fix for my problem: My system has a file ...


2

As per your comment: I found this in var/log/auth.log: Jul 7 17:23:02 v81553 sshd[14589]: User root not allowed because shell /bin/bash\r does not exist It looks like the shell for root is set to /bin/bash\r - likely the result of a tool attempting to add a newline to /etc/passwd incorrectly. You can confirm this with: $ grep ^root /etc/passwd root:x:...


1

Use the force Luke! use RequestTTY force in your ~/.ssh/config for the desired host. btw. this is also discussed here http://unix.stackexchange.com/questions/27713/ssh-config-way-to-spectify-pseudo-tty-allocation-and-command-execution-like-sc/294468#294468



Top 50 recent answers are included