Hi,I have set up osticket so that when an email is sent to support@company.com a ticket is automatically created. My problem:a ticket is only created when an agent is actively logged in into osticket (fi; when someone has sent a mail to support@ in the evening and the agent logs in the following morning, only then a ticket is created).I use the following command in my crontab: www-data /usr/bin/php7.0 /var/www/osticket/upload/api/cron.phpWhen executing this in terminal as www-data I get the following error message:PHP Warning:  Declaration of AssignmentForm:($options) should be compatible with Form:($staff = true, $title = false, $options = Array) in /var/www/osticket/upload/include/class.forms.php on line 4368PHP Warning:  Declaration of TransferForm:($options) should be compatible with Form:($staff = true, $title = false, $options = Array) in /var/www/osticket/upload/include/class.forms.php on line 4488See this github issue: https://github.com/osTicket/osTicket/issues/3033Could this be related? I've already tried the solution proposed in the last post, but didn't work at all.Could someone help me please? This functionallity is really essential to us. 

My version:osTicket Versionv1.10.1 (9ae093d) —  Up to dateWeb Server SoftwareApache/2.4.18 (Ubuntu)MySQL Version10.2.15PHP Version7.0.30-0ubuntu0.16.04.1

Hi,reading the wiki I've found the main cause myself:In email settings, section incoming mails: option "tech on auto-cron" was selected hence osticket would import emails when an agent was logged in.But now my cron job does not seem to work. When I perform this command manually:sudo -u www-data /usr/bin/php7.0 /var/www/osticket/upload/api/cron.phpMy emails are polled. But with my cronjob enabled:*/5 * * * * www-data /usr/bin/php7.0 /var/www/osticket/upload/api/cron.phpMy emails are not polled. What could be wrong? Here is output from:  grep cron /var/log/syslogMay 29 09 OSSERVER CRON: (root) CMD (www-data /usr/bin/php7.0 /var/www/osticket/upload/api/cron.php)kr,wouterps: my initial thoughts regarding the php-error were wrong, this had nothing to do with it it only affects pop-up windows as the githubb issue report states. 

Ok I've solved it. Turned out i needed to append the PHP command in my crontab with "sudo -u"So instead of:*/5 * * * * www-data /usr/bin/php7.0 /var/www/osticket/upload/api/cron.phpit must be:*/5 * * * * sudo -u www-data /usr/bin/php7.0 /var/www/osticket/upload/api/cron.phpnow it works!output  grep cron /var/log/syslog:May 29 14 OSSERVER CRON: (root) CMD (sudo -u www-data /usr/bin/php7.0 /var/www/osticket/upload/api/cron.php)

The documentation at the wiki  is not correct/outdated.It states: The PHP CLI executable is called to run cron.php.Add the following entry to cron file normally in /etc/crontab in *nix systems and adjust: the time; the webuser; and paths accordingly.

*/5 * * * * nobody /path/to/php /path/to/api/cron.php

So what do you think is wrong with the wiki entry?

Shouldn't it be like this?*/5 * * * * sudo -u nobody /path/to/php /path/to/api/cron.php(fyi I'm working with Ubuntu, don't know how cron differs from other distributions)

That might be an Ubuntu thing... but i do not do that on my Debian installation (and Ubuntu is built on top of Debian last I checked).  I've never had to do that.  I've always just changed nobody to my apache user.

Glad you say so. I also thought you never need to use sudo -u in crontab but then I stumbled upon this post  and gave it a try and surprisingly, it worked for me. From the ubuntu wiki:00 01 * * * rusty /home/rusty/rusty-list-files.shThis would run Rusty's command script as user rusty from his home directory. However, it is not usual to add commands to this file. While an experienced user should know about it, it is not recommended that you add anything to /etc/crontab. Apart from anything else, this could cause a problem if the /etc/crontab file is affected by updates! Rusty could lose his command.

So this states you don't need to add sudo -u ideed but only put the username in front..Not sure what is what and what now...Only thing I'm sure is that it's working now. I'll give it a try on my test Osticket server (which I used another ubuntu version for it). I'll keep you informed what's working there.krwouter

Well adding sudo before it means that the command is being run with escalated privileges (and not as your Apache user).But anyway, I'll leave this open feel free to update it if you have more to report.

9 days later

Not exactly;sudo with option -u means it runs the command as the specified user. From the man of sudo:-u userThe -u (user) option causes sudo to run the specified command as a user other than root. To specify a uid instead of a user name, use #uid. When running commands as a uid, many shells require that the '#' be escaped with a backslash ('\'). Security policies may restrict uids to those listed in the password database. The sudoers policy allows uids that are not in the password database as long as the targetpw option is not set. Other security policies may not support this.I've done the following test by adding these two lines to my crontab:#*/1 * * * * www-data echo 'test' > /home/test1.txt#*/1 * * * * sudo -u www-data echo 'test' > /home/test1.txtBut both files have root as owner, but not sure wether this test is representative for this problem.

Write a Reply...