Troubleshooting Apache Kudu

Issues Starting or Restarting the Master or Tablet Server

Error during hole punch test

Kudu requires hole punching capabilities in order to be efficient. Support for hole punching depends on your operating system kernel version and local filesystem. On Linux, hole punching is the use of the fallocate() system call with the FALLOC_FL_PUNCH_HOLE option set.
  • RHEL or CentOS 6.4 or later, patched to kernel version of 2.6.32-358 or later. Unpatched RHEL or CentOS 6.4 does not include a kernel with support for hole punching.
  • Ubuntu 14.04 includes version 3.13 of the Linux kernel, which supports hole punching.
  • Newer versions of the EXT4 or XFS filesystems support hole punching, but EXT3 does not. Older versions of XFS that do not support hole punching return a EOPNOTSUPP (operation not supported) error. Older versions of either EXT4 or XFS that do not support hole punching cause Kudu to emit an error message such as the following and to fail to start:
    Error during hole punch test. The log block manager requires a
    filesystem with hole punching support such as ext4 or xfs. On el6,
    kernel version 2.6.32-358 or newer is required. To run without hole
    punching (at the cost of some efficiency and scalability), reconfigure
    Kudu with --block_manager=file. Refer to the Kudu documentation for more
    details. Raw error message follows.
  • Without hole punching support, the log block manager will never delete blocks and progressively occupy even more space on disk, which makes it unsafe to use.
  • If you can’t use hole punching in your environment, you can still try Kudu. Enable the file block manager instead of the log block manager by adding the --block_manager=file flag to the commands you use to start the master and tablet servers. Note that the file block manager does not scale as well as the log block manager, and should only be used for small-scale deployments.

Clock is not synchronized

The clock on each Kudu master and tablet server daemon must be synchronized using Network Time Protocol (NTP). If NTP is not installed or is not running, you may see errors such as the following:
I0929 10:00:26.570979 21371] Initializing master server...
F0929 10:00:26.571107 21371] Check failed: _s.ok() Bad status: Service unavailable: Clock is not synchronized:
  Error reading clock. Clock considered unsynchronized. Errno: Invalid argument] Initializing tablet server...
F0929 10:00:26.572041 21370] Check failed: _s.ok() Bad status: Service unavailable: Clock is not synchronized:
  Error reading clock. Clock considered unsynchronized. Errno: Success

To resolve such errors, make sure that NTP is installed on each master and tablet server, and that all NTP processes synchronize to the same time source.

  • To install NTP, use the command appropriate for your operating system:

    OS Command


    sudo apt-get install ntp


    sudo yum install ntp

  • If NTP is installed but the clock is reported as unsynchronized, Kudu will not start, and will emit a message such as:

    F0924 20:24:36.336809 14550 Couldn't get the current time: Clock unsynchronized. Status: Service unavailable: Error reading clock. Clock considered unsynchronized.

    You can monitor clock synchronization status by running the ntptime command. The relevant value is what is reported for maximum error. Note that NTP requires a network connection and may take a few minutes to synchronize the clock. In some cases a spotty network connection may make NTP report the clock as unsynchronized. A common, though temporary, workaround for this is to restart NTP with one of the following commands.

    OS Command


    sudo service ntp restart


    sudo /etc/init.d/ntpd restart

  • In addition to the clocks being synchronized, the maximum clock error (not to be mistaken with the estimated error) must be set to a value relevant to your deployment. The default value is 10 seconds, but it can be configured using the --max_clock_sync_error_usec flag.

    If NTP is installed and synchronized, but the maximum clock error is too high, you will see a message such as:

    Sep 17, 8:13:09.873 PM FATAL Couldn't get the current time: Clock synchronized, but error: 11130000, is past the maximum allowable error: 10000000


    Sep 17, 8:32:31.135 PM FATAL Check failed: _s.ok() Bad status: Service unavailable: Cannot initialize clock: Cannot initialize HybridClock. Clock synchronized but error was too high (11711000 us).

    If NTP reports the clock as synchronized, but the maximum error is consistently too high, you can increase the threshold to a higher value by setting the max_clock_sync_error_usec flag. For example, to increase the maximum error to 20 seconds, set the flag as follows: --max_clock_sync_error_usec=20000000. script exits with the too few arguments error

The script, which is used to create a new Impala_Kudu service or clone one from an existing Apache Impala (incubating) service, takes a different number of required arguments when using the create and clone operations.

If you use the create option without specifying scratch directories, the script will fail with the error create: error: too few arguments. Re-run the command, specifying scratch directories: create <scratch_dirs> <service_name> --cluster <cluster_name> create /data/impala IMPALA_KUDU-1 --cluster 'Cluster 1'

Troubleshooting Performance Issues

Kudu Tracing

The Kudu master and tablet server daemons include built-in support for tracing based on the open source Chromium Tracing framework. You can use tracing to diagnose latency issues or other problems on Kudu servers.

Accessing the Tracing Web Interface

The tracing interface is part of the embedded web server in each of the Kudu daemons, and can be accessed using a web browser. Note that while the interface has been known to work in recent versions of Google Chrome, other browsers may not work as expected.

Daemon URL

Tablet Server




Saving Traces

After you have collected traces, you can save these traces as JSON files by clicking Save. To load and analyze a saved JSON file, click Load and choose the file.

RPC Timeout Traces

If client applications are experiencing RPC timeouts, the Kudu tablet server WARNING level logs should contain a log entry which includes an RPC-level trace. For example:

W0922 00:56:52.313848 10858] Call kudu.consensus.ConsensusService.UpdateConsensus
from (request call id 3555909) took 1464ms (client timeout 1000).
W0922 00:56:52.314888 10858] Trace:
0922 00:56:50.849505 (+     0us)] Inserting onto call queue
0922 00:56:50.849527 (+    22us)] Handling call
0922 00:56:50.849574 (+    47us)] Updating replica for 2 ops
0922 00:56:50.849628 (+    54us)] Early marking committed up to term: 8 index: 880241
0922 00:56:50.849968 (+   340us)] Triggering prepare for 2 ops
0922 00:56:50.850119 (+   151us)] Serialized 1555 byte log entry
0922 00:56:50.850213 (+    94us)] Marking committed up to term: 8 index: 880241
0922 00:56:50.850218 (+     5us)] Updating last received op as term: 8 index: 880243
0922 00:56:50.850219 (+     1us)] Filling consensus response to leader.
0922 00:56:50.850221 (+     2us)] Waiting on the replicates to finish logging
0922 00:56:52.313763 (+1463542us)] finished
0922 00:56:52.313764 (+     1us)] UpdateReplicas() finished
0922 00:56:52.313788 (+    24us)] Queueing success response

These traces can indicate which part of the request was slow. Make sure you include them when filing bug reports related to RPC latency outliers.

Kernel Stack Watchdog Traces

Each Kudu server process has a background thread called the Stack Watchdog, which monitors other threads in the server in case they are blocked for longer-than-expected periods of time. These traces can indicate operating system issues or bottle-necked storage.

When the watchdog thread identifies a case of thread blockage, it logs an entry in the WARNING log as follows:

W0921 23:51:54.306350 10912] Thread 10937 stuck at /data/kudu/consensus/ for 537ms:
Kernel stack:
[<ffffffffa00b209d>] do_get_write_access+0x29d/0x520 [jbd2]
[<ffffffffa00b2471>] jbd2_journal_get_write_access+0x31/0x50 [jbd2]
[<ffffffffa00fe6d8>] __ext4_journal_get_write_access+0x38/0x80 [ext4]
[<ffffffffa00d9b23>] ext4_reserve_inode_write+0x73/0xa0 [ext4]
[<ffffffffa00d9b9c>] ext4_mark_inode_dirty+0x4c/0x1d0 [ext4]
[<ffffffffa00d9e90>] ext4_dirty_inode+0x40/0x60 [ext4]
[<ffffffff811ac48b>] __mark_inode_dirty+0x3b/0x160
[<ffffffff8119c742>] file_update_time+0xf2/0x170
[<ffffffff8111c1e0>] __generic_file_aio_write+0x230/0x490
[<ffffffff8111c4c8>] generic_file_aio_write+0x88/0x100
[<ffffffffa00d3fb1>] ext4_file_write+0x61/0x1e0 [ext4]
[<ffffffff81180f5b>] do_sync_readv_writev+0xfb/0x140
[<ffffffff81181ee6>] do_readv_writev+0xd6/0x1f0
[<ffffffff81182046>] vfs_writev+0x46/0x60
[<ffffffff81182102>] sys_pwritev+0xa2/0xc0
[<ffffffff8100b072>] system_call_fastpath+0x16/0x1b
[<ffffffffffffffff>] 0xffffffffffffffff

User stack:
    @       0x3a1ace10c4  (unknown)
    @          0x1262103  (unknown)
    @          0x12622d4  (unknown)
    @          0x12603df  (unknown)
    @           0x8e7bfb  (unknown)
    @           0x8f478b  (unknown)
    @           0x8f55db  (unknown)
    @          0x12a7b6f  (unknown)
    @       0x3a1b007851  (unknown)
    @       0x3a1ace894d  (unknown)
    @              (nil)  (unknown)

These traces can be useful for diagnosing root-cause latency issues in Kudu especially when they are caused by underlying systems such as disk controllers or file systems.