Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Container is pausing with no apparent reason #5

Open
fspegni opened this issue Apr 2, 2020 · 0 comments
Open

Container is pausing with no apparent reason #5

fspegni opened this issue Apr 2, 2020 · 0 comments

Comments

@fspegni
Copy link

fspegni commented Apr 2, 2020

Hi,

I'm experimenting with your container (thanks for the nice job). I've some problem to understand why the following docker-compose configuration starts a container that is paused after a few seconds:

...
  rsync:
    image: eeacms/rsync
    command: [ "client" ]
...

This is what I get filtering the output of docker ps command:

$ user@host:~/git/project$ docker ps | grep rsync
a5af0b17883a        eeacms/rsync             "/docker-entrypoint.…"   20 seconds ago      Up 18 seconds                                                     project_rsync_1
...
$ user@host:~/git/project$ docker ps | grep rsync
a5af0b17883a        eeacms/rsync             "/docker-entrypoint.…"   41 seconds ago      Up 40 seconds (Paused)                                                 project_rsync_1

You can see that while the container project_rsync_1 is created just fine, but it goes to a (Paused) state without me doing nothing. By checking the container log I can only see the usual SSH key output:

user@host:~/git/project$ docker logs project_rsync_1 
ssh-keygen: generating new host keys: RSA DSA ECDSA ED25519 
Please add this ssh key to your server /home/user/.ssh/authorized_keys        
================================================================================
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQDRmI7wc61m4gaDnaJQVq2TfS2Rj/avt0Oxw1ZRmvDYkzVXmkBJIUt0aycLcqJSrcu9oaVg0m/t5oFwTxX7rGCl1JObhCiibSn8FI+X30VZRxPmMt4fKybGgFAcTSY9C1TsIny9+jbLo+lO24dUWP05wlD6UPFxWhUyFxLIXbk8HT03Z+GI/1gLZ7cjS3jhYtrCxP5MO6T//jRksRj0qYyGtGWt84fRptFCMd9/HFVa09m95N9ASteHTLAz+t8TKaxqrt0otpsTPAAbMFHy/lmIIW9QCjvRfE56nVYvwd9vak6sR6GLhLdW62vVr3EF/qQP64cmgvygnOWqCQH4asajb9i2e3Jxn1xJ91O5ZbX8UMLplnFArIh//lPRClR7zRMvGNzKo/f6BwsEUE5Of4vGH6Xkwj9bk0FCQp8IbQAydSRaPNxuBeEczXtBi9GdWZYAsONJW1Oie5x5kXWPW5jZI6ZU+fe45kieVCjDeES8n4wMG8nm6lRSErfw8UY5KzU= root@a5af0b17883a
================================================================================

If I (manually) unpause the container and check the running processes within the container, I can see the following:

$ docker-compose exec rsync ash
... (enter the container) ...
Mem: 14428704K used, 1373116K free, 936804K shrd, 952276K buff, 5104148K cached
CPU:   2% usr   4% sys   0% nic  91% idle   0% io   0% irq   1% sirq
Load average: 1.20 1.36 1.43 2/1716 20
  PID  PPID USER     STAT   VSZ %VSZ CPU %CPU COMMAND
   15     0 root     S     1624   0%   1   0% ash
   20    15 root     R     1560   0%   3   0% top
    1     0 root     S     1552   0%   4   0% /usr/sbin/crond -f

The container crontab -l is actually empty, because I did not set the variable CRON_TASK_1, but the same problem happens if I set such variable.

Is it a problem or is it supposed to work that way? Do I miss something obvious?

Thanks

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant