artisan runs in the context of your project, maybe this will help http://stackoverflow.com/questions/22917116/laravel-artisan-cron-not-working

If you want to completely kill the output you have two options to redirect standard out and standard error.

$ [shell command] > /dev/null

or

$ [shell command] > /dev/null 2>&1

The first one redirects standard output to /dev/null which discards it, but doesn't discard standard error.

The second one makes your cron/shell command completely silent.

So you could change your crontab to look like this:

* * * * * cd /var/www/seat-ec && /usr/local/lib/php artisan scheduled:run > /dev/null 2>&1

Sorry for a later response, see if the cd to map works.

After 15 minutes, the logs are outputting the same: [2014-04-29 09:25:02] production.ERROR: exception 'ErrorException' with message 'Use of undefined constant STDOUT - assumed 'STDOUT'' in /var/www/seat-ec/vendor/wp-cli/php-cli-tools/lib/cli/Shell.php:51

Although, when I set in the php.ini at the option disable_functions=posix_isatty the shell error is gone but symfony throws in a 8 line error, as I do notice that when calling the Artisan menu, all colors are gone.

The front-end works like a charm it's only that this php-cli-error on the posix_isatty request kills all and wont let the framework do his job.

Try:

* * * * * cd /var/www/seat-ec && /usr/local/lib/php ./artisan scheduled:run >> artisan.log 2>&1

After you do that check the artisan.log file in /var/www/seat-ec.

Also double check your php path:

$ whereis php

If none of that works try this:

* * * * * cd /var/www/seat-ec && /usr/local/lib/php -r 'if( !defined("STDOUT") ) define("STDOUT", fopen("php://stdout","w")); require_once("./artisan");' scheduled:run  >> artisan.log 2>&1

That's really a hack to define STDOUT, but it might work.

Run this too to see if PHP is perhaps running in CGI mode:

$ php -v

/usr/lib/php is just a directory, the CLI is located in /usr/local/bin/php and when doing -v it say's (cli) 5.4.27 (cgi version is in /usr/bin/)

I even did the move from /var/www/ to /home/<userdir>/seat-ec/... in case of apache's interference and security checks as to even tripple checked all corresponding directories. Although, I included that directory to make it a valid directory to work with.php

But I've found out that the Shell is piped

[quote] [2014-04-30 10:00:04] production.ERROR: exception 'ErrorException' with message 'Use of undefined constant STDOUT - assumed 'STDOUT'' in /home/tohacong/seat-ec/vendor/wp-cli/php-cli-tools/lib/cli/Shell.php:57 Stack trace: #0 /home/tohacong/seat-ec/vendor/wp-cli/php-cli-tools/lib/cli/Shell.php(57): Illuminate\Exception\Handler->handleError(8, 'Use of undefine...', '/home/tohacong/...', 57, Array) #1 /home/tohacong/seat-ec/vendor/wp-cli/php-cli-tools/lib/cli/Table.php(69): cli\Shell::isPiped() [/quote] After applying a "certain fix" found on the php-cli-tool dev site

Okay, let's think out of the Box now... that Shell requires SSH right, considering phpseclib is getting used. Considering, I need a key to ssh into my server as either root or the assigned user. Even though I added apache and nobody to the wheel group, I can't sure if the same counts for bash/ssh Looking at the fact, I preform via my client: scheduled:run en do that every minute to even every 5 minutes,I don't get any error output

so, my question would be: Where can I can specificy to use a specific key and user?

^^ that should probably solve my problem

If shell is being piped for some reason, meaning the script is being read from stdin, the "STDOUT" PHP constant won't be available, check "Note" http://www.php.net/manual/en/features.commandline.io-streams.php

That's probably the reason.

Try:

* * * * * cd /var/www/seat-ec && /usr/local/bin/php ./artisan scheduled:run >> artisan.log 2>&1

Or:

* * * * * cd /var/www/seat-ec && /usr/local/bin/php -r 'if( !defined("STDOUT") ) define("STDOUT", fopen("php://stdout","w")); require_once("./artisan");' scheduled:run  >> artisan.log 2>&1

In regards to permissions, I believe the crons run in whatever user you created them in. So if you were root and you did crontab -e those crons would run under the root user. If you ran crontab under the apache user using su apache, then that cron would be run as apache. If your files are owned by apache ls -l, then you want to create the crontab under the apache user. It looks like you got all that covered because the error you're getting is about STDOUT not some 'cannot open file error'. I'd look more into the piping to see if that's the main cause. So far I think that's the best lead.