If the process doesn't even exit when you send a SIGKILL, then it's not a problem which exists in userspace. My guess is the "freeze" is due to flushing the bytes to the device, and dd is waiting for this to complete. It really is trying to exit, but it's waiting for the kernel.

You're probably right. Did it again, then issued a `sudo sync'. This also hung until I physically removed the device.
Don't know how to proceed from here.... Kernel:
uname -a
Linux audhumla 4.6.3-1-ARCH #1 SMP PREEMPT Fri Jun 24 21:19:13 CEST 2016 x86_64 GNU/Linux

Well, found something in /var/log/errors.log:
kernel: blk_update_request: I/O error, dev sdc, sector 13102920
kernel: Buffer I/O error on dev sdc, logical block 1637865, lost async page write
kernel: Buffer I/O error on dev sdc, logical block 1637866, lost async page write
kernel: Buffer I/O error on dev sdc, logical block 1637867, lost async page write
(....)

Is it possible those are from when you physically pulled the device from the machine? Not sure why /var/log/errors.log would be populated....

That's possible. Actually it's probably that....

Anyway I think the device got poperly zero'd out. It's a 8GB memorystick. `lsblk -S'
sdc 7:0:0:0 disk SanDisk Cruzer Fit 1.27 usb
But having to yank it to get dd to exit feels a bit akward....

The point is that if you wait long enough, dd will exit on its own. I don't think there's any bug in coreutils here.

Dunno. I've waited for like half an hour after the device was filled and error message regarding that displayed before I yanked the device.
No sign of exit from dd. But I agree whatever caused it it's likely not a bug in coreutils, so this bug can probably be closed.
I'll use dd on an OpenBSD box instead.

For a cheap USB drive, half an hour to fill 8 GiB is not extraordinary. Some of them are really slow when writing [1]. 4 MiB/s for 1800 s would be 7200 MiB. In fact, I think the errors in your log files indicate that the kernel was still writing data when you pulled the drive.

FYI: You should be able to check the progress by sending SIGUSR1 to the dd process.

http://usbspeed.nirsoft.net/?pdesc=SanDisk+Cruzer+Fit&vname=SanDisk+Corp.&vid=1921&pid=21873

You misunderstand. I wrote "half an hour AFTER the device was filled". I did not state the time of writing before, which was indeed three quarters of an hour. The period is after the error message clearly stated that device is full. And then (another half an hour later), after yanking out device the message from dd is that megabytes according to size of device are indeed written. The half hour I describe occurred when writing was finished, and is also a hang. This have not happened me on Arch earlier, when I did similar things, and did not happen now when I took same two devices and did the same on an OpenBSD box (where the writing itself was slower, because it's a slow box).

> You misunderstand. I wrote "half an hour AFTER the device was filled"
Sorry, but the misunderstanding is on your side. The device *appears* full, but the data hasn't been physically written yet -- it's still buffered. Had it *actually* been full, the kernel wouldn't have complained when you yanked the device from the port (and dd would have exited).

You can probably change this behavior by forcing dd not to buffer (see the 'sync' option).

I'll test that. Will report back.

Seems you're right about that. Used commandline this time:
# dd if=/dev/zero of=/dev/sdc bs=4096 status=progress iflag=sync oflag=sync
It took like half an hour longer and this time dd returned after reporting device full.
I have never experienced this before, even having used dd quite a bit for different stuff. Have gnu dd changed in the use of buffer? The async buffer between read and write here in normal operation must be quite large...?

This is pretty typical behavior of Linux. It doesn't really have anything to do with dd, other than the fact that it's writing to a raw device rather than some sort of filesystem.