Ctrl+C doesn't interrupt process waiting for I/O - Kernel

This is a discussion on Ctrl+C doesn't interrupt process waiting for I/O - Kernel ; Hi, I have encountered the following situation several times, but I've been unable to come up with a way to reproduce this until now: - some process is keeping the disk busy (some cron job for example: updatedb, chkrootkit, ...) ...

+ Reply to Thread
Page 1 of 3 1 2 3 LastLast
Results 1 to 20 of 46

Thread: Ctrl+C doesn't interrupt process waiting for I/O

  1. Ctrl+C doesn't interrupt process waiting for I/O

    Hi,

    I have encountered the following situation several times, but I've been
    unable to come up with a way to reproduce this until now:
    - some process is keeping the disk busy (some cron job for example:
    updatedb, chkrootkit, ...)
    - other processes that want to do I/O have to wait (this is normal)
    - I have a (I/O bound) process running in my terminal, and I want to
    interrupt it with Ctrl+C
    - I type Ctrl+C several times, and the process is not interrupted for
    several seconds (10-30 secs)
    - if I type Ctrl+Z, and use kill %1 the process dies faster than
    waiting for it to react to Ctrl+C

    This issue occurs both on my x86-64 machine that uses reiserfs, and on
    my x86 machine that uses XFS, so it doesn't seem related to the
    underlying FS.
    I use 2.6.25-2 and 2.6.26-rc8 now; I don't recall seeing this behaviour
    with old kernels (IIRC I see this since 2.6.21 or 2.6.23).

    Is this intended behaviour, or should I report a bug?

    If it should be considered a bug, I will try several kernels to see if
    there is a particular kernel version that introduced this behaviour.

    To reproduce this issue here is a testcase:
    Step 1: Run this shell script in a terminal in X (gnome-terminal,
    konsole, ...):
    #!/bin/sh
    # choose a size that will keep the disks busy for about half a minute or
    more
    dd if=/dev/zero of=xt bs=100M count=4&
    dd if=/dev/zero of=yt bs=100M count=4&
    rm xt
    rm yt
    wait %1 %2

    Step 2: Run latencytop
    Step 3: In another terminal run an I/O bound process and try to
    interrupt it with Ctrl+C, see how fast it responds, for example:
    edwin@thunder:~/tst$ find / >/dev/null
    find: `/boot/lost+found': Permission denied
    ^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C ^C^C^C^C^C^C
    edwin@thunder:~/tst$

    Step 4: repeat step 3 until you get a behaviour like the above (repeat
    20-30 times, it doesn't always happen, when it happens you have to press
    Ctrl+C several times in order for the process to react)

    Here is the output of /proc/latency_stats when this situation occured,
    notice that even select has a high latency:

    Latency Top version : v0.1
    555 202326 4994 do_sys_poll sys_poll sysenter_past_esp
    430 515897 4994 do_select core_sys_select sys_select sysenter_past_esp
    12 1140 1013 tty_wait_until_sent set_termios tty_mode_ioctl n_tty_ioctl
    tty_ioctl vfs_ioctl do_vfs_ioctl sys_ioctl sysenter_past_esp
    434 60405 4522 do_select core_sys_select sys_select sysenter_past_esp
    21 244388 54486 blk_execute_rq scsi_execute scsi_execute_req
    sr_test_unit_ready sr_media_change media_changed cdrom_media_changed
    sr_block_media_changed check_disk_change cdrom_open sr_block_open do_open
    21 44988 7252 blk_execute_rq scsi_execute scsi_execute_req
    sr_test_unit_ready sr_drive_status cdrom_ioctl sr_block_ioctl
    blkdev_driver_ioctl blkdev_ioctl block_ioctl vfs_ioctl do_vfs_ioctl
    7 7052 1185 blk_execute_rq scsi_execute sr_do_ioctl sr_packet
    cdrom_get_media_event sr_drive_status cdrom_ioctl sr_block_ioctl
    blkdev_driver_ioctl blkdev_ioctl block_ioctl vfs_ioctl
    7 4399 735 blk_execute_rq scsi_execute scsi_execute_req
    ioctl_internal_command scsi_set_medium_removal sr_lock_door
    cdrom_release sr_block_release __blkdev_put blkdev_put blkdev_close __fput
    32 5646 3269 sys_epoll_wait sysenter_past_esp
    14 14108 3260 futex_wait do_futex sys_futex sysenter_past_esp
    4 5257 4095 futex_wait do_futex sys_futex sysenter_past_esp
    7 2712 1396 pipe_wait pipe_read do_sync_read vfs_read sys_read
    sysenter_past_esp
    2 0 0 pipe_wait pipe_read do_sync_read vfs_read sys_read sysenter_past_esp
    208 1996603 953067 xfs_ilock xfs_iomap __xfs_get_blocks xfs_get_blocks
    __block_prepare_write block_write_begin xfs_vm_write_begin
    generic_file_buffered_write xfs_write xfs_file_aio_write do_sync_write
    vfs_write
    21 10264428 915514 get_request_wait __make_request generic_make_request
    submit_bio xfs_submit_ioend_bio xfs_submit_ioend xfs_page_state_convert
    xfs_vm_writepage __writepage write_cache_pages generic_writepages
    xfs_vm_writepages
    26 3369263 2260529 down xfs_buf_iowait xfs_buf_iostart
    xfs_buf_read_flags xfs_trans_read_buf xfs_imap_to_bp xfs_itobp xfs_iread
    xfs_iget_core xfs_iget xfs_lookup xfs_vn_lookup
    1 17888 17888 down xfs_buf_iowait xfs_buf_iostart xfs_buf_read_flags
    xfs_trans_read_buf xfs_da_do_buf xfs_da_read_buf xfs_dir2_block_getdents
    xfs_readdir xfs_file_readdir vfs_readdir sys_getdents64
    2 8226 7641 down xfs_buf_iowait xfs_buf_iostart xfs_buf_read_flags
    xfs_trans_read_buf xfs_da_do_buf xfs_da_read_buf xfs_dir2_leaf_getdents
    xfs_readdir xfs_file_readdir vfs_readdir sys_getdents64
    2 16090 10971 down xfs_buf_iowait xfs_buf_iostart xfs_buf_read_flags
    xfs_trans_read_buf xfs_da_do_buf xfs_da_read_buf
    xfs_dir2_leaf_lookup_int xfs_dir2_leaf_lookup xfs_dir_lookup xfs_lookup
    xfs_vn_lookup
    1 2149 2149 down xfs_buf_lock _xfs_buf_find xfs_buf_get_flags
    xfs_buf_read_flags xfs_trans_read_buf xfs_da_do_buf xfs_da_read_buf
    xfs_dir2_leaf_getdents xfs_readdir xfs_file_readdir vfs_readdir
    2 0 0 unix_stream_recvmsg sock_recvmsg sys_recvfrom sys_recv
    sys_socketcall sysenter_past_esp
    43 1340361 1336178 xfs_ilock xfs_iomap xfs_map_blocks
    xfs_page_state_convert xfs_vm_writepage __writepage write_cache_pages
    generic_writepages xfs_vm_writepages do_writepages
    __writeback_single_inode sync_sb_inodes
    1 6 6 xfs_ilock xfs_iomap_write_allocate xfs_iomap xfs_map_blocks
    xfs_page_state_convert xfs_vm_writepage __writepage write_cache_pages
    generic_writepages xfs_vm_writepages do_writepages __writeback_single_inode
    64 1052948 21773 congestion_wait __alloc_pages_internal __alloc_pages
    __grab_cache_page block_write_begin xfs_vm_write_begin
    generic_file_buffered_write xfs_write xfs_file_aio_write do_sync_write
    vfs_write sys_write
    3 5264928 3610252 sync_page wait_on_page_bit
    wait_on_page_writeback_range filemap_fdatawait xfs_fsync xfs_file_fsync
    do_fsync __do_fsync sys_fsync sysenter_past_esp
    1 284000 284000 get_request_wait __make_request generic_make_request
    submit_bio _xfs_buf_ioapply xfs_buf_iorequest xlog_bdstrat_cb xlog_sync
    xlog_state_release_iclog xlog_state_sync _xfs_log_force _xfs_trans_commit
    3 1724786 1319135 xlog_state_sync _xfs_log_force _xfs_trans_commit
    xfs_fsync xfs_file_fsync do_fsync __do_fsync sys_fsync sysenter_past_esp
    3 2851878 1642865 down xfs_buf_lock _xfs_buf_find xfs_buf_get_flags
    xfs_buf_read_flags xfs_trans_read_buf xfs_alloc_read_agf
    xfs_alloc_fix_freelist xfs_alloc_vextent xfs_bmap_btalloc xfs_bmap_alloc
    xfs_bmapi
    17 43 23 xfs_ilock xfs_iomap_write_allocate xfs_iomap xfs_map_blocks
    xfs_page_state_convert xfs_vm_writepage shrink_page_list
    shrink_inactive_list shrink_zone try_to_free_pages
    __alloc_pages_internal __alloc_pages
    1 45 45 down xfs_buf_lock _xfs_buf_find xfs_buf_get_flags
    xfs_buf_read_flags xfs_trans_read_buf xfs_btree_read_bufs
    xfs_alloc_lookup xfs_alloc_lookup_eq xfs_alloc_fixup_trees
    xfs_alloc_ag_vextent_size xfs_alloc_ag_vextent
    1 539 539 congestion_wait __alloc_pages_internal __alloc_pages
    handle_mm_fault do_page_fault error_code
    2 26759 21339 congestion_wait __alloc_pages_internal __alloc_pages
    __get_free_pages proc_file_read proc_reg_read vfs_read sys_read
    sysenter_past_esp
    6 96540 19159 congestion_wait __alloc_pages_internal __alloc_pages
    __get_free_pages __pollwait unix_poll sock_poll do_select
    core_sys_select sys_select sysenter_past_esp
    2 53244 47209 mempool_alloc bio_alloc_bioset bio_alloc
    xfs_alloc_ioend_bio xfs_submit_ioend xfs_page_state_convert
    xfs_vm_writepage __writepage write_cache_pages generic_writepages
    xfs_vm_writepages do_writepages
    1 425375 425375 sync_page __lock_page find_lock_page filemap_fault
    __do_fault handle_mm_fault do_page_fault error_code

    Best regards,
    --Edwin
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  2. Re: Ctrl+C doesn't interrupt process waiting for I/O

    Török Edwin wrote:
    > Hi,
    >
    > I have encountered the following situation several times, but I've been
    > unable to come up with a way to reproduce this until now:
    > - some process is keeping the disk busy (some cron job for example:
    > updatedb, chkrootkit, ...)
    > - other processes that want to do I/O have to wait (this is normal)
    > - I have a (I/O bound) process running in my terminal, and I want to
    > interrupt it with Ctrl+C
    > - I type Ctrl+C several times, and the process is not interrupted for
    > several seconds (10-30 secs)
    > - if I type Ctrl+Z, and use kill %1 the process dies faster than
    > waiting for it to react to Ctrl+C
    >
    > This issue occurs both on my x86-64 machine that uses reiserfs, and on
    > my x86 machine that uses XFS, so it doesn't seem related to the
    > underlying FS.
    > I use 2.6.25-2 and 2.6.26-rc8 now; I don't recall seeing this behaviour
    > with old kernels (IIRC I see this since 2.6.21 or 2.6.23).
    >
    > Is this intended behaviour, or should I report a bug?
    >


    Yes, it's intended behaviour. Filesystem IO syscalls are considered
    "fast" and are interruptible. Usermode code can reasonably expect that
    file IO will never return EINTR.

    That said, if a program is blocking for tens of seconds in block IO,
    then that could be a problem in itself.

    J
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  3. Re: Ctrl+C doesn't interrupt process waiting for I/O

    Jeremy Fitzhardinge wrote:
    > Yes, it's intended behaviour. Filesystem IO syscalls are considered
    > "fast" and are interruptible.


    Er, *un*interruptible.

    J
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  4. Re: Ctrl+C doesn't interrupt process waiting for I/O

    Jeremy Fitzhardinge wrote:
    > Török Edwin wrote:
    >> Hi,
    >>
    >> I have encountered the following situation several times, but I've been
    >> unable to come up with a way to reproduce this until now:
    >> - some process is keeping the disk busy (some cron job for example:
    >> updatedb, chkrootkit, ...)
    >> - other processes that want to do I/O have to wait (this is normal)
    >> - I have a (I/O bound) process running in my terminal, and I want to
    >> interrupt it with Ctrl+C
    >> - I type Ctrl+C several times, and the process is not interrupted for
    >> several seconds (10-30 secs)
    >> - if I type Ctrl+Z, and use kill %1 the process dies faster than
    >> waiting for it to react to Ctrl+C
    >>
    >> This issue occurs both on my x86-64 machine that uses reiserfs, and on
    >> my x86 machine that uses XFS, so it doesn't seem related to the
    >> underlying FS.
    >> I use 2.6.25-2 and 2.6.26-rc8 now; I don't recall seeing this behaviour
    >> with old kernels (IIRC I see this since 2.6.21 or 2.6.23).
    >>
    >> Is this intended behaviour, or should I report a bug?
    >>

    >
    > Yes, it's intended behaviour. Filesystem IO syscalls are considered
    > "fast" and are interruptible. Usermode code can reasonably expect
    > that file IO will never return EINTR.


    That's filesystem dependent; if you mount an nfs filesystem with the
    'intr' mount option, it will be interruptible (which makes sense, as it
    is impossible to guarantee the server's responsiveness).

    --
    I have a truly marvellous patch that fixes the bug which this
    signature is too narrow to contain.

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  5. Re: Ctrl+C doesn't interrupt process waiting for I/O

    Avi Kivity wrote:
    >>
    >> Yes, it's intended behaviour. Filesystem IO syscalls are considered
    >> "fast" and are interruptible. Usermode code can reasonably expect
    >> that file IO will never return EINTR.

    >
    > That's filesystem dependent; if you mount an nfs filesystem with the
    > 'intr' mount option, it will be interruptible (which makes sense, as
    > it is impossible to guarantee the server's responsiveness).


    'intr' is a pretty bad idea, and I would never recommend it ('soft' is
    better). It's an excellent way to destroy data when a stray signal
    causes a syscall to fail with EINTR in an unexpected way (write being
    the obvious one, but link, unlink, truncate or even close can fail in
    odd ways can cause havok).

    I don't know of any other filesystem with a similarly bad option.

    J
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  6. Re: Ctrl+C doesn't interrupt process waiting for I/O

    Jeremy Fitzhardinge wrote:
    > Avi Kivity wrote:
    >>>
    >>> Yes, it's intended behaviour. Filesystem IO syscalls are considered
    >>> "fast" and are interruptible. Usermode code can reasonably expect
    >>> that file IO will never return EINTR.

    >>
    >> That's filesystem dependent; if you mount an nfs filesystem with the
    >> 'intr' mount option, it will be interruptible (which makes sense, as
    >> it is impossible to guarantee the server's responsiveness).

    >
    > 'intr' is a pretty bad idea, and I would never recommend it ('soft' is
    > better). It's an excellent way to destroy data when a stray signal
    > causes a syscall to fail with EINTR in an unexpected way (write being
    > the obvious one, but link, unlink, truncate or even close can fail in
    > odd ways can cause havok).
    >


    Applications should not assume that write() (or other syscalls) can't
    return EINTR. Not all filesystems have a bounded-time backing store.

    'soft' has its own problems; namely false positives when someone steps
    on the network cable, temporarily blocking packet flow, or when using a
    clustered server which may take some time to recover from a fault.


    --
    Do not meddle in the internals of kernels, for they are subtle and quick to panic.

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  7. Re: Ctrl+C doesn't interrupt process waiting for I/O

    Avi Kivity wrote:
    > Applications should not assume that write() (or other syscalls) can't
    > return EINTR. Not all filesystems have a bounded-time backing store.


    The distinction between 'fast' (filesystem) and 'slow' (terminals and
    pipes) blocking syscalls goes back to the earliest days of Unix, and is
    part of the ABI. Most filesystem syscalls are not documented to ever
    return EINTR.

    > 'soft' has its own problems; namely false positives when someone steps
    > on the network cable, temporarily blocking packet flow, or when using
    > a clustered server which may take some time to recover from a fault.


    Sure. It's the basic problem of trying to make network access
    transparent by hiding the failure modes. You either need to put up with
    spurious timeouts caused by transient failures, or unbounded blocking on
    real failures.

    Regardless, NFS is the exception here, and making normal block-backed
    filesystems start throwing EINTRs around would be a huge behavioural change.

    J
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  8. Re: Ctrl+C doesn't interrupt process waiting for I/O

    Jeremy Fitzhardinge wrote:
    > Török Edwin wrote:
    >> Hi,
    >>
    >> I have encountered the following situation several times, but I've been
    >> unable to come up with a way to reproduce this until now:
    >> - some process is keeping the disk busy (some cron job for example:
    >> updatedb, chkrootkit, ...)
    >> - other processes that want to do I/O have to wait (this is normal)
    >> - I have a (I/O bound) process running in my terminal, and I want to
    >> interrupt it with Ctrl+C
    >> - I type Ctrl+C several times, and the process is not interrupted for
    >> several seconds (10-30 secs)
    >> - if I type Ctrl+Z, and use kill %1 the process dies faster than
    >> waiting for it to react to Ctrl+C
    >>
    >> This issue occurs both on my x86-64 machine that uses reiserfs, and on
    >> my x86 machine that uses XFS, so it doesn't seem related to the
    >> underlying FS.
    >> I use 2.6.25-2 and 2.6.26-rc8 now; I don't recall seeing this behaviour
    >> with old kernels (IIRC I see this since 2.6.21 or 2.6.23).
    >>
    >> Is this intended behaviour, or should I report a bug?
    >>

    >
    > Yes, it's intended behaviour. Filesystem IO syscalls are considered
    > "fast" and are interruptible. Usermode code can reasonably expect
    > that file IO will never return EINTR.


    Ok.

    >
    > That said, if a program is blocking for tens of seconds in block IO,
    > then that could be a problem in itself.


    In that case I don't think that a program doing heavy I/O (writeout of
    100Mb+) should be able to block other processes waiting for I/O on the
    same device for tens of seconds.
    I am using CFQ as I/O scheduler now, I will try the other I/O schedulers
    (especially deadline) and see if I get better behaviour.

    Is there any documentation on the tunable values for CFQ? (in
    Documentation/block there is only about anticipatory and deadline).

    Best regards,
    --Edwin

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  9. Re: Ctrl+C doesn't interrupt process waiting for I/O

    Jeremy Fitzhardinge wrote:
    > Török Edwin wrote:
    >> ...
    >> - I have a (I/O bound) process running in my terminal, and I want to
    >> interrupt it with Ctrl+C
    >> - I type Ctrl+C several times, and the process is not interrupted for
    >> several seconds (10-30 secs)
    >> - if I type Ctrl+Z, and use kill %1 the process dies faster than
    >> waiting for it to react to Ctrl+C

    >
    > Yes, it's intended behaviour. Filesystem IO syscalls are considered
    > "fast" and are interruptible. Usermode code can reasonably expect
    > that file IO will never return EINTR.


    This does not address the symptom that the process can be killed quicker
    by sending a SIGTERM. I've noticed the problem, too (2.6.25.) I wonder
    if it isn't some strangeness in the tty layer (hence the interrupt key
    is slower than an explicitly sent signal.)
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  10. Re: Ctrl+C doesn't interrupt process waiting for I/O

    Jeremy Fitzhardinge wrote:
    > Avi Kivity wrote:
    >> Applications should not assume that write() (or other syscalls) can't
    >> return EINTR. Not all filesystems have a bounded-time backing store.

    >
    > The distinction between 'fast' (filesystem) and 'slow' (terminals and
    > pipes) blocking syscalls goes back to the earliest days of Unix, and
    > is part of the ABI. Most filesystem syscalls are not documented to
    > ever return EINTR.


    POSIX documents EINTR for write(), and the manpage on my Linux distro
    says the same.
    However I don't think introducing EINTR would be beneficial (it will
    likely cause applications that don't expect it to break).

    >
    >> 'soft' has its own problems; namely false positives when someone
    >> steps on the network cable, temporarily blocking packet flow, or when
    >> using a clustered server which may take some time to recover from a
    >> fault.

    >
    > Sure. It's the basic problem of trying to make network access
    > transparent by hiding the failure modes. You either need to put up
    > with spurious timeouts caused by transient failures, or unbounded
    > blocking on real failures.
    >
    > Regardless, NFS is the exception here, and making normal block-backed
    > filesystems start throwing EINTRs around would be a huge behavioural
    > change.


    Agreed.

    Best regards,
    --Edwin
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  11. Re: Ctrl+C doesn't interrupt process waiting for I/O

    Jeremy Fitzhardinge writes:

    >> I have encountered the following situation several times, but I've been
    >> unable to come up with a way to reproduce this until now:
    >> - some process is keeping the disk busy (some cron job for example:
    >> updatedb, chkrootkit, ...)
    >> - other processes that want to do I/O have to wait (this is normal)
    >> - I have a (I/O bound) process running in my terminal, and I want to
    >> interrupt it with Ctrl+C
    >> - I type Ctrl+C several times, and the process is not interrupted for
    >> several seconds (10-30 secs)
    >> - if I type Ctrl+Z, and use kill %1 the process dies faster than
    >> waiting for it to react to Ctrl+C
    >>
    >> This issue occurs both on my x86-64 machine that uses reiserfs, and on
    >> my x86 machine that uses XFS, so it doesn't seem related to the
    >> underlying FS.
    >> I use 2.6.25-2 and 2.6.26-rc8 now; I don't recall seeing this behaviour
    >> with old kernels (IIRC I see this since 2.6.21 or 2.6.23).
    >>
    >> Is this intended behaviour, or should I report a bug?
    >>

    >
    > Yes, it's intended behaviour. Filesystem IO syscalls are considered
    > "fast" and are interruptible. Usermode code can reasonably expect
    > that file IO will never return EINTR.
    >
    > That said, if a program is blocking for tens of seconds in block IO,
    > then that could be a problem in itself.


    Still there's the effect that Ctrl-Z+kill works faster than Ctrl-C
    that is not explained by this. This has often annoyed me too.
    I'm not sure why it is. In theory they should be the same unless
    someone blocks SIGINT.

    -Andi
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  12. Re: Ctrl+C doesn't interrupt process waiting for I/O

    > Applications should not assume that write() (or other syscalls) can't
    > return EINTR. Not all filesystems have a bounded-time backing store.


    Unix tradition (and thus almost all applications) believe file store
    writes to be non signal interruptible. It would not be safe or practical
    to change that guarantee.

    Alan
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  13. Re: Ctrl+C doesn't interrupt process waiting for I/O

    Andi Kleen wrote:
    > Still there's the effect that Ctrl-Z+kill works faster than Ctrl-C
    > that is not explained by this. This has often annoyed me too.
    > I'm not sure why it is. In theory they should be the same unless
    > someone blocks SIGINT.
    >


    I'd never noticed that. That's just weird.

    J
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  14. Re: Ctrl+C doesn't interrupt process waiting for I/O

    Jeremy Fitzhardinge wrote:
    > Avi Kivity wrote:
    >> Applications should not assume that write() (or other syscalls) can't
    >> return EINTR. Not all filesystems have a bounded-time backing store.

    >
    > The distinction between 'fast' (filesystem) and 'slow' (terminals and
    > pipes) blocking syscalls goes back to the earliest days of Unix, and is
    > part of the ABI. Most filesystem syscalls are not documented to ever
    > return EINTR.
    >
    >> 'soft' has its own problems; namely false positives when someone steps
    >> on the network cable, temporarily blocking packet flow, or when using
    >> a clustered server which may take some time to recover from a fault.

    >
    > Sure. It's the basic problem of trying to make network access
    > transparent by hiding the failure modes. You either need to put up with
    > spurious timeouts caused by transient failures, or unbounded blocking on
    > real failures.
    >

    Basic problem is that you can get a process which you can't interrupt
    (in in most cases can't kill) which has resources tied up. Given the
    choice between surprising a process with an EINTR or killing it during a
    reboot to get the system usable again, I would rather surprise.

    The current situation is infrequent but not unheard of. And the causes
    are not all rooted in NFS, I used to see this 4-5 times a year when I
    was running nntp clusters with heavily threaded applications, every once
    in a while some thread would hang in a waiting for i/o state and could
    be killed or fixed. I can't see that an application error would result
    in a thread being left waiting i/o and uninterruptable, that's a kernel
    state.

    --
    Bill Davidsen
    "We have more to fear from the bungling of the incompetent than from
    the machinations of the wicked." - from Slashdot
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  15. Re: Ctrl+C doesn't interrupt process waiting for I/O

    Jeremy Fitzhardinge wrote:
    > Andi Kleen wrote:
    >> Still there's the effect that Ctrl-Z+kill works faster than Ctrl-C
    >> that is not explained by this. This has often annoyed me too.
    >> I'm not sure why it is. In theory they should be the same unless
    >> someone blocks SIGINT.
    >>

    >
    > I'd never noticed that. That's just weird.
    >

    I occationally see this - although I rarely run loads so heavy that it
    is a real problem. Ctrl-C - nothing happens except maybe a ^C printed -
    kill it from another rxvt.

    Could it be some sort of tty locking issue, holding up Ctrl-C processing
    while the heavily loaded machine suffer lock contention?

    Last time I saw this was a erroneous script that called itself without
    exec. With 2G memory and 3G of swap in use, the system was slow. the
    mouse cursor moved only now and then. Very little happened
    with Ctrl-C. Closing the rxvt running this script then caused a lot of
    disk activity and the system slowly came back to normal.

    Helge Hafting
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  16. Re: Ctrl+C doesn't interrupt process waiting for I/O

    On Sat, Jun 28, 2008 at 10:13:54PM -0700, Jeremy Fitzhardinge wrote:
    > Avi Kivity wrote:
    >>>
    >>> Yes, it's intended behaviour. Filesystem IO syscalls are considered
    >>> "fast" and are interruptible. Usermode code can reasonably expect
    >>> that file IO will never return EINTR.

    >>
    >> That's filesystem dependent; if you mount an nfs filesystem with the
    >> 'intr' mount option, it will be interruptible (which makes sense, as
    >> it is impossible to guarantee the server's responsiveness).

    >
    > 'intr' is a pretty bad idea, and I would never recommend it ('soft' is
    > better).


    Yipes.

    > It's an excellent way to destroy data when a stray signal
    > causes a syscall to fail with EINTR in an unexpected way (write being
    > the obvious one, but link, unlink, truncate or even close can fail in
    > odd ways can cause havok).


    And with "soft" all that can happen with the need for the stray
    signal....

    I suppose the relative likelihoods of hitting the problem under "soft"
    and "intr" may vary depending on the details of your setup. But in
    general I'd've thought it'd be easier to control stray signals than,
    say, stray network problems.

    --b.

    > I don't know of any other filesystem with a similarly bad option.

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  17. Re: Ctrl+C doesn't interrupt process waiting for I/O

    Török Edwin wrote:
    > Hi,
    >
    > I have encountered the following situation several times, but I've been
    > unable to come up with a way to reproduce this until now:
    > - some process is keeping the disk busy (some cron job for example:
    > updatedb, chkrootkit, ...)
    > - other processes that want to do I/O have to wait (this is normal)
    > - I have a (I/O bound) process running in my terminal, and I want to
    > interrupt it with Ctrl+C
    > - I type Ctrl+C several times, and the process is not interrupted for
    > several seconds (10-30 secs)
    > - if I type Ctrl+Z, and use kill %1 the process dies faster than
    > waiting for it to react to Ctrl+C


    The following patch to 2.6.26-rc8 fixes the issue for me. Perhaps we
    really want to do something else, but since I'm not all that familiar
    with the standard behaviour on other Unices and since the comment
    describing the changed order of function calls in the original commit
    didn't give the reason for that change, I leave that to more
    knowledgeable people.

    Regards,

    Elias


    --------
    From: Elias Oltmanns
    Subject: Make sure that interrupt characters get through reliably

    Since commit ec5b1157f8e819c72fc93aa6d2d5117c08cdc961, users have been
    unable to interrupt interactive processes reliably by pressing CTRL+C.
    This patch reverts the original commit except for the most important
    part: actually echoing ^C is preserved.

    Signed-off-by: Elias Oltmanns
    ---

    drivers/char/n_tty.c | 13 +------------
    1 files changed, 1 insertions(+), 12 deletions(-)

    diff --git a/drivers/char/n_tty.c b/drivers/char/n_tty.c
    index 8096389..74018ef 100644
    --- a/drivers/char/n_tty.c
    +++ b/drivers/char/n_tty.c
    @@ -759,20 +759,9 @@ static inline void n_tty_receive_char(struct tty_struct *tty, unsigned char c)
    signal = SIGTSTP;
    if (c == SUSP_CHAR(tty)) {
    send_signal:
    - /*
    - * Echo character, and then send the signal.
    - * Note that we do not use isig() here because we want
    - * the order to be:
    - * 1) flush, 2) echo, 3) signal
    - */
    - if (!L_NOFLSH(tty)) {
    - n_tty_flush_buffer(tty);
    - tty_driver_flush_buffer(tty);
    - }
    if (L_ECHO(tty))
    echo_char(c, tty);
    - if (tty->pgrp)
    - kill_pgrp(tty->pgrp, signal, 1);
    + isig(signal, tty, 0);
    return;
    }
    }
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  18. Re: Ctrl+C doesn't interrupt process waiting for I/O

    Elias Oltmanns wrote:
    [...]
    > The following patch to 2.6.26-rc8 fixes the issue for me.


    Sorry, resending without MIME encoding the message.

    Regards,

    Elias


    --------
    From: Elias Oltmanns
    Subject: Make sure that interrupt characters get through reliably

    Since commit ec5b1157f8e819c72fc93aa6d2d5117c08cdc961, users have been
    unable to interrupt interactive processes reliably by pressing CTRL+C.
    This patch reverts the original commit except for the most important
    part: actually echoing ^C is preserved.

    Signed-off-by: Elias Oltmanns
    ---

    drivers/char/n_tty.c | 13 +------------
    1 files changed, 1 insertions(+), 12 deletions(-)

    diff --git a/drivers/char/n_tty.c b/drivers/char/n_tty.c
    index 8096389..74018ef 100644
    --- a/drivers/char/n_tty.c
    +++ b/drivers/char/n_tty.c
    @@ -759,20 +759,9 @@ static inline void n_tty_receive_char(struct tty_struct *tty, unsigned char c)
    signal = SIGTSTP;
    if (c == SUSP_CHAR(tty)) {
    send_signal:
    - /*
    - * Echo character, and then send the signal.
    - * Note that we do not use isig() here because we want
    - * the order to be:
    - * 1) flush, 2) echo, 3) signal
    - */
    - if (!L_NOFLSH(tty)) {
    - n_tty_flush_buffer(tty);
    - tty_driver_flush_buffer(tty);
    - }
    if (L_ECHO(tty))
    echo_char(c, tty);
    - if (tty->pgrp)
    - kill_pgrp(tty->pgrp, signal, 1);
    + isig(signal, tty, 0);
    return;
    }
    }
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  19. Re: Ctrl+C doesn't interrupt process waiting for I/O

    Elias Oltmanns wrote:
    > Elias Oltmanns wrote:
    > [...]
    >
    >> The following patch to 2.6.26-rc8 fixes the issue for me.
    >>

    >
    > Sorry, resending without MIME encoding the message.
    >
    > Regards,
    >
    > Elias
    >
    >
    > --------
    > From: Elias Oltmanns
    > Subject: Make sure that interrupt characters get through reliably
    >
    > Since commit ec5b1157f8e819c72fc93aa6d2d5117c08cdc961, users have been
    > unable to interrupt interactive processes reliably by pressing CTRL+C.
    > This patch reverts the original commit except for the most important
    > part: actually echoing ^C is preserved.
    >


    Thanks for the patch , the process seems to respond faster to Ctrl-C,
    but I'll have to find a way to measure that reliably.
    However ^C is not echoed anymore for me.

    Best regards,
    --Edwin
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  20. Re: Ctrl+C doesn't interrupt process waiting for I/O

    Elias Oltmanns wrote:
    > - if (!L_NOFLSH(tty)) {
    > - n_tty_flush_buffer(tty);
    > - tty_driver_flush_buffer(tty);
    > - }
    > if (L_ECHO(tty))
    > echo_char(c, tty);
    > - if (tty->pgrp)
    > - kill_pgrp(tty->pgrp, signal, 1);
    > + isig(signal, tty, 0);


    My first reaction is that tty->pgrp must be null. Perhaps the patch
    could be simplified...

    if (tty->pgrp)
    kill_pgrp(tty->pgrp, signal, 1);
    + else
    + isig(signal, tty, 0);


    Thoughts?
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

+ Reply to Thread
Page 1 of 3 1 2 3 LastLast