I was expecting / hoping that drush @sites cron --quiet --yes would not generate output, but it does:

$ drush @sites cron --quiet --yes
You are about to execute 'cron' non-interactively (--yes forced) on all of the following targets:
  /var/www/site#one
  /var/www/site#two
Continue?  (y/n): y
Cron run successful.

It seems logical to me to suppress the interactive questions when --quiet and --yes are combined. I did find a couple of issues about the --quiet option but they're all fixed and closed. Is the behavior above correct and by design?

Comments

moshe weitzman’s picture

moshe weitzman commented
Assigned: Unassigned » greg.1.anderson
greg.1.anderson’s picture

greg.1.anderson commented

It looks like --quiet is not passed through on a multisite operation (hence 'cron run successful). We could make --quiet auto-confirm the multisite prompt without output. I am reluctant to make --quiet a global option that suppresses all stdout output, but I don't know why; maybe that is how it should behave.

marcvangend’s picture

marcvangend
he/him
Primary language Dutch
Location Amsterdam
commented

Thanks Greg. I don't know much about drush's internals, so I just speaking as an end user here. IMHO, the most logical behavior for the --quiet option would be that it suppresses all output except error messages and interactive stuff. When combined with --yes, I would expect it to suppress interactive stuff as well. Just my €0.02.

mrharolda’s picture

mrharolda commented
Version: » 7.x-5.8

Can anyone give me a pointer how to run drush cron on a multi-site environment without being spammed every cron run? If I redirect alle STDERR to STDOUT using 2>&1, I also lose all errors and warnings so that's not an option.

Wrong command:
find /var/www -name cron.php -execdir sh -c "/usr/bin/drush -y --quiet --concurrency=1 @sites cron 2>&1;" \; > /dev/null

greg.1.anderson’s picture

greg.1.anderson commented

See drush topic docs-cron. Drush cron can be quiet if you run it once per site. As mentioned above, it is not quiet if run with @sites.

mrharolda’s picture

mrharolda commented

Greg, we run on average of 50 sites per server. Adding each site manually to cron is not only a lot of work, it's prone for a lot of errors too (forgotten/obsolete/etc), not to mention the concurrency which is perfectly managed using @sites.

The @sites method could work just fine, but unfortunately all messages are written to STDERR instead of only the warnings and/or errors. Maybe that's the real "bug"?

greg.1.anderson’s picture

greg.1.anderson commented

You could run a shell script that found all of your sites, and called each one via drush cron, passing in the correct --root and --uri. You'd want to search for settings.php (which exists one per site) rather than cron.php, although you'd have to trim the path. If your script ran drush cron with &, you would also get concurrency.

If you went this route, you should find that drush cron --quiet is quiet enough.

mrharolda’s picture

mrharolda commented

Getting concurrency is not a problem, limiting is. We don't want 50 cron jobs starting at the same time, we want them with a maximum concurrency of 3 ...

I still don't understand why someone who uses drush cron --quiet @sites should expect that the result isn't quiet. Seems like a bug/unexpected behavior to me ...

greg.1.anderson’s picture

greg.1.anderson commented

It is a bug. That is why this bug report is open. Patches are welcome.

mrharolda’s picture

mrharolda commented

Is the bug that all messages are written to STDERR instead of only the non-success messages, or that --quiet isn't passed when using @sites? Or both? ;)

greg.1.anderson’s picture

greg.1.anderson commented

--quiet does not prevent certain interactive message, such as the confirmation message you get when running commands on multiple sites with the @sites alias.

mrharolda’s picture

mrharolda commented

From your profile: Drush (666 commits) ;)

I'll try to look into it, I guess passing the --quiet option is the first candidate for a fix?

greg.1.anderson’s picture

greg.1.anderson commented

When a user specified --quiet, Drush will set a context; it's DRUSH_QUIET, or something like that. Probably set in bootstrap.inc. Take a look at the functions drush_confirm, drush_choice, etc., which might be in drush.inc. If the QUIET context is set, exit with a default selection without producing any output.

Thanks for your help here.

greg.1.anderson’s picture

greg.1.anderson commented
Version: 7.x-5.8 » 8.x-6.x-dev
Status: Active » Closed (won't fix)
Issue tags: +Needs migration

This issue was marked closed (won't fix) because Drush has moved to Github.

If desired, you may copy this bug to our Github project and then post a link here to the new issue. Please also change the status of this issue to closed (duplicate).

Please ask support questions on Drupal Answers.

mrharolda’s picture

mrharolda commented
Status: Closed (won't fix) » Closed (duplicate)

Moved to github: https://github.com/drush-ops/drush/issues/81