drush
drush copied to clipboard
drush-ops
drush sqlc < does not work.
drush sqlc command takes me to the sql command prompt rather than importing the sql file.
In our setup, I am logged in via SSH to run drush sqlc there. We have several DBs linked up with galera cluster with MariaDB 10.4.11 . We found that we could import the db with 9.6.2 by replacing all the set autocommit=0 to be set autocommit=1 from a mysql dump from drush. e.g. drush sql-dump > test.sql
I ran drush sql-dump > test.sql (this ran successfully) sed replaced all autocommit=0 to be autocommit=1 then I ran drush sqlc < test.sql
I expected this to import the sql file like it did in version 9.6.2
Instead, it sent me to the sql command prompt.
Drush version: 10.2.0 Drupal version: 8.7 PHP version: 7.3.14 OS: CentOS
I've certainly seen funkiness with sql:cli in the past:
- https://github.com/drush-ops/drush/issues/4092
- https://github.com/drush-ops/drush/issues/4197
The failure modes in those cases were either hanging on failure or silently failing. I've never seen it drop into the SQL shell, and we now have an automated test to catch those failures, so I suspect this new issue is something else.
I'm not able to reproduce this on Ubuntu, maybe it's a CentOS thing? What's the full command you are running and output with --debug? Are you using an alias, specifically over SSH? If so, can you reproduce the same behavior without the alias?
I am researching this a bit more, and will give you the requested information.
EDIT: To be sure it is known, we did this to the sql file as mentioned in the first (albiet edited) comment:
In our setup, I am logged in via SSH to run drush sqlc there. We have several DBs linked up with galera cluster with MariaDB 10.4.11 . We found that we could import the db with 9.6.2 by replacing all the set autocommit=0 to be set autocommit=1 from a mysql dump from drush. e.g. drush sql-dump > test.sql
@danepowell I have edited the first comment above. My --debug output is as follows:
drush sqlc < sqlfile.sql
[preflight] Config paths: /var/www/html/vendor/drush/drush/drush.yml,/var/www/html/drush/drush.yml
[preflight] Alias paths: /var/www/html/web/drush/sites,/var/www/html/drush/sites
[preflight] Commandfile search paths: /var/www/html/vendor/drush/drush/src,/var/www/html/drush
[debug] Starting bootstrap to max [0.07 sec, 8.41 MB]
[debug] Drush bootstrap phase: bootstrapDrupalRoot() [0.07 sec, 8.41 MB]
[debug] Change working directory to /var/www/html/web [0.07 sec, 8.41 MB]
[debug] Initialized Drupal 8.7.11 root directory at /var/www/html/web [0.07 sec, 8.54 MB]
[debug] Drush bootstrap phase: bootstrapDrupalSite() [0.08 sec, 8.84 MB]
[debug] Initialized Drupal site default at sites/default [0.08 sec, 9.07 MB]
[debug] Drush bootstrap phase: bootstrapDrupalConfiguration() [0.08 sec, 9.07 MB]
[debug] Add service modifier [0.09 sec, 9.59 MB]
[info] Executing: command -v mysql [0.09 sec, 10.05 MB]
[info] Executing: mysql --defaults-file=/tmp/drush_(some random chars here) --database=d8db --host=(ip here) --port=(port here) -A [0.1 sec, 10.11 MB]
Welcome to the MariaDB monitor. Commands end with ; or \g.
Your MariaDB connection id is 3864
Server version: 10.4.11-MariaDB MariaDB Server
Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
MariaDB [d8db]>
Tried all the 10.x versions back to 10.0.0 but couldn't get it to work. I tried to downgrade to 9.x but then drush won't work at all and I get a different error "TypeError: Argument 4 passed to Drush\Drupal\Commands\config\ConfigImportCommands::__construct() must implement interface Drupal\Core\Extension\ModuleHandlerInterface".
Maybe someone who can reproduce this could do a git bisect between 9.6.2 and 10.2.0 and see where the behavior changed.
@greg-1-anderson here is the result of the git bisect
dda3993778f6d81e339d1ae7f0b1c8e18cc9b573 is the first bad commit
commit dda3993778f6d81e339d1ae7f0b1c8e18cc9b573
Author: ****
Date: Tue Apr 9 13:57:13 2019 -0700
Fix TTY detection for runserver command. (#4033)
:040000 040000 8e3ff352f57b0c96ba1fccc77bc79b7a94797175 86b73d1fdb80f4dc0f19bfdc8ecc3298aaa611af M .scenarios.lock
:100644 100644 48407d9fbf30b99ca15c7738b5685dd009782c74 37a83ee6b683b126d98965ca53546c87cf966c27 M composer.json
:100644 100644 099c42680e0faa539c0143ff5059db9e4aa3db22 5de3b9eefbc66e7a3d84207d4c6b1eb1b924cfaa M composer.lock
:040000 040000 8b75248db74c6a7eb51fc3d97378f0178de35d86 346b597507ec0e8aec5cdb91321e9349d45fbc14 M src
@weitzman We are also running into this issue on drush-8.3.5. We upgraded recently from 8.1.16 where this was not a problem.
@kindlehl Drush 8.x doesn't use any of this code, so the problem must be unrelated. If you could test with git bisect and determine which commit on the 8.x branch caused the problem you are seeing, then we can track it down separately.
@golddragon007 I am wondering if perhaps dda3993 is just a do-over. It seems that the intention of this commit was to move away from using the posix commands to detect tty capability, and instead use the Symfony libraries, if available. However, it seems to me that the old code did something different than the new code. The old code specifically checked to see if stdin was connected to a tty. Drush used this check to determine whether stdin should be redirected or not. The Symfony functions do not appear to be equivalent; they are not specifically about STDIN. The comment on the Symfony function says:
Returns whether TTY is supported on the current operating system.
That's not the same thing.
A workaround: drush sql-sync --no-dump --source-dump=<sql_file> @self @self
@greg-1-anderson
@kindlehl Drush 8.x doesn't use any of this code, so the problem must be unrelated. If you could test with
git bisectand determine which commit on the 8.x branch caused the problem you are seeing, then we can track it down separately.
It looks like drush 8.3.5 is picking up on a site-local installation of drush 10.3.0 and using that, causing this issue in my case. I was not aware of this functionality, but I can replicate this issue for version 10.3.0
@kindlehl: See my comment to @golddragon007 above regarding the bug in Drush 10. Maybe @danepowell can help here as well.
@greg-1-anderson I don't know how much it is a do-over or not, but definitely it breaks for me and that's the first commit that didn't work for me. Therefore if it was a rework, then it wasn't 100% equal. What I can tell you, however, if you are running in docker this, this is not an issue as far as I heard from my colleagues, however, from LAMP stack when everything is in the local machine, and you have project base defined drush installed by composer and pulled in by drush launcher, this happens.
Yes; what I mean by a "do-over" is that it did not do what it was supposed to do, or more specifically, the new code is not making the same check as the old code was, which changes the intention of the code.
I just tested this by redoing the changes from that commit and it still is broken. Also, this doesn't happen in our production environment on php 7.2.31 with drush 10.3.0. It happens in non-live where we run php 7.2.28 and drush 10.3.0. There are some other differences such as the version of the mysql driver, etc. I tried testing under php 7.2.26 and it still failed.
I mentioned above that this came from an upgrade from 8.1.16 to 8.3.5, but that also came along with fundamental changes to php configuration and other things, and I'm leaning towards thinking that is what is caused this to break. I gutted the php configuration on the VM and applied the old configuration, kept my local modified drush 10.3.0 installation, and it now works. :shrug:
I'm not sure, very confused.
@golddragon007 The issue on our end was the lack of the php posix extension. On IUS, install php72u-process was good enough to solve this issue. Can you verify that you have a similar problem?
@greg-1-anderson would you support adding a warning on POSIX OS's if the POSIX extension is not installed?
@kindlehl Well, it's not a 100% solution as I see. I've installed the php73-php-process and php73-process packages. Now it doesn't jump into the console if I through some data to it. However, if there is an import error, then it doesn't jump out.
$ drush sqlc < dump.sql
The error shows up here...
After the error, it just hangs and you need to kill it with ctrl + c.
$ zcat dump.sql.gz | drush sqlc
Even if an error happens, it doesn't display it and it hangs till you kill it with ctrl + c. However, I don't remember if this was the original how it worked in the past or not. So maybe legit working solution actually.
And actually, as I'm testing now, $ zcat dump.sql.gz | drush sqlc is epic slow compared to the 'original' way of working.
@kindlehl: @weitzman just removed a bunch of php configuration validation checks (not POSIX) that were not firing often/ever. Since POSIX is important to Drush, though, perhaps a PR to check for it in preflight or invoke would be welcome.
I think the point of dda3993 was to make Drush work better without POSIX, but I think it might have made things worse. Still not sure.
Hello,
I ran into this bug too. I was upgrading from 9.6.2 to 10.3.4.
Drush version: 10.3.4 Drupal version: 8.9.6 PHP version: 7.2.25 OS: CentOS 7
I downgraded Drush to 10.3.0: same problem 9.7.2: same problem 9.6.2: ok
I ran into this problem very recently. @rsanzante replied to this closed issue in https://github.com/drush-ops/drush/issues/3859#issuecomment-736539002. He identified sqlc as failing to accept STDIN and that there were a couple diffs that never made it into the codebase. On the latest 10.3.6 provided by composer require drush/drush:10.x I can replicate the failure. As well, per my comment linked below in that issue, when I apply diff https://github.com/drush-ops/drush/commit/9a03ed80412fd1c2113fd8392c50b1846bd5ef2e as a patch, my STDIN functionality for sqlc is restored. I see this is the only remaining issue opened for sqlc STDIN failure, so I added a comment here. Please be sure to read the two comments above the last one I linked as I am not sure if there is any need for the second diff he linked or if my anecdotal success is safe to rely on to conclude the change as ideal. I plan to simply apply that patch to the latest 10.3.6 until I see this issue closed. Thanks!
Source comment on closed issue: https://github.com/drush-ops/drush/issues/3859#issuecomment-751504751
FWIW I noticed this commit for Composer https://github.com/composer/composer/commit/14962776971e753b31a062783ad758ed0e8dde24. See the PR linked from there.
We're running into this as well, specifically when importing into a cluster that puts an upper limit on transaction sizes. Error reported during drush sqlc < dump.sql:
ERROR 1180 (HY000) at line 23703: Got error 5 "Input/output error" during COMMIT
The problem is also outlined here.
ISTM this is due to Drush\Sql\SqlMysql::dumpCmd() adding --no-autocommit as an extra parameter (which is not safe for large transactions!)
@meanderix we're running into the same problem, same sort of setup. Have you found a way to fix this yet?
The issue on our end was the lack of the php posix extension
I can confirm the same issue on Centos, running sudo yum install php-process fixed the issue for me.
For debugging purposes, here is some outputs sudo yum list installed | grep php and php -m (before installation of posix/process).
Debugging Output
$ sudo yum list installed | grep php
php.x86_64 8.1.18-1.el7.remi @remi-php81
php-cli.x86_64 8.1.18-1.el7.remi @remi-php81
php-common.x86_64 8.1.18-1.el7.remi @remi-php81
php-gd.x86_64 8.1.18-1.el7.remi @remi-php81
php-mbstring.x86_64 8.1.18-1.el7.remi @remi-php81
php-mysqlnd.x86_64 8.1.18-1.el7.remi @remi-php81
php-opcache.x86_64 8.1.18-1.el7.remi @remi-php81
php-pdo.x86_64 8.1.18-1.el7.remi @remi-php81
php-pecl-mcrypt.x86_64 1.0.6-1.el7.remi.8.1 @remi-php81
php-pecl-zip.x86_64 1.21.1-1.el7.remi.8.1 @remi-php81
php-sodium.x86_64 8.1.18-1.el7.remi @remi-php81
php-xml.x86_64 8.1.18-1.el7.remi @remi-php81
$ php -m
[PHP Modules]
bz2
calendar
Core
ctype
curl
date
dom
exif
fileinfo
filter
ftp
gd
gettext
hash
iconv
json
libxml
mbstring
mcrypt
mysqli
mysqlnd
openssl
pcntl
pcre
PDO
pdo_mysql
pdo_sqlite
Phar
readline
Reflection
session
SimpleXML
sockets
sodium
SPL
sqlite3
standard
tokenizer
xml
xmlreader
xmlwriter
xsl
Zend OPcache
zip
zlib
[Zend Modules]
Zend OPcache
$ cat /etc/os-release
NAME="CentOS Linux"
VERSION="7 (Core)"
ID="centos"
ID_LIKE="rhel fedora"
VERSION_ID="7"
PRETTY_NAME="CentOS Linux 7 (Core)"
ANSI_COLOR="0;31"
CPE_NAME="cpe:/o:centos:centos:7"
HOME_URL="https://www.centos.org/"
BUG_REPORT_URL="https://bugs.centos.org/"
CENTOS_MANTISBT_PROJECT="CentOS-7"
CENTOS_MANTISBT_PROJECT_VERSION="7"
REDHAT_SUPPORT_PRODUCT="centos"
REDHAT_SUPPORT_PRODUCT_VERSION="7"
$ uname -a
Linux myhostname 3.10.0-1160.6.1.el7.x86_64 #1 SMP Tue Nov 17 13:59:11 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
this (drush sqlc does not accept stdin) just happend to me on RHEL with php 8.1 and drush11; apache running php-fpm.
install php-process fixed it.
I ran into this as well with PHP 8.1 and Drush 10.6.2, on a UBI 7 system.
yum install php-process fixed the problem.
