70

After a recent upgrade to Fedora 15, I'm finding that a number of tools are failing with errors along the lines of:

tail: inotify resources exhausted
tail: inotify cannot be used, reverting to polling

It's not just tail that's reporting problems with inotify, either. Is there any way to interrogate the kernel to find out what process or processes are consuming the inotify resources? The current inotify-related sysctl settings look like this:

fs.inotify.max_user_instances = 128
fs.inotify.max_user_watches = 8192
fs.inotify.max_queued_events = 16384

9 Answers 9

52

It seems that if the process creates inotify instance via inotify_init(), the resulting file that represents filedescriptor in the /proc filesystem is a symlink to (non-existing) 'anon_inode:inotify' file.

$ cd /proc/5317/fd
$ ls -l
total 0
lrwx------ 1 puzel users 64 Jun 24 10:36 0 -> /dev/pts/25
lrwx------ 1 puzel users 64 Jun 24 10:36 1 -> /dev/pts/25
lrwx------ 1 puzel users 64 Jun 24 10:36 2 -> /dev/pts/25
lr-x------ 1 puzel users 64 Jun 24 10:36 3 -> anon_inode:inotify
lr-x------ 1 puzel users 64 Jun 24 10:36 4 -> anon_inode:inotify

Unless I misunderstood the concept, the following command should show you list of processes (their representation in /proc), sorted by number of inotify instances they use.

$ for foo in /proc/*/fd/*; do readlink -f $foo; done | grep inotify | sort | uniq -c | sort -nr

Finding the culprits

Via the comments below @markkcowan mentioned this:

$ find /proc/*/fd/* -type l -lname 'anon_inode:inotify' -exec sh -c 'cat $(dirname {})/../cmdline; echo ""' \; 2>/dev/null
4
  • 9
    Excellent, thank you! I didn't know about the inotify inodes showing up in /proc. For my purposes, the command can be simplified to this: find /proc/*/fd/* -type l -lname 'anon_inode:inotify' -print
    – larsks
    Commented Jun 25, 2011 at 12:29
  • I'm glad it helped. And your solution with find -lname is indeed much nicer than mine with for loop and readlink.
    – Petr Uzel
    Commented Jun 26, 2011 at 10:44
  • 4
    Note that you could also be out of watches (not instances). E.g., on my system, that gives a low-teens number of instances, but there are many tens of thousands of watches from KDE's desktop search. Its too bad there isn't an easier way to check how many watches/instances are in use, since the kernel clearly knows...
    – derobert
    Commented Jan 23, 2013 at 16:18
  • @derobert I made a script for listing the processes consuming watchers, which is usually what one cares about. See my answer below.
    – oligofren
    Commented Apr 2, 2019 at 12:14
45

Oct 31 2022 update Upvote Michael Sartain's answer below. He implemented a native executable that is much faster, along with additional functionality not present in my script (below). Worth checking out if you can spend a few seconds compiling it! the native inotify-info utility


Original answer with script

As @Jonathan Kamens said, you are probably running out of watches. I have a premade script, inotify-consumers, that lists the top offenders for you:

   INOTIFY   INSTANCES
   WATCHES      PER   
    COUNT     PROCESS   PID USER         COMMAND
------------------------------------------------------------
   21270         1       11076 my-user    /snap/intellij-idea-ultimate/357/bin/fsnotifier
     201         6           1 root       /sbin/init splash
     115         5        1510 my-user    /lib/systemd/systemd --user
      85         1        3600 my-user    /usr/libexec/xdg-desktop-portal-gtk
      77         1        2580 my-user    /usr/libexec/gsd-xsettings
      35         1        2475 my-user    /usr/libexec/gvfsd-trash --spawner :1.5 /org/gtk/gvfs/exec_spaw/0
      32         1         570 root       /lib/systemd/systemd-udevd
      26         1        2665 my-user    /snap/snap-store/558/usr/bin/snap-store --gapplication-service
      18         2        1176 root       /usr/libexec/polkitd --no-debug
      14         1        1858 my-user    /usr/bin/gnome-shell
      13         1        3641 root       /usr/libexec/fwupd/fwupd
...

   21983  WATCHES TOTAL COUNT

INotify instances per user (e.g. limits specified by fs.inotify.max_user_instances): 

INSTANCES    USER
-----------  ------------------
41           my-user
23           root
1            whoopsie
1            systemd-ti+
...

Here you quickly see why the default limit of 8K watchers is too little on a development machine, as just WebStorm instance quickly maxes this when encountering a node_modules folder with thousands of folders. Add a webpack watcher to guarantee problems ...

Even though it was much faster than the other alternatives when I made it initially, Simon Matter added some speed enhancements for heavily loaded Big Iron Linux (hundreds of cores) that sped it up immensely, taking it down from ten minutes (!) to 15 seconds on his monster rig.

Later on, Brian Dowling contributed instance count per process, at the expense of relatively higher runtime. This is insignificant on normal machines with a runtime of about one second, but if you have Big Iron, you might want the earlier version with about 1/10 the amount of system time :)

How to use

inotify-consumers --help 😊 To get it on your machine, just copy the contents of the script and put it somewhere in your $PATH, like /usr/local/bin. Alternatively, if you trust this stranger on the net, you can avoid copying it and pipe it into bash over http:

$ curl -s https://raw.githubusercontent.com/fatso83/dotfiles/master/utils/scripts/inotify-consumers | bash 

       INOTIFY
       WATCHER
        COUNT     PID USER     COMMAND
    --------------------------------------
        3044   3933 myuser node /usr/local/bin/tsserver
        2965   3941 myuser /usr/local/bin/node /home/myuser/.config/coc/extensions/node_modules/coc-tsserver/bin/tsserverForkStart /hom...

        6990  WATCHES TOTAL COUNT

How does it work?

For reference, the main content of the script is simply this (inspired by this answer)

find /proc/*/fd \
    -lname anon_inode:inotify \
    -printf '%hinfo/%f\n' 2>/dev/null \
    \
    | xargs grep -c '^inotify'  \
    | sort -n -t: -k2 -r 

Changing the limits

In case you are wondering how to increase the limits

$ inotify-consumers --limits 

Current limits
-------------
fs.inotify.max_user_instances = 128
fs.inotify.max_user_watches = 524288


Changing settings permanently
-----------------------------
echo fs.inotify.max_user_watches=524288 | sudo tee -a /etc/sysctl.conf
sudo sysctl -p # re-read config
4
  • 3
    A lot of other suggestions didn't work well for me, but this script worked great on Fedora 29. Thanks! Commented Mar 29, 2019 at 13:19
  • 3
    Fantastic answer, thanks. I actually find it much more relevant than the accepted since it helps you focus on the biggest culprits. Also works perfectly on Ubuntu 18.04, and any other Linux I guess Commented Jan 7, 2020 at 10:19
  • This worked best at finding the culprit. Excellent script.
    – Bastion
    Commented Feb 19, 2020 at 4:42
  • 1
    @oligofren nice and useful script, thanks! :) Commented Oct 3, 2020 at 15:52
27

You are probably running out of inotify watches rather than instances. To find out who's creating a lot of watches:

  1. Enable tracing of watch adds:
$ echo 1 > /sys/kernel/debug/tracing/events/syscalls/sys_exit_inotify_add_watch/enable`
  1. Verify if tracing_on is s to 1:
$ cat /sys/kernel/debug/tracing/tracing_on
0
$ echo 1 > /sys/kernel/debug/tracing/tracing_on
  1. Restart the processes with inotify instances (determined as described in Petr Uzel's answer) that you suspect of creating a lot of watches; and
  2. Setup ftrace
$ cat /sys/kernel/debug/tracing/current_tracer
nop

$ cat /sys/kernel/debug/tracing/set_ftrace_filter
#### all functions enabled ####

$ echo function              > /sys/kernel/debug/tracing/current_tracer
$ echo SyS_inotify_add_watch > /sys/kernel/debug/tracing/set_ftrace_filter
  1. Read the file /sys/kernel/debug/tracing/trace to watch how many watches are created and by which processes.

When you're done, make sure to echo 0 into the enable file (and the tracing_on file if you had to enable that as well) to turn off tracing so you won't incur the performance hit of continuing to trace.

NOTE: In older versions of the Linux kernel the /sys endpoint used to be called tracing_enabled, however it's now called tracing_on. If you find you're on an older edition of the kernel change /sys/kernel/debug/tracing/tracing_on to /sys/kernel/debug/tracing/tracing_enabled.

6
  • 1
    It was a backup application creating lots of inotify watches, and the solution in the accepted answer helped identify the culprit. However, I wasn't previously familiar with the system call tracing you've demonstrated here. Very cool. Thanks for the information!
    – larsks
    Commented Jan 23, 2013 at 16:35
  • There is no /sys/kernel/debug/tracing/events/syscalls/sys_exit_inotify_add_watch/enable nor /sys/kernel/debug/tracing/tracing_enabled on Gentoo Linux, but /sys/kernel/debug/tracing/tracing_enabled exists. Why is that?
    – zeekvfu
    Commented Dec 4, 2013 at 16:32
  • 1
    As @Kartoch implies, you need to do echo 1 | sudo tee /sys/kernel/debug/tracing/tracing_on on modern distros (Ubuntu 18.04.2 LTS).
    – oligofren
    Commented Feb 22, 2019 at 14:53
  • 1
    Could I somehow convert this information to file/directory paths?
    – Marinos An
    Commented Mar 4, 2019 at 14:24
  • 1
    @MarinosAn If you need file/directory paths, check out my answer.
    – oligofren
    Commented Apr 3, 2019 at 19:21
19

Just wrote an C++ app to help track down inotify information. Should be able to display summary information along with files and directories watched.

https://github.com/mikesart/inotify-info

Hopefully should help track down what the limits are and where they're being hit.

1
  • Hey, this is great! It covers most of the stuff in my script, is vastly quicker, and is just missing some improvements to make it more user friendly and useful. I will add some issues.
    – oligofren
    Commented Oct 31, 2022 at 9:31
9

I ran into this problem, and none of these answers give you the answer of "how many watches is each process currently using?" The one-liners all give you how many instances are open, which is only part of the story, and the trace stuff is only useful to see new watches being opened.

TL;DR: This will get you a file with a list of open inotify instances and the number of watches they have, along with the pids and binaries that spawned them, sorted in descending order by watch count:

sudo lsof | awk '/anon_inode/ { gsub(/[urw]$/,"",$4); print "/proc/"$2"/fdinfo/"$4; }' | while read fdi; do count=$(sudo grep -c inotify $fdi); exe=$(sudo readlink $(dirname $(dirname $fdi))/exe); echo -e $count"\t"$fdi"\t"$exe; done | sort -nr > watches

That's a big ball of mess, so here's how I got there. To start, I ran a tail on a test file, and looked at the fd's it opened:

joel@gladstone:~$ tail -f test > /dev/null &
[3] 22734
joel@opx1:~$ ls -ahltr /proc/22734/fd
total 0
dr-xr-xr-x 9 joel joel  0 Feb 22 22:34 ..
dr-x------ 2 joel joel  0 Feb 22 22:34 .
lr-x------ 1 joel joel 64 Feb 22 22:35 4 -> anon_inode:inotify
lr-x------ 1 joel joel 64 Feb 22 22:35 3 -> /home/joel/test
lrwx------ 1 joel joel 64 Feb 22 22:35 2 -> /dev/pts/2
l-wx------ 1 joel joel 64 Feb 22 22:35 1 -> /dev/null
lrwx------ 1 joel joel 64 Feb 22 22:35 0 -> /dev/pts/2

So, 4 is the fd we want to investigate. Let's see what's in the fdinfo for that:

joel@opx1:~$ cat /proc/22734/fdinfo/4
pos:    0
flags:  00
mnt_id: 11
inotify wd:1 ino:15f51d sdev:ca00003 mask:c06 ignored_mask:0 fhandle-bytes:8 fhandle-type:1 f_handle:1df51500a75e538c

That looks like a entry for the watch at the bottom!

Let's try something with more watches, this time with the inotifywait utility, just watching whatever is in /tmp:

joel@gladstone:~$ inotifywait /tmp/* &
[4] 27862
joel@gladstone:~$ Setting up watches.
Watches established.
joel@gladstone:~$ ls -ahtlr /proc/27862/fd | grep inotify
lr-x------ 1 joel joel 64 Feb 22 22:41 3 -> anon_inode:inotify
joel@gladstone:~$ cat /proc/27862/fdinfo/3
pos:    0
flags:  00
mnt_id: 11
inotify wd:6 ino:7fdc sdev:ca00003 mask:fff ignored_mask:0 fhandle-bytes:8 fhandle-type:1 f_handle:dc7f0000551e9d88
inotify wd:5 ino:7fcb sdev:ca00003 mask:fff ignored_mask:0 fhandle-bytes:8 fhandle-type:1 f_handle:cb7f00005b1f9d88
inotify wd:4 ino:7fcc sdev:ca00003 mask:fff ignored_mask:0 fhandle-bytes:8 fhandle-type:1 f_handle:cc7f00006a1d9d88
inotify wd:3 ino:7fc6 sdev:ca00003 mask:fff ignored_mask:0 fhandle-bytes:8 fhandle-type:1 f_handle:c67f00005d1d9d88
inotify wd:2 ino:7fc7 sdev:ca00003 mask:fff ignored_mask:0 fhandle-bytes:8 fhandle-type:1 f_handle:c77f0000461d9d88
inotify wd:1 ino:7fd7 sdev:ca00003 mask:fff ignored_mask:0 fhandle-bytes:8 fhandle-type:1 f_handle:d77f00000053c98b

Aha! More entries! So we should have six things in /tmp then:

joel@opx1:~$ ls /tmp/ | wc -l
6

Excellent. My new inotifywait has one entry in its fd list (which is what the other one-liners here are counting), but six entries in its fdinfo file. So we can figure out how many watches a given fd for a given process is using by consulting its fdinfo file. Now to put it together with some of the above to grab a list of processes that have notify watches open and use that to count the entries in each fdinfo. This is similar to above, so I'll just dump the one-liner here:

sudo lsof | awk '/anon_inode/ { gsub(/[urw]$/,"",$4); print "/proc/"$2"/fdinfo/"$4; }' | while read fdi; do count=$(sudo grep -c inotify $fdi); echo -e $count"\t"$fdi; done

There's some thick stuff in here, but the basics are that I use awk to build an fdinfo path from the lsof output, grabbing the pid and fd number, stripping the u/r/w flag from the latter. Then for each constructed fdinfo path, I count the number of inotify lines and output the count and the pid.

It would be nice if I had what processes these pids represent in the same place though, right? I thought so. So, in a particularly messy bit, I settled on calling dirname twice on the fdinfo path to get pack to /proc/<pid>, adding /exe to it, and then running readlink on that to get the exe name of the process. Throw that in there as well, sort it by number of watches, and redirect it to a file for safe-keeping and we get:

sudo lsof | awk '/anon_inode/ { gsub(/[urw]$/,"",$4); print "/proc/"$2"/fdinfo/"$4; }' | while read fdi; do count=$(sudo grep -c inotify $fdi); exe=$(sudo readlink $(dirname $(dirname $fdi))/exe); echo -e $count"\t"$fdi"\t"$exe; done | sort -n > watches

Running that without sudo to just show my processes I launched above, I get:

joel@gladstone:~$ cat watches 
6   /proc/4906/fdinfo/3 /usr/bin/inotifywait
1   /proc/22734/fdinfo/4    /usr/bin/tail

Perfect! A list of processes, fd's, and how many watches each is using, which is exactly what I needed.

2
  • When using lsof for this purpose, I would recommend using the -nP flags to avoid unnecessary lookups of reverse DNS and port names. In this particular case, adding -bw to avoid potentially blocking syscalls is also recommended. That said, with lsof gobbling up 3 seconds of wall clock time on my humble workstation (of which 2 seconds are spent in the kernel), this approach is nice for exploration but alas unsuitable for monitoring purposes.
    – BertD
    Commented Mar 15, 2018 at 10:39
  • I found your one-liner to be extremely slow, but there's a nice improvement possible, at the cost of some loss of info (we'll see watchers per process, rather than per file descriptor): First generate an intermediate file: lsof | awk '/a_inode/ { gsub(/[urw]$/,"",$4); print "/proc/"$2"/fdinfo/"$4; }' | sed 's/fdinfo.*//' | sort | uniq > uniq-o then cat uniq-o | while read fdi; do count=$(cat ${fdi}fdinfo/* | grep -c inotify 2>/dev/null); exe=$(readlink ${fdi}exe); echo -e $count"\t"${fdi}"\t"$exe; done > watches
    – LLlAMnYP
    Commented Jul 17, 2019 at 10:27
6

To trace which processes consume inotify watches (not instances) you can use the dynamic ftrace feature of the kernel if it is enabled in your kernel.

The kernel option you need is CONFIG_DYNAMIC_FTRACE.

First mount the debugfs filesystem if it is not already mounted.

mount -t debugfs nodev /sys/kernel/debug

Go under the tracing subdirectory of this debugfs directory

cd /sys/kernel/debug/tracing

Enable tracing of function calls

echo function > current_tracer

Filter only SyS_inotify_add_watch system calls

echo SyS_inotify_add_watch > set_ftrace_filter

Clear the trace ring buffer if it wasn't empty

echo > trace

Enable tracing if it is not already enabled

echo 1 > tracing_on

Restart the suspected process (in my case it was crashplan, a backup application)

Watch the inotify_watch being exhausted

wc -l trace
cat trace

Done

3
find /proc/*/fd/* -type l -lname 'anon_inode:inotify' 2>/dev/null | cut -f 1-4 -d'/' |  sort | uniq -c  | sort -nr
1

I have modified the script present in above to show the list of processes those are consuming inotify resources:

ps -p `find /proc/*/fd/* -type l -lname 'anon_inode:inotify' -print | sed s/'^\/proc\/'/''/ | sed s/'\/fd.*$'/''/`

I think there is a way to replace my double sed.


Yes. Use either

cut -f 3 -d '/'   

or

sed -e 's/^\/proc\/\([0-9]*\)\/.*/\1'  

and you'll only get the pid.
Also, if you add

2> /dev/null  

in the find, you'll get rid of any pesky error lines thrown by find. So this would work:

ps -p $(find /proc/*/fd/* -type l -lname 'anon_inode:inotify' -print 2> /dev/null | sed -e 's/^\/proc\/\([0-9]*\)\/.*/\1/')
0

We needed to run this script against a fleet of servers so we wrote an Ansible playbook to accomplish this. It adapts several of the concepts in the others answers into a single playbook which will run the commands necessary to generate a report showing inotify watcher usage by PID.

$ ansible-playbook \
    -i systems-inventory/cluster2.lab1 \
    playbooks/show_inotify_watcher_cnt.yml \
    -l ocp-master-02a.lab1*

NOTE: There's an example usage of this playbook is a comment towards the end of the playbook below.

$ cat show_inotify_watcher_cnt.yml
###########################################################
# References
###########################################################
# - https://stackoverflow.com/questions/40230184/how-to-do-multiline-shell-script-in-ansible
###########################################################


- hosts: compute infra masters
  tasks:
    - shell:
        cmd: |
            cat <<EOF > /tmp/inotify_cnt.sh
            #!/bin/bash

            ## Get the procs sorted by the number of inotify watchers
            ##
            ## From \`man find\`: 
            ##    %h     Leading directories of file's name (all but the last element).  
            ##           If the file name contains no slashes (since it is in the current directory) 
            ##           the %h specifier expands to \`.'.
            ##    %f     File's name with any leading directories removed (only the last element).
            lines=\$(
                find /proc/*/fd \
                -lname anon_inode:inotify \
                -printf '%hinfo/%f\n' 2>/dev/null \
                \
                | xargs grep -c '^inotify'  \
                | sort -n -t: -k2 -r \
                )

            printf "\n%10s\n" "INOTIFY"
            printf "%10s\n" "WATCHER"
            printf "%10s  %5s     %s\n" " COUNT " "PID" "CMD"
            printf -- "----------------------------------------\n"
            for line in \$lines; do
                watcher_count=\$(echo \$line | sed -e 's/.*://')
                pid=\$(echo \$line | sed -e 's/\/proc\/\([0-9]*\)\/.*/\1/')
                cmdline=\$(ps --columns 120 -o command -h -p \$pid) 
                printf "%8d  %7d  %s\n" "\$watcher_count" "\$pid" "\$cmdline"
            done
            EOF
      become: yes

    - file: 
        dest: /tmp/inotify_cnt.sh
        mode: a+x

    - shell: /tmp/inotify_cnt.sh
      become: yes
      register: output

    - debug:
        var: output.stdout_lines

    - shell: |
        sysctl fs.inotify
      become: yes
      register: output

    - debug:
        var: output.stdout_lines


##########
# USAGE
##########
## $ ansible-playbook -i systems-inventory/cluster2.lab1 playbooks/show_inotify_watcher_cnt.yml -l ocp-master-02a.lab1*
##   
##   PLAY [compute infra masters] *****************************************************************************************************************************************************
##   
##   TASK [Gathering Facts] ***********************************************************************************************************************************************************
##   ok: [ocp-master-02a.lab1.mydomclec.local]
##   
##   TASK [shell] *********************************************************************************************************************************************************************
##   changed: [ocp-master-02a.lab1.mydomclec.local]
##   
##   TASK [file] **********************************************************************************************************************************************************************
##   ok: [ocp-master-02a.lab1.mydomclec.local]
##   
##   TASK [shell] *********************************************************************************************************************************************************************
##   changed: [ocp-master-02a.lab1.mydomclec.local]
##   
##   TASK [debug] *********************************************************************************************************************************************************************
##   ok: [ocp-master-02a.lab1.mydomclec.local] => {
##       "output.stdout_lines": [
##           "",
##           "   INOTIFY",
##           "   WATCHER",
##           "    COUNT     PID     CMD",
##           "----------------------------------------",
##           "     957     6553  /usr/bin/hyperkube kubelet --v=2 --address=0.0.0.0 --allow-privileged=true --anonymous-auth=true --authentication-token-",
##           "      11      856  /usr/lib/systemd/systemd-udevd",
##           "      11     1457  /usr/bin/python2 -Es /usr/sbin/firewalld --nofork --nopid",
##           "      10     1471  /usr/sbin/rpc.gssd",
##           "       5        1  /usr/lib/systemd/systemd --switched-root --system --deserialize 22",
##           "       5        1  /usr/lib/systemd/systemd --switched-root --system --deserialize 22",
##           "       5     1508  /usr/sbin/NetworkManager --no-daemon",
##           "       4        1  /usr/lib/systemd/systemd --switched-root --system --deserialize 22",
##           "       4        1  /usr/lib/systemd/systemd --switched-root --system --deserialize 22",
##           "       4     1508  /usr/sbin/NetworkManager --no-daemon",
##           "       4     1378  /usr/lib/polkit-1/polkitd --no-debug",
##           "       3     4211  tail --follow=name /var/log/openvswitch/ovs-vswitchd.log /var/log/openvswitch/ovsdb-server.log",
##           "       3     1970  /usr/sbin/crond -n",
##           "       3     1378  /usr/lib/polkit-1/polkitd --no-debug",
##           "       2     1893  /usr/sbin/rsyslogd -n",
##           "       2     1389  /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation",
##           "       1     9012  virt-handler -v 3 --port 8443 --hostname-override ocp-master-02a.lab1.mydomclec.local --pod-ip-address 172.20.0.201",
##           "       1     9012  virt-handler -v 3 --port 8443 --hostname-override ocp-master-02a.lab1.mydomclec.local --pod-ip-address 172.20.0.201",
##           "       1     9012  virt-handler -v 3 --port 8443 --hostname-override ocp-master-02a.lab1.mydomclec.local --pod-ip-address 172.20.0.201",
##           "       1     9012  virt-handler -v 3 --port 8443 --hostname-override ocp-master-02a.lab1.mydomclec.local --pod-ip-address 172.20.0.201",
##           "       1     6553  /usr/bin/hyperkube kubelet --v=2 --address=0.0.0.0 --allow-privileged=true --anonymous-auth=true --authentication-token-",
##           "       1     6553  /usr/bin/hyperkube kubelet --v=2 --address=0.0.0.0 --allow-privileged=true --anonymous-auth=true --authentication-token-",
##           "       1        1  /usr/lib/systemd/systemd --switched-root --system --deserialize 22",
##           "       1     1388  /usr/sbin/sssd -i --logger=files",
##           "       1     1359  /usr/bin/abrt-watch-log -F BUG: WARNING: at WARNING: CPU: INFO: possible recursive locking detected ernel BUG at list_de",
##           "       1     1347  /usr/sbin/abrtd -d -s",
##           "       0     6553  /usr/bin/hyperkube kubelet --v=2 --address=0.0.0.0 --allow-privileged=true --anonymous-auth=true --authentication-token-"
##       ]
##   }
##   
##   TASK [shell] *********************************************************************************************************************************************************************
##   changed: [ocp-master-02a.lab1.mydomclec.local]
##   
##   TASK [debug] *********************************************************************************************************************************************************************
##   ok: [ocp-master-02a.lab1.mydomclec.local] => {
##       "output.stdout_lines": [
##           "fs.inotify.max_queued_events = 16384",
##           "fs.inotify.max_user_instances = 128",
##           "fs.inotify.max_user_watches = 65536"
##       ]
##   }
##   
##   PLAY RECAP ***********************************************************************************************************************************************************************
##   ocp-master-02a.lab1.mydomclec.local : ok=7    changed=3    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0
##   

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .