Example:

[
        {
                "id": "runscript",
                "execute-command": "/path/to/script.sh",
                "command-working-directory": "/tmp",
                "pass-environment-to-command": [
                        {
                                "source": "payload",
                                "name": "env1",
                                "envname": "ENV1"
                        },
                        {
                                "source": "payload",
                                "name": "env2",
                                "envname": "ENV2"
                        }
        }
]

script.sh

#!/bin/sh
pwd

In my log, I see the following

[webhook] 2020/09/24 16:09:40 [d92f25] executing /path/to/script.sh (/path/to/script.sh) with arguments ["/path/to/script.sh"] and environment [ENV1=a ENV2=b] using /path/to as cwd
/path/to

This is with the latest version of webhook: 2.7.0

sorry, my bad! I had been editing the wrong hooks.json. Turns out that there is no problem with command-working-directory. 👍

Example:

[
        {
                "id": "runscript",
                "execute-command": "/path/to/script.sh",
                "command-working-directory": "/tmp",
                "pass-environment-to-command": [
                        {
                                "source": "payload",
                                "name": "env1",
                                "envname": "ENV1"
                        },
                        {
                                "source": "payload",
                                "name": "env2",
                                "envname": "ENV2"
                        }
        }
]

script.sh

#!/bin/sh
pwd

In my log, I see the following

[webhook] 2020/09/24 16:09:40 [d92f25] executing /path/to/script.sh (/path/to/script.sh) with arguments ["/path/to/script.sh"] and environment [ENV1=a ENV2=b] using /path/to as cwd
/path/to

This is with the latest version of webhook: 2.7.0

Sure. I just had the impression (as I believe most folks would as well) from the docs (https://www.nomadproject.io/docs/job-specification/task#kill_signal) that my tasks would be getting TERM instead of KILL

Fixes #8932

NOTE: I'm guessing ideally, the standard messaging in various places (nomad/structs/structs.go, command/alloc_status.go) with text like 'Sent interrupt' might have to change as well, but maybe that can be part of a bigger discussion. For now, I think updating the default from SIGINT to SIGTERM makes sense.

References: https://www.nomadproject.io/docs/job-specification/task#kill_signal, https://docs.docker.com/engine/reference/commandline/stop/

Nomad version

Nomad v0.13.0-dev (fb170f37a05d712e3046d604c362804c7934cfc9+CHANGES)

Operating system and Environment details

Ubuntu 20.04.1 LTS

Issue

Reproduction steps

Not too sure why nobody has noticed, but it seems like nomad job stop sends a docker task the interrupt signal, as opposed to the expected TERM as per https://www.nomadproject.io/docs/job-specification/task#kill_signal

To confirm this, I basically added debug logging to https://github.com/hashicorp/nomad/blob/943854469db945631e79ccd0f8014cdb1e584963/drivers/docker/handle.go#L127

My debug output for the signal parameter gives interrupt.

My first clue was from my alloc logs, where I see 'Sent interrupt'. The line from nomad job stop is called out below

Time                  Type        Description
2020-09-19T10:50:04Z  Killing     Sent interrupt. Waiting 30s before force killing
2020-09-19T10:50:04Z  Killed      Task successfully killed
2020-09-19T10:50:04Z  Terminated  Exit Code: 1, Exit Message: "Docker container exited with non-zero exit code: 1"
2020-09-19T10:50:02Z  Killing     Sent interrupt. Waiting 30s before force killing                 --> did `nomad job stop` here
2020-09-19T10:45:51Z  Started     Task started by client
2020-09-19T10:45:37Z  Driver      Downloading image
2020-09-19T10:45:37Z  Task Setup  Building Task Directory
2020-09-19T10:45:34Z  Received    Task received by client

Job file (if appropriate)

any standard job file will do

I am seeing this as well - with the latest Nomad version too (Nomad v0.12.4 (8efaee4ba5e9727ab323aaba2ac91c2d7b572d84)). This issue should not have been closed by the bot. Is anybody looking at this?

Thank you for coming up with this, @toymachiner62 . I didnt even think that we could have a dynamic tag this way!!

I've improved upon this and fixed the way to keep the tag constant between the build and push steps:

      - run:
          name: seed environment
          command: |
            echo $(date +%Y-%m-%d__%H-%M)__$(git log -n1 --format=%h) > IMAGE_TAG
      - aws-ecr/build-and-push-image:
          tag: $(cat IMAGE_TAG)
          ...

This works and gives you a stable tag in the environment. Really all you need is a a stable tag between "Build docker image" and "Push image to Amazon ECR". The format of the tag is entirely up to you, but I like having the datetime + hash reflected

@jf From the source code: https://github.com/unbit/uwsgi/blob/uwsgi-2.0/plugins/http/http.c#L658

Excellent, thanks! I see it now. On another note, if anybody has any recommendations for another server to check out that has proper http keep-alive support, I'd be glad to hear it.

Btw, "http-keepalive" option value is a number which specify timeout (in seconds) after which an inactive connection is closed by server. How can I configure this timeout when I will use "http11-socket"?

@marc1n what is your source for this? I see https://github.com/unbit/uwsgi/issues/2018, which seems to indicate that this is a boolean instead.

I wonder if the fix is not more complicated than that:

* there might be IPv6/IPv4 addresses in nodes as well, some existing implementations might have chosen some strategies to use ServiceAdress _before_ Node.Address or Node.TaggedAddress[IPv4/v6] and it might break some clients. For instance, we consider the semantics to be very precise (aka, it means this is a virtual IP, not the IP value)

I agree with you that the choice of letting it empty is probably unfortunate, but the change would be very late in the game, what I mean is that some users might take decisions based on the fact this value is present or not.

As mentioned at https://github.com/hashicorp/consul/issues/4599#issuecomment-689611373, I'm not sure what the value of having Service.Address be empty would be.

About choosing to use it the correct version, (Service OR Node), maybe the doc should be lear about what the default strategy should be, but it is probably to the Consul wrappers to implement it.

it would indeed be helpful for the docs to clear about this, yes

For instance, in the implementations of our SDKs, we provide wrappers for that, for example, https://github.com/criteo/consul-templaterb/blob/master/TemplateAPI.md#service_address

I agree with you on the initial issue, but I think that many tools are now doing assumptions based on this value being present or not, see my comment: #7782 (comment)

I'm late to this issue but... what tools would these be, and why would they care about it being empty (""?) vs being filled with an actual IP address? I fail to see why having the actual IP address reflected in Service.Address is a problem vs it's current "" value

Now no external dependencies are needed to play with all combinations of ENTRYPOINT and CMD.

this is great! thanks.

At least the shell form prevents the CMD to be used. A second /bin/sh normally doesn't make sense in the command line, but of course depends on what the entrypoint does with it.

Surely the shell form still does something with the CMD provided in the Dockerfile? That was my point and why I say the documentation isnt really correct.

I you like you could draft a PR to update the table in docker/cli repo.

Thanks. I can. Just not too sure about (as I've said) whether this is a bug in the doc, or if the behaviour has changed.

But coming back to what I would like to verify (or else I could have just done the PR to docker/cli myself): is this a bug and the intention of The shell form prevents any CMD or run command line arguments from being used still remains the same... or has that changed? Can you help me with that?

(Your echo test, btw, failed because it would have been (breaking up the parameters) run as /bin/sh, -c, echo, /bin/sh,-c, exec_cmd p1_cmd. All of those arguments after echo got passed as arguments to /bin/sh, and not to echo)

yeah, I know because I did see the result of docker top... but also because I investigated the process data (not necessary, but just helps to confirm things) in the container. Now the question remains: is this a bug? is it still intended that, according to the doc The shell form prevents any CMD or run command line arguments from being used? Which is it?

It's either that the table has to be changed.. or the statement that The shell form prevents any CMD or run command line arguments from being used, ... has to be changed.

@StefanScherer can you confirm which is correct?

# docker version
Client: Docker Engine - Community
 Version:           19.03.12
 API version:       1.40
 Go version:        go1.13.10
 Git commit:        48a66213fe
 Built:             Mon Jun 22 15:45:44 2020
 OS/Arch:           linux/amd64
 Experimental:      false

Server: Docker Engine - Community
 Engine:
  Version:          19.03.12
  API version:      1.40 (minimum version 1.12)
  Go version:       go1.13.10
  Git commit:       48a66213fe
  Built:            Mon Jun 22 15:44:15 2020
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          1.2.13
  GitCommit:        7ad184331fa3e55e52b890ea95e65ba581ae3429
 runc:
  Version:          1.0.0-rc10
  GitCommit:        dc9208a3303feef5b3839f4323d9beb36df0a9dd
 docker-init:
  Version:          0.18.0
  GitCommit:        fec3683

It's either that the table has to be changed.. or the statement that The shell form prevents any CMD or run command line arguments from being used, ... has to be changed.

FROM ubuntu
ENTRYPOINT top -b
CMD exec_cmd p1_cmd

docker build ... docker run --name test ... docker top test

If you only look at the output, how do you verify that echo got run with sh -c echo?

My testing for the table shows otherwise. Have you tested it?

File: engine/reference/builder.md

These points relate to https://docs.docker.com/engine/reference/builder/#shell-form-entrypoint-example. Several points:

1. The following Dockerfile does not build:

FROM ubuntu
ENTRYPOINT top -b
CMD --ignored-param1

# docker build -t top .
Sending build context to Docker daemon  70.14kB
Error response from daemon: Dockerfile parse error line 6: Unknown flag: ignored-param1
#

2. command output conflicts with argument(s?) to docker run in the example given:

$ docker run -it --name test top --ignored-param2

Mem: 1704184K used, 352484K free, 0K shrd, 0K buff, 140621524238337K cached
CPU:   9% usr   2% sys   0% nic  88% idle   0% io   0% irq   0% sirq
Load average: 0.01 0.02 0.05 2/101 7
  PID  PPID USER     STAT   VSZ %VSZ %CPU COMMAND
    1     0 root     S     3168   0%   0% /bin/sh -c top -b cmd cmd2
    7     1 root     R     3164   0%   0% top -b

Command gives --ignored-param2, while output uses cmd cmd2. This is besides the fact that the container's output from top does not reveal the command line arguments for both sh and top; you need to use docker top test for that.

3. The table at https://docs.docker.com/engine/reference/builder/#understand-how-cmd-and-entrypoint-interact needs to be updated. Specifically the ENTRYPOINT exec_entry p1_entry, with CMD exec_cmd p1_cmd entry. I get /bin/sh -c exec_entry p1_entry sh -c exec_cmd p1_cmd

First up, my apologies if this isn't really as vetted as it should be. I'm not entirely certain that this affects its use as called from c.Meta.FlagSet within the same file. What I do know and can tell is that this same string is used for the help output... which gives you misleading text:

# nomad node eligibility
Either the '-enable' or '-disable' flag must be set
For additional help try 'nomad node-eligibility -help'
#

It really should be nomad node eligibility -help instead.

I also see other Name() funcs for other commands that might need fixing, btw. If I can get some confirmation that all of the Name() funcs within command/*.go only affect help text, then I can go about fixing them.

As per subject, if you install the latest nomad package for Ubuntu (I'm using Focal), the systemd unit file is as follows:

[Unit]
Description=Nomad
Documentation=https://nomadproject.io/docs/
Wants=network-online.target
After=network-online.target

# When using Nomad with Consul it is not necessary to start Consul first. These
# lines start Consul before Nomad as an optimization to avoid Nomad logging
# that Consul is unavailable at startup.
#Wants=consul.service
#After=consul.service

[Service]
ExecReload=/bin/kill -HUP $MAINPID
ExecStart=/usr/bin/nomad agent -config /etc/nomad.d
KillMode=process
KillSignal=SIGINT
LimitNOFILE=65536
LimitNPROC=infinity
Restart=on-failure
RestartSec=2
StartLimitBurst=3
StartLimitInterval=10
TasksMax=infinity
OOMScoreAdjust=-1000

[Install]
WantedBy=multi-user.target

It looks like it should be StartLimitIntervalSec=10 instead of StartLimitInterval=10

Progress update please, can this be merged?

I think it looks like this was the intention, but https://github.com/terraform-providers/terraform-provider-aws/pull/9032#issuecomment-639695850 seems to indicate that discussion is being moved to https://discuss.hashicorp.com/t/discussion-of-aws-security-group-rules-for-absolute-management-while-avoiding-cyclical-dependencies/9647

@cloudhead just a ping again. Do you have any issues with this PR?

I see that "Unlicense" was already stated as the license without this project's approval. Please do not think to speak for rbenv-gemset.

I'm new to this, so forgive me for some simple mistakes. Following the README hasn't really helped me; I've seen on other issues that there has been some confusion about the README.

When I used a gemset for RVM, I would see it in the ruby version. I would run:

rvm gemset create my_cool_app rvm 2.5.1@my_cool_app

I could also a have a .ruby-version file with the gemset in it like this: 2.5.1@my_cool_app. And it worked perfectly. When I would view my ruby version, it would tell me my version with the gemset.

However, that's not happening with this plugin. I followed the README

I ran rbenv gemset init in my Rails project which created the .rbenv-gemsets file. When I ran rbenv gemset active it showed my gemset correctly. But when I run:

rbenv version in my project, I get this:

2.6.3 (set by /Users/garcia/.rbenv/version)

There is no gemset. It seems like the gemset is there, but it's not doing anything.

Am I wrongly expecting RVM behavior? Is it actually working fine?

Additional Questions

• Is a .ruby-version file necessary with version and gemset in it?

I did it all in the same commit, if that's ok. Figured it's probably better, and a cleaner commit.

I think this will be helpful. If there were some option or way to configure it that would be great.

as per subject, correct the phase info for lua_need_request_body. I assume this should be rewrite/access/content_by_lua