now space left on remote_tmp

Archives Ansible Project
1

I am getting

12<em>fatal: [VM-414001-0264.step.zrz.dvz.cn-mv.de]: FAILED! =>
  msg: 'failure writing module data to temporary file for transfer: [Errno 28] No space left on device
</em>

eventhough

123<em>user@vm-51150-0128:~/repos/ansible/step> grep tmp ansible.cfg
allow_world_readable_tmpfiles = True
remote_tmp = /tmp/.ansible/tmp
</em>

and

123<em>stepuser@vm-414001-0264:~> df -h /tmp
Filesystem              Size  Used Avail Use% Mounted on
/dev/mapper/vgsys-root  7,0G  2,2G  4,9G  32% /
</em>

what am I doing wrong?

2

It’s total gibberish to me.
Post plain text and we might be able to help
But one thing that comes to mind and that is you’ve ran out of inodes.

3

Indeed - as well as "df -h" it's always good to do "df -i"

Antony.

4

Since your notes give no hint of what file was being transferred, it
may have just too dang big.

5

Are you using BTRFS on /dev/mapper/vgsys-root? Then you better check "btrfs fs df /"

6

You need to be careful with using /tmp as teh remote tmp directory on selinux systems. You can end up doing weird stuff to to your permissions there when ansible things that is the home directory. Have you made sure the permissions are good.

7

here in plain text

I am getting

   fatal: [VM-414001-0264.step.zrz.dvz.cn-mv.de]: FAILED! =>
   msg: 'failure writing module data to temporary file for transfer: [Errno 28] No space left on device

on "Gathering Facts" of a playbook execution, eventhough I have setup ansible to use /tmp/.ansible/tmp and there should be space available as far as I can tell

   stepuser@vm-414001-0264:~> df -h /tmp
   Filesystem Size Used Avail Use% Mounted on
   /dev/mapper/vgsys-root 7,0G 2,2G 4,9G 32% /

what am I doing wrong?

8

You’re only looking at the number of free space (i.e. blocks).
But (as I stated earlier) there are also inodes which the filesystem can run out of.
Try:

df -i

9

sorry everybody. I made a stupid mistake. The error message was about the anible-controler, NOT THE REMOTE HOST.

and, again, I recognize that it is always a good idea to post the entire -vvv content here. Sorry that I did not do ii this time and likewise may have directed everybody into the wrong direction.