x-yuri

x-yuri

Member Since 10 years ago

Experience Points
3
follower
Lessons Completed
0
follow
Lessons Completed
9
stars
Best Reply Awards
59
repos

129 contributions in the last year

Pinned
⚡ Debugging in Ruby 2
⚡ Our goal is to operate this CDN in a peer reviewed fashion.
⚡ phpThumb() - The PHP thumbnail generator
⚡ A PHP Framework For Web Artisans
⚡ Really fast deployer and server automation tool.
Activity
Jan
23
4 days ago
Activity icon
issue

x-yuri issue sharkdp/fd

x-yuri
x-yuri

Is `-tf -td -tl -ts -tp` always true?

What version of fd are you using? fd 8.3.0

I'm trying to exclude sockets so that tar wouldn't complain. And pipes since I don't need them. Should I use -tf -td -tl?

Activity icon
issue

x-yuri issue comment sharkdp/fd

x-yuri
x-yuri

Is `-tf -td -tl -ts -tp` always true?

What version of fd are you using? fd 8.3.0

I'm trying to exclude sockets so that tar wouldn't complain. And pipes since I don't need them. Should I use -tf -td -tl?

Jan
18
1 week ago
Activity icon
issue

x-yuri issue comment cli/cli

x-yuri
x-yuri

`pr create` asks for a password and fails

Describe the bug

It asks for a password when creating a pr, although, as it says itself, password authentication was removed.

$ gh --version
gh version 2.4.0 (2021-12-21)
https://github.com/cli/cli/releases/tag/v2.4.0

Steps to reproduce the behavior

  1. Clone a repository (git clone https://github.com...).
  2. gh repo fork, make a branch, do some changes, commit.
  3. gh pr create.

Expected vs actual behavior

I expected it to create a pr w/o asking for a password. Instead it asked for a password and failed. I was able to work around it by switching to git in .git/config, but it'd be great if it didn't try to use password authentication, especially since it doesn't support it.

Logs

$ git clone https://github.com/cli/cli
$ cd cli
$ gh repo fork
$ git checkout -b b1
$ echo a > a
$ git add a
$ git commit -m b1
$ gh pr create
? Where should we push the 'b1' branch? x-yuri/cli

Creating pull request for x-yuri:b1 into master in docker/cli

? Title Don't ask for a password
? Body <Received>
? What's next? Submit
Username for 'https://github.com': x-yuri
Password for 'https://[email protected]':
remote: Support for password authentication was removed on August 13, 2021. Please use a personal acc
ess token instead.
remote: Please see https://github.blog/2020-12-15-token-authentication-requirements-for-git-operations/ for more information.
fatal: Authentication failed for 'https://github.com/x-yuri/cli.git/'

X operation failed. To restore: gh pr create --recover /tmp/gh468042586.json

exit status 128
x-yuri
x-yuri

Oh, I see, I have git_protocol: https in ~/.config/gh/config.yml. So supposedly I chose https. And probably because generally I start with it, in case I'm not going to make a PR.

And supposedly git_protocol affects gh repo clone, and gh repo fork. In the latter case only the new remote is affected.

Consider adding the config location, and what is affected by git_protocol to the docs.

Activity icon
issue

x-yuri issue comment erikogan/wait4ports

x-yuri
x-yuri

it doesn't sleep 1 second by default

This lines takes no effect:

https://github.com/erikogan/wait4ports/blob/v0.3.1/main.c#L35

sleep_seconds are overridden in any case:

https://github.com/erikogan/wait4ports/blob/v0.3.1/main.c#L73

x-yuri
x-yuri

A little follow-up. Available since Alpine Linux 3.14.

Activity icon
issue

x-yuri issue comment cli/cli

x-yuri
x-yuri

`pr create` asks for a password and fails

Describe the bug

It asks for a password when creating a pr, although, as it says itself, password authentication was removed.

$ gh --version
gh version 2.4.0 (2021-12-21)
https://github.com/cli/cli/releases/tag/v2.4.0

Steps to reproduce the behavior

  1. Clone a repository (git clone https://github.com...).
  2. gh repo fork, make a branch, do some changes, commit.
  3. gh pr create.

Expected vs actual behavior

I expected it to create a pr w/o asking for a password. Instead it asked for a password and failed. I was able to work around it by switching to git in .git/config, but it'd be great if it didn't try to use password authentication, especially since it doesn't support it.

Logs

$ git clone https://github.com/cli/cli
$ cd cli
$ gh repo fork
$ git checkout -b b1
$ echo a > a
$ git add a
$ git commit -m b1
$ gh pr create
? Where should we push the 'b1' branch? x-yuri/cli

Creating pull request for x-yuri:b1 into master in docker/cli

? Title Don't ask for a password
? Body <Received>
? What's next? Submit
Username for 'https://github.com': x-yuri
Password for 'https://[email protected]':
remote: Support for password authentication was removed on August 13, 2021. Please use a personal acc
ess token instead.
remote: Please see https://github.blog/2020-12-15-token-authentication-requirements-for-git-operations/ for more information.
fatal: Authentication failed for 'https://github.com/x-yuri/cli.git/'

X operation failed. To restore: gh pr create --recover /tmp/gh468042586.json

exit status 128
x-yuri
x-yuri

Can you tell us about what switching to git means in this context?

I mean switching from the https to the git protocol:

url = https://github.com/cli/cli -> url = [email protected]:cli/cli.git

I believe I did gh auth login. If it changes ~/.gitconfig, I might have replaced it afterwards, but I think I'd notice if it was already there.

Activity icon
issue

x-yuri issue comment docker/compose

x-yuri
x-yuri

Don't SetRawTerminal() when exec is run with -T

What I did

Made it not put the terminal into raw mode.

Related issue

Fixes #9086.

(not mandatory) A picture of a cute animal, if possible in relation with what you did

https://giphy.com/gifs/cW64pEEZe0YZa

x-yuri
x-yuri

@ndeloof I think I'm done. By the way, --signoff, at least in my git.

push

x-yuri push x-yuri/compose

x-yuri
x-yuri

Don't SetRawTerminal() when exec is run with -T

Signed-off-by: Yuri Kanivetsky [email protected]

commit sha: a8eab48e4fed2d62a6c5da2af580749ecb1c1ad0

push time in 1 week ago
Activity icon
issue

x-yuri issue cli/cli

x-yuri
x-yuri

`pr create` asks for a password and fails

Describe the bug

It asks for a password when creating a pr, although, as it says itself, password authentication was removed.

$ gh --version
gh version 2.4.0 (2021-12-21)
https://github.com/cli/cli/releases/tag/v2.4.0

Steps to reproduce the behavior

  1. Clone a repository (git clone https://github.com...).
  2. gh repo fork, make a branch, do some changes, commit.
  3. gh pr create.

Expected vs actual behavior

I expected it to create a pr w/o asking for a password. Instead it asked for a password and failed. I was able to work around it by switching to git in .git/config, but it'd be great if it didn't try to use password authentication, especially since it doesn't support it.

Logs

$ git clone https://github.com/cli/cli
$ cd cli
$ gh repo fork
$ git checkout -b b1
$ echo a > a
$ git add a
$ git commit -m b1
$ gh pr create
? Where should we push the 'b1' branch? x-yuri/cli

Creating pull request for x-yuri:b1 into master in docker/cli

? Title Don't ask for a password
? Body <Received>
? What's next? Submit
Username for 'https://github.com': x-yuri
Password for 'https://[email protected]':
remote: Support for password authentication was removed on August 13, 2021. Please use a personal acc
ess token instead.
remote: Please see https://github.blog/2020-12-15-token-authentication-requirements-for-git-operations/ for more information.
fatal: Authentication failed for 'https://github.com/x-yuri/cli.git/'

X operation failed. To restore: gh pr create --recover /tmp/gh468042586.json

exit status 128
Activity icon
created branch

x-yuri in x-yuri/compose create branch exec_T

createdAt 1 week ago
pull request

x-yuri pull request docker/compose

x-yuri
x-yuri

Don't SetRawTerminal() when exec is run with -T

What I did

Made it not put the terminal into raw mode.

Related issue

Fixes #9086.

(not mandatory) A picture of a cute animal, if possible in relation with what you did

Activity icon
fork

x-yuri forked docker/compose

⚡ Define and run multi-container applications with Docker
x-yuri Apache License 2.0 Updated
fork time in 1 week ago
Activity icon
issue

x-yuri issue comment docker/compose

x-yuri
x-yuri

Broken output with disabled pseudo-tty allocation

Broken output with disabled pseudo-tty allocation docker-compose exec -T

Steps to reproduce the issue:

  1. Docker compose config

    version: '3.5'
    
    services:
      wget:
        image: cirrusci/wget
        command: tail -f /dev/null
    
  2. Run commands

    $ docker-compose up -d
    $ docker-compose exec -T wget wget http://ipv4.download.thinkbroadband.com/1MB.zip
    

Describe the results you received:

Corrupted output:

--2022-01-05 09:35:54--  http://ipv4.download.thinkbroadband.com/1MB.zip
                                                                        Resolving ipv4.download.thinkbroadband.com... 80.249.99.148
                                                                                                                                   Connecting to ipv4.download.thinkbroadband.com|80.249.99.148|:80... connected.
                                                                                                                                                                                                                 HTTP request sent, awaiting response... 200 OK
                                                                                                                                                                                                                                                               Length: 1048576 (1.0M) [application/zip]
            Saving to: '1MB.zip'

                                     0K .......... .......... .......... .......... ..........  4%  424K 2s
                                                                                                               50K .......... .......... .......... .......... ..........  9%  811K 2s
                                                                                                                                                                                         100K .......... .......... .......... .......... .......... 14% 7.46M 1s
                                                                                                                                                                                                                                                                    150K .......... .......... .......... .......... .......... 19%  989K 1s
                                                    200K .......... .......... .......... .......... .......... 24% 6.92M 1s
                                                                                                                               250K .......... .......... .......... .......... .......... 29% 15.3M 1s
                                                                                                                                                                                                          300K .......... .......... .......... .......... .......... 34%  776K 1s
                                                                                                                                                                                                                                                                                     350K .......... .......... .......... .......... .......... 39% 7.50M 0s
                                                                     400K .......... .......... .......... .......... .......... 43% 1.49M 0s
                                                                                                                                                450K .......... .......... .......... .......... .......... 48% 2.10M 0s
                                                                                                                                                                                                                           500K .......... .......... .......... .......... .......... 53% 7.49M 0s
           550K .......... .......... .......... .......... .......... 58% 1.49M 0s
                                                                                      600K .......... .......... .......... .......... .......... 63% 2.01M 0s
                                                                                                                                                                 650K .......... .......... .......... .......... .......... 68% 3.76M 0s
                                                                                                                                                                                                                                            700K .......... .......... .......... .......... .......... 73% 2.24M 0s
                            750K .......... .......... .......... .......... .......... 78% 2.00M 0s
                                                                                                       800K .......... .......... .......... .......... .......... 83% 3.48M 0s
                                                                                                                                                                                  850K .......... .......... .......... .......... .......... 87% 3.02M 0s
                                                                                                                                                                                                                                                             900K .......... .......... .......... .......... .......... 92% 2.05M 0s
                                             950K .......... .......... .......... .......... .......... 97% 2.39M 0s
                                                                                                                       1000K .......... .......... ....                            100% 3.37M=0.6s

                                                                                                                                                                                                  2022-01-05 09:35:54 (1.73 MB/s) - '1MB.zip' saved [1048576/1048576]

Describe the results you expected:

I expect correctly formatted output the same that docker exec without tty produces

$ docker exec tty-wget-1 wget http://ipv4.download.thinkbroadband.com/1MB.zip                                                                                                                                                          

--2022-01-05 09:42:21--  http://ipv4.download.thinkbroadband.com/1MB.zip
Resolving ipv4.download.thinkbroadband.com... 80.249.99.148
Connecting to ipv4.download.thinkbroadband.com|80.249.99.148|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 1048576 (1.0M) [application/zip]
Saving to: '1MB.zip.1'

     0K .......... .......... .......... .......... ..........  4%  417K 2s
    50K .......... .......... .......... .......... ..........  9%  838K 2s
   100K .......... .......... .......... .......... .......... 14% 50.2M 1s
   150K .......... .......... .......... .......... .......... 19%  842K 1s
   200K .......... .......... .......... .......... .......... 24% 3.94M 1s
   250K .......... .......... .......... .......... .......... 29% 6.73M 1s
   300K .......... .......... .......... .......... .......... 34% 1.15M 1s
   350K .......... .......... .......... .......... .......... 39% 11.1M 0s
   400K .......... .......... .......... .......... .......... 43% 1.02M 0s
   450K .......... .......... .......... .......... .......... 48% 3.04M 0s
   500K .......... .......... .......... .......... .......... 53% 18.1M 0s
   550K .......... .......... .......... .......... .......... 58% 1.16M 0s
   600K .......... .......... .......... .......... .......... 63% 6.67M 0s
   650K .......... .......... .......... .......... .......... 68% 6.82M 0s
   700K .......... .......... .......... .......... .......... 73% 1.05M 0s
   750K .......... .......... .......... .......... .......... 78% 8.07M 0s
   800K .......... .......... .......... .......... .......... 83% 6.01M 0s
   850K .......... .......... .......... .......... .......... 87% 1.04M 0s
   900K .......... .......... .......... .......... .......... 92% 13.0M 0s
   950K .......... .......... .......... .......... .......... 97% 9.09M 0s
  1000K .......... .......... ....                            100%  597K=0.6s

2022-01-05 09:42:22 (1.70 MB/s) - '1MB.zip.1' saved [1048576/1048576]

OS: macOS 11.6.2

Docker-compose version:

  • v2.2.1 installed with docker for Mac 4.3.2
  • v2.2.2 installed with brew

It is the same bug as already closed https://github.com/docker/compose/issues/8833. The fix was released in v2.2.0 but still reproduced in v2.2.1 and v2.2.2

Jan
13
2 weeks ago
Activity icon
issue

x-yuri issue comment lxc/linuxcontainers.org

x-yuri
x-yuri

getting-started.md needs revision for cgroup preperation by fully unprivileged users

In https://github.com/lxc/linuxcontainers.org/blob/master/content/lxc/getting-started.md it is said that

Now, everything below assumes a recent Ubuntu system or another Linux distribution which offers a similar experience (recent kernel, recent version of shadow, cgmanager and default uid/gid allocation).

Just before you create your first container, you probably should logout and login again, or even reboot your machine to make sure that your user is placed in the right cgroups. (This is only required if cgmanager wasn't installed on your machine prior to you installing LXC.)

As cgmanager is considered retired, it should be updated to libpam-cgfs at least for hybrid cgroup hierarchy. In addition, it is instructed at https://github.com/lxc/lxc/issues/3242#issuecomment-568936099 to use

systemd-run --unit=myshell --user --scope -p "Delegate=yes" lxc-start

This trick for pure cgroup2 hierarchy should also be included in getting-started.md

x-yuri
x-yuri

I also came here because of this part:

Running unprivileged containers as an unprivileged user only works if you delegate a cgroup in advance (the cgroup2 delegation model enforces this restriction, not liblxc). Use the following systemd command to delegate the cgroup:

systemd-run --unit=myshell --user --scope -p "Delegate=yes" lxc-start <container-name>

I'm not sure if it's out of place, but:

  1. It's confusing. Originally I thought that I have to first execute this command. And only after that I can create/start containers. But it appears that this is a command to start a container. From what I can see after some googling, it creates a transient user scope unit named myshell, allowing it to manage cgroups (a private subhierarchy), and launches lxc-start ... there.
  2. It works w/o it (e.g. Debian 8, lxc-2.0.7).

So I'd suggest e.g. the following wording:

Running unprivileged containers as an unprivileged user only works if you delegate a cgroup (the cgroup2 delegation model enforces this restriction, not liblxc). Use the following command to start a container delegating it the cgroup:

After the command it can be added that:

It creates a transient user scope unit named myshell, allowing it to manage cgroups (a private subhierarchy), and launches lxc-start ... there.

By the way, lxc-start <container-name> -> lxc-start -n <container-name>. And double quotes are not needed.

Jan
11
2 weeks ago
Activity icon
issue

x-yuri issue comment neovim/neovim

x-yuri
x-yuri

Fix possible misplaced cursor after :map expr (Issue #12707)

My attempt at tackling issue: https://github.com/neovim/neovim/issues/12707.

Fix corner case that occurs when both:

  1. Evaluating a mapped expression causes the cursor to move.
  2. The evaluated result does not resolve to a character.

When a mapping does not result in a character, the UI is flushed, and we go back to waiting for user input. When the cursor has moved, the UI is flushed in an incorrect state, this can be resolved with a simple call to setcursor().

x-yuri
x-yuri

Okay, now, how do we make it merged? :) I see that it needs a maintainer approval. Is there anything I can do to help you? @justinmk? @clason?

Jan
5
3 weeks ago
Activity icon
issue

x-yuri issue comment tpope/vim-fugitive

x-yuri
x-yuri

`vim` freezes on some `fugitive` commands

Steps to reproduce:

a.sh:

mkdir a
cd a
git init
echo a > a && git add a && git commit -m a
echo 'line 1
line 2' > b && git add b && git commit -m b1
echo 'line 11
line 2' > b && git add b && git commit -m b2
echo 'line 11
line 22' > b && git add b && git commit -m b3
$ sh ./a.sh
$ cd a
$ vim +'Gedit :' +'tabe b' +tabn
  1. :G rebase -i --root
  2. Swap the last two commits.
  3. ZZ
  4. ra

At this point it freezes. To unfreeze: o, l or Enter.

It happens here (:checktime). A vim bug? Apparently it wants to ask me if I want to reload b. Not sure how to make it visible to confirm it.

But it doesn't happen with any commit history. E.g. not with this one:

mkdir a
cd a
git init
echo a > a && git add a && git commit -m a
echo 'line 1
line 2' > b && git add b && git commit -m b1
echo 'line 2
line 1' > b && git add b && git commit -m b2
$ vim --version
VIM - Vi IMproved 8.2 (2019 Dec 12, compiled Dec 25 2021 11:17:40)
x-yuri
x-yuri

With autoread it doesn't freeze.

Activity icon
issue

x-yuri issue tpope/vim-fugitive

x-yuri
x-yuri

`vim` freezes on some `fugitive` commands

Steps to reproduce:

a.sh:

mkdir a
cd a
git init
echo a > a && git add a && git commit -m a
echo 'line 1
line 2' > b && git add b && git commit -m b1
echo 'line 11
line 2' > b && git add b && git commit -m b2
echo 'line 11
line 22' > b && git add b && git commit -m b3
$ sh ./a.sh
$ cd a
$ vim +'Gedit :' +'tabe b' +tabn
  1. :G rebase -i --root
  2. Swap the last two commits.
  3. ZZ
  4. ra

At this point it freezes. To unfreeze: o, l or Enter.

It happens here (:checktime). A vim bug? Apparently it wants to ask me if I want to reload b. Not sure how to make it visible to confirm it.

But it doesn't happen with any commit history. E.g. not with this one:

mkdir a
cd a
git init
echo a > a && git add a && git commit -m a
echo 'line 1
line 2' > b && git add b && git commit -m b1
echo 'line 2
line 1' > b && git add b && git commit -m b2
$ vim --version
VIM - Vi IMproved 8.2 (2019 Dec 12, compiled Dec 25 2021 11:17:40)
Jan
3
3 weeks ago
pull request

x-yuri pull request mesonbuild/meson

x-yuri
x-yuri

Running-Meson.md: fix a broken link

push

x-yuri push x-yuri/meson

x-yuri
x-yuri

Running-Meson.md: fix a broken link

commit sha: 31112a4dc8d3b39e88cfa6f9f1e34d9dc86f10e0

push time in 3 weeks ago
Activity icon
fork

x-yuri forked mesonbuild/meson

⚡ The Meson Build System
x-yuri Apache License 2.0 Updated
fork time in 3 weeks ago
push

x-yuri push x-yuri/mesonbuild.github.io

x-yuri
x-yuri

Running-Meson.html: fix a broken link

commit sha: 8592bb7b23209698f7c39a5129a10bf808ed8a0c

push time in 3 weeks ago
Activity icon
fork

x-yuri forked mesonbuild/mesonbuild.github.io

⚡ Mesonbuild.com web site
x-yuri Updated
fork time in 3 weeks ago
Jan
1
3 weeks ago
Activity icon
issue

x-yuri issue comment neovim/neovim

x-yuri
x-yuri

Fix possible misplaced cursor after :map expr (Issue #12707)

My attempt at tackling issue: https://github.com/neovim/neovim/issues/12707.

Fix corner case that occurs when both:

  1. Evaluating a mapped expression causes the cursor to move.
  2. The evaluated result does not resolve to a character.

When a mapping does not result in a character, the UI is flushed, and we go back to waiting for user input. When the cursor has moved, the UI is flushed in an incorrect state, this can be resolved with a simple call to setcursor().

x-yuri
x-yuri

I've rebased the changes:

Restore cursor position after expr mapping vim-patch 8.1.1591: on error garbage collection may free memory in use vim-patch 8.1.2336: when an expr mapping moves the cursor it is not restored

onto master (or rather cherry-picked the commits):

Restore cursor position after expr mapping vim-patch 8.1.2336: when an expr mapping moves the cursor it is not restored

8.1.1591 was applied here.

The first commit had a conflict in src/nvim/getchar.c because a function handle_mapping() was extracted from vgetorpeek(). As such NOLINT is supposedly no longer needed.

The second commit had a conflict in the same file, and in src/nvim/testdir/test_mapping.c. I resolved the second conflict by putting the test to the place where it is in the vim repository, for what it's worth.

It's worth noting that they put the cursor back before restoring vgetc_busy, and may_garbage_collect.

Other than that, it resolves the issue, and the tests pass.

@JaySandhu, can you update the PR? Or should I create a new one?

Activity icon
issue

x-yuri issue comment sharkdp/fd

x-yuri
x-yuri

Is `-tf -td -tl -ts -tp` always true?

What version of fd are you using? fd 8.3.0

I'm trying to exclude sockets so that tar wouldn't complain. And pipes since I don't need them. Should I use -tf -td -tl?

x-yuri
x-yuri

Actually no:

$ mkfifo p
$ touch a
$ ln -s ./a b
$ fd -tf
a
$ fd -tl
b
$ fd -tp
p

Here are the corresponding lines:

https://github.com/sharkdp/fd/blob/e5145ffb985ab1fdd72b680806dff4fc00c1877f/src/filetypes.rs#L19-L23

And the is_file description says:

Tests whether this file type represents a regular file. The result is mutually exclusive to the results of is_dir and is_symlink; only zero or one of these tests may pass.

Then the following lines suggest that the options in the title aren't true for every entry:

https://github.com/sharkdp/fd/blob/e5145ffb985ab1fdd72b680806dff4fc00c1877f/src/filetypes.rs#L30-L34

So, what are the other possible cases?

Activity icon
created branch

x-yuri in x-yuri/neovim create branch map-expr-fix

createdAt 3 weeks ago
Activity icon
fork

x-yuri forked neovim/neovim

⚡ Vim-fork focused on extensibility and usability
x-yuri Updated
fork time in 3 weeks ago
Dec
29
4 weeks ago
Activity icon
issue

x-yuri issue sharkdp/fd

x-yuri
x-yuri

Is `-tf -td -tl -ts -tp` always true?

What version of fd are you using? fd 8.3.0

I'm trying to exclude sockets so that tar wouldn't complain. And pipes since I don't need them. Should I use -tf -td -tl?

Dec
27
1 month ago
Activity icon
issue

x-yuri issue rhboot/efibootmgr

x-yuri
x-yuri

-b's descripyion is misleading

I thought I could modify a boot entry like so:

$ efibootmgr --disk /dev/nvme0n1 --part 5 --bootnum 0000 --unicode 'root=PARTUUID=... rw initrd=\initramfs-linux.img'

But it turns out it doesn't work this way, and I have to delete the entry first. A better description would probably be:

Provide a bootnum for --active, --inactive, --delete, --create, ...

Dec
24
1 month ago
Activity icon
issue

x-yuri issue linux-pam/linux-pam

x-yuri
x-yuri

pam_unix ignores nullok

I've run into it while trying to understand why ssh doesn't let me in without a password. I end up here (user has empty password - access denied):

https://github.com/linux-pam/linux-pam/blob/40f7d85f3736d058c26de1dafa4fed46de7d75ef/modules/pam_unix/passverify.c#L78-L87

But nullok is actually not nullok, but some nonull:

https://github.com/linux-pam/linux-pam/blob/40f7d85f3736d058c26de1dafa4fed46de7d75ef/modules/pam_unix/support.c#L723

I'm not a PAM expert, but it seems like it doesn't work. I expected authentication to succeed if nullok and empty password (passwd -S ... == NP).

Dec
16
1 month ago
Activity icon
issue

x-yuri issue comment docker/compose

x-yuri
x-yuri

detachKeys support (making Ctrl-P usable in attached containers) broken in v2?

Interactive/attached containers started with docker-compose v2.1.1 use Ctrl-P,Ctrl-Q as the detach escape sequence, regardless of detachKeys settings in ~/.docker/config.json

Previously discussed in #3311 and closed as fixed, but presumably broken again in the go rewrite?

docker-compose.yml:

services:
  blah:
    image: ubuntu:latest
    command: /bin/bash
    stdin_open: true
    tty: true
~/.docker/config.json:
{ "detachKeys": "z,z" }

Steps to reproduce the issue:

  1. docker-compose run --rm blah
  2. type z z (container detaches)
  3. type Ctrl-p Ctrl-q (should not detach; does anyway.)

Describe the results you received:

detachKeys setting is in addition to the standard Ctrl-P,Ctrl-Q, not instead of. This leaves Ctrl-P inputs buffered making it unusable as an interactive keybinding (which is a common readline usage for 'previous thing')

Describe the results you expected:

interactive sessions opened through compose should obey the local detachKeys setting, or provide some other facility to configure it to avoid buffering ctrl-P keystrokes. This could be an argument to docker-compose run mirroring the --detach-keys STR arg that docker run accepts.

Edit:

After some source diving and further testing, I originally thought it wsnt' being set at all, but it is actually allowing both the default /and/ the detachkeys config, which is nice if you want it bound to something else as well, but not if you want to free up the original binding for use.

Output of docker compose version: Docker Compose version v2.1.1

Output of docker info:

Client:
 Context:    default
 Debug Mode: false
 Plugins:
  app: Docker App (Docker Inc., v0.9.1-beta3)
  buildx: Build with BuildKit (Docker Inc., v0.6.3-docker)
  compose: Docker Compose (Docker Inc., v2.1.1)
  scan: Docker Scan (Docker Inc., v0.9.0)

Server:
 Containers: 6
  Running: 4
  Paused: 0
  Stopped: 2
 Images: 118
 Server Version: 20.10.10
 Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
  Native Overlay Diff: true
  userxattr: false
 Logging Driver: json-file
 Cgroup Driver: cgroupfs
 Cgroup Version: 1
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
 Swarm: inactive
 Runtimes: io.containerd.runtime.v1.linux runc io.containerd.runc.v2
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: 5b46e404f6b9f661a205e28d59c982d3634148f8
 runc version: v1.0.2-0-g52b36a2
 init version: de40ad0
 Security Options:
  apparmor
  seccomp
   Profile: default
 Kernel Version: 5.11.0-38-generic
 Operating System: Ubuntu 20.04.3 LTS
 OSType: linux
 Architecture: x86_64
 CPUs: 3
 Total Memory: 7.742GiB
 Name: hithere
 ID: 123
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 Registry: https://index.docker.io/v1/
 Labels:
 Experimental: false
 Insecure Registries:
  127.0.0.0/8
 Live Restore Enabled: false
 Default Address Pools:
   Base: 10.0.0.0/16, Size: 26
x-yuri
x-yuri

I see. I don't run shells in containers like in the OP. So I don't really know the workflow people follow in that case. The way that OP did it, that would run a second instance of the blah service. Than, what's the point of running a shell in a container, if you launch another instance of a service anyway? Usually I have a container with some program and I run a shell there with exec if I need to investigate something. The way I see it, docker-compose run is for scripts, not for shells. But anyway:

version: '3'
services:
  s1:
    image: alpine
    command: /bin/sh
    stdin_open: true
    tty: true
  s2:
    image: alpine
    command: sleep infinity
    init: true
$ docker-compose up -d
$ docker-compose run --rm s1

If I press Ctrl-p Ctrl-q the docker-compose process stops responding and I have to kill it. And z z works ([email protected] [email protected] in my case).

$ docker-compose exec --rm s2 sh

Both Ctrl-p Ctrl-q and [email protected] [email protected] detach me from the container.

$ docker attach $(docker-compose ps -q s1)

This way it works as expected ([email protected] [email protected] detaches, Ctrl-p Ctrl-q doesn't).

$ docker exec -it $(docker-compose ps -q s2) sh

Same here.

So docker-compose run and docker-compose exec doesn't work as expected. The workaround is to use docker attach or docker exec.

And about shells in containers I recommend against command: /bin/bash or something. It makes things harder. There's no docker-compose attach, for one. Do you need to run a shell in a container with some program? docker-compose exec. Are you planning not run anything in a container right away? command: sleep infinity + init: true (to make it restart fast). Then docker-compose exec when you need a shell there. To make it clear I don't have projects with command: sleep infinity in docker-compose.yml files (not on the remote/origin). I usually change the command locally to sleep infinity, then exec into the container, then either run the process that is supposed to run there (e.g. ./manage.py runserver, bin/rails s), or vim, or whatever else I need (e.g. ./manage.py migrate, bin/rails db:migrate). This way I can also use interactive debuggers (e.g. pdbpp, pry-byebug). If I only need to restart the process, and there's a way (e.g. nginx -s reload), I just exec into the container (no point in changing the command).

Previous