In Process.php line 1019: TTY mode requires /dev/tty to be read/writable

[jonathan1055]

Describe the bug In drush11 trying to run drush runserver gives me

In Process.php line 1019:
  TTY mode requires /dev/tty to be read/writable.  

This is exactly what was reported in #4015 and the discussion there suggested it was fixed.

To Reproduce Fails in drush11. But runs fine in drush10

System Configuration

Q	A
Drush version?	11.4
Drupal version?	10.x
PHP version	8.1
OS?	Mac

This is a support request, as I expect the bug was fixed before. Thanks

[weitzman]

Any chance you are using Drush Launcher instead of calling vendor/bin/drush directly? I cant reproduce this on OSX.

[weitzman]

maybe share output of drush status and composer show

[jonathan1055]

Thanks for the reply. I was using the drush launcher, but the same happens when I try vendor/bin/drush runserver Are there other ways I can try to run it? As I said, drush10 on a drupal 9.5 works fine, but drush 11 on a D10 environment fails.

drush status

Drupal version   : 10.0.1-dev                                                       
Site URI         : http://default                                                   
DB driver        : mysql                                                            
DB hostname      : localhost                                                        
DB port          :                                                                  
DB username      : drupal10                                                         
DB name          : drupal100dev                                                     
Database         : Connected                                                        
Drupal bootstrap : Successful                                                       
Default theme    : olivero                                                          
Admin theme      : seven                                                            
PHP binary       : /usr/local/Cellar/php/8.1.10/bin/php                             
PHP config       : /usr/local/etc/php/8.1/php.ini                                   
PHP OS           : Darwin                                                           
PHP version      : 8.1.10                                                           
Drush script     : /Library/WebServer/web/drupal100dev/vendor/drush/drush/drush     
Drush version    : 11.4.0                                                           
Drush temp       : /tmp                                                             
Drush configs    : /Library/WebServer/web/drupal100dev/vendor/drush/drush/drush.yml 
Install profile  : standard                                                         
Drupal root      : /Library/WebServer/web/drupal100dev                              
Site path        : sites/default                                                    
Files, Public    : sites/default/files                                              
Files, Temp      : /tmp   

I also get at the end of the status call the following:

PHP Fatal error:  Cannot redeclare composerRequiree96ef5ed469e804f25c286ba9f7e7584()
(previously declared in /Library/WebServer/Web/drupal100dev/vendor/composer/autoload_real.php:54)
in /Library/WebServer/web/drupal100dev/vendor/composer/autoload_real.php on line 54

composer show _composer_show.txt

[weitzman]

Your output looks OK to me. Its not clear to me whats going on.

[jonathan1055]

Just tried vendor/bin/drush runserver --no-interaction --debug (from the linked issue)

[jonathan1055]

It gives more detail, but not sure if it will show anything.

[jonathan1055]

_runserver_debug.txt

[jonathan1055]

symphony process.php has

    /**
     * Returns whether TTY is supported on the current operating system.
     */
    public static function isTtySupported(): bool
    {
        static $isTtySupported;
        return $isTtySupported ??= ('/' === \DIRECTORY_SEPARATOR && stream_isatty(\STDOUT));
    }

[jonathan1055]

Fails in

   public function setTty(bool $tty): static
    {
        if ('\\' === \DIRECTORY_SEPARATOR && $tty) {
            throw new RuntimeException('TTY mode is not supported on Windows platform.');
        }
        if ($tty && !self::isTtySupported()) {
            throw new RuntimeException('TTY mode requires /dev/tty to be read/writable.');
        }
        $this->tty = $tty;
        return $this;
    }

[jonathan1055]

I've got around it temporarily by commenting out the exception line :-) but obviosuly that's not a sustainable solution

[weitzman]

In https://github.com/drush-ops/drush/blob/11.x/src/Commands/core/RunserverCommands.php#L80, does isTtySupported() return TRUE? If so, why does consolidation/site-process (thats where Tty class lives) think you have support where Symfony Process thinks you dont.

[jonathan1055]

OK I will try to check that.

Dumb question: The exception says "TTY mode requires /dev/tty to be read/writable". Is this referring simply to the /dev/tty folder? ls -la /dev/tty gives: crw-rw-rw- 1 root wheel 2, 0 4 Jan 10:22 /dev/tty

[jonathan1055]

Yes, in runserverCommands, runserver function line 80 Tty::isTtySupported() returns TRUE (1)

Then setTty() is called and in https://github.com/symfony/symfony/blob/6.3/src/Symfony/Component/Process/Process.php#L1012 on line 1018 we have self::isTtySupported() but this returns FALSE (blank) and thus the exception is thrown.

In https://github.com/symfony/symfony/blob/6.3/src/Symfony/Component/Process/Process.php#L1203 isTtySupported() line 1027 stream_isatty(\STDOUT) returns FALSE which is the reason for the problem, I think.

[jonathan1055]

To answer your second question, in https://github.com/consolidation/site-process/blob/main/src/Util/Tty.php#L16 on line 19 the function posix_isatty does exist, so the return is set from calling posix_isatty(STDIN) which gives TRUE

Is that the difference? This is testing STDIN whereas in symfony process isTtySupported(), the check is on stream_isatty(\STDOUT)

[weitzman]

@greg-1-anderson any ideas?

[pameeela]

This same thing is happening to me, only on sites where I have updated to D10. Tried updating drush from 10 to 11 but still the same issue. Relieved that I am not the only one!

It only happens when using drush on my local machine to access remote sites, e.g. drush @site.env cr

If I add tty: false to my drush config, then I can run most commands, but still can't ssh via drush because I get tty error.

[jonathan1055]

Hi, I don't know if this will fix your problem, but I modified site-process/src/Util/Tty.php changing return posix_isatty(STDIN) to return posix_isatty(STDOUT);

Patch attached, in case you want to try it. _site_process_tty.patch

[pameeela]

Thanks for that. Interestingly, it does work to suppress the error, but if I try drush @site.env ssh it runs without error but the ssh session does not start.

However, if I modify Process.php to comment out the exception, then it works just fine.

Also, I recently got a new laptop and set up everything from scratch assuming that I would be rid of this but... it's still happening. So I guess it's something specific in how I'm setting everything up. Still seems really odd we could be the only two people who've hit this with D10 but certainly seems that way!

[mhariip]

Thanks for that. Interestingly, it does work to suppress the error, but if I try drush @site.env ssh it runs without error but the ssh session does not start.

However, if I modify Process.php to comment out the exception, then it works just fine.

Also, I recently got a new laptop and set up everything from scratch assuming that I would be rid of this but... it's still happening. So I guess it's something specific in how I'm setting everything up. Still seems really odd we could be the only two people who've hit this with D10 but certainly seems that way!

You are not alone. I have this very same issue with D10 Site aliases. Hope this issue will be resolved soon.

[idiazroncero]

Same problem here with D10 site aliases and Drush 11.6, both with Drush Launcher and vendor/bin/drush

[joegl]

I'm having the same problem with Drush 9, 10 and 11 on any remote D10 site. My local aliases still work fine.

Interestingly, this only started happening to me once I added (and then removed) the drupal-check package

[greg-1-anderson]

Just noticed this issue; didn't see the mention earlier. If folks who are having this problem run:

php -r 'var_export(stream_isatty(\STDOUT));'

Do you get true or false? I get true on my system; I would expect from the comments above that the problem is caused when stream_isatty returns false for STDOUT. I am not sure what would cause that.

[joegl]

I get true on my system when I run:

php -r 'var_export(stream_isatty(\STDOUT));'

But I also may have a unique set up causing my issue.

[greg-1-anderson]

It only happens when using drush on my local machine to access remote sites, e.g. drush @site.env cr

I missed this critical bit if information! Take a look at your ssh config, and see if it is configured to allow a tty to be allocated. In some configurations, ssh does not do this, because a tty is an exhaustible resource, and not every remote command needs a tty.

Check and see if behavior is any different if you run Drush in non-interactive mode (-n).

[joegl]

Drush works when I use the non-interactive mode (-n) so you're definitely on to something. What are you referring to when you say "look at your ssh config"? Something in /etc/ssh/ssh_config or a drush SSH configuration? Thanks!

[greg-1-anderson]

I don't know ssh config off the top of my head; I just know that if I ssh from my Mac to an Ubuntu box, I get a tty, but if I ssh to a Pantheon container, I don't, because Pantheon has configured sshd to not allocate tty's.

When you run Drush in non-interactive mode, it skips the tty check and behaves as if you were running without a tty, so this avoids any inconsistency with the tests to determine whether or not a tty is available. Ideally, Drush would figure it out and do the right thing, but at least there is this workaround.

[pameeela]

@greg-1-anderson ok interesting, so using -n works but only for non-ssh commands, e.g. : drush -n @site.dev cr works (where it doesn't without -n) but drush -n @site.dev ssh still results in TTY mode requires /dev/tty to be read/writable. So the same result as adding tty: false to the drush ssh config (noted a few months back that adding that to the drush config allows me to run other commands but ssh still fails).

I've just worked around this by either using ssh directly (adding the config and running ssh dev.site) or using lando drush to run the ssh command. I am still keen to resolve it just out of stubbornness.

[pameeela]

Was just thinking it might be down to the ssh options in my drush config, but I don't think that's it because even if I break the config, the command fails with TTY mode requires /dev/tty to be read/writable. before it hits the broken config.

[greg-1-anderson]

Sounds like the ssh command requires a tty, although I don't specifically remember, and in theory this should not be necessary. Does drush -n @site.dev ssh pwd behave the same way, or does it work?

[pameeela]

Yes, that works. I've only just noticed though that when I run any drush command that way, it actually runs twice. That doesn't happen if I run the same command via Lando. Same version of drush (11.6.0), same config.

pamelabarone@site % drush @site.dev ssh pwd
/app/site/web /app/site/web

So there's obviously something else strange going on with this setup. I found a few old issues where people had the same issue of commands running twice but they are all very old and look to have been resolved. Now leaning toward giving up on this considering I have workarounds! Wonder whether any others are finding the same.