Is there a special device that causes read to block forever?

Clash Royale CLAN TAG#URR8PPP
up vote
1
down vote
favorite
IâÂÂm looking for a variant of /dev/null that causes read to block forever, rather than returning EOF immediately. Does such a device exist?
I could probably create a named pipe (via mkfifo) to achieve the desired effect, but IâÂÂd rather not have to deal with unlinking the FIFO at the end of the script.
For context, I want to wait for an RPC server to quit. To avoid polling, I open a connection via netcat:
netcat localhost 12345
The connection will be closed automatically when the server closes. Unfortunately, when running the command via SSH, stdin is set to /dev/null and so netcat exits immediately after sending EOF instead of waiting for the connection to close. netcat -d (donâÂÂt wait for stdin) has a bug? on macOS and spins hot, meaning the solution is actually worse than polling at a reasonable interval.
I have a solution to this problemâÂÂhooking stdin up to a pipeâÂÂbut I am specifically interested in the question as stated out of pure curiosity.
scripting
add a comment |Â
up vote
1
down vote
favorite
IâÂÂm looking for a variant of /dev/null that causes read to block forever, rather than returning EOF immediately. Does such a device exist?
I could probably create a named pipe (via mkfifo) to achieve the desired effect, but IâÂÂd rather not have to deal with unlinking the FIFO at the end of the script.
For context, I want to wait for an RPC server to quit. To avoid polling, I open a connection via netcat:
netcat localhost 12345
The connection will be closed automatically when the server closes. Unfortunately, when running the command via SSH, stdin is set to /dev/null and so netcat exits immediately after sending EOF instead of waiting for the connection to close. netcat -d (donâÂÂt wait for stdin) has a bug? on macOS and spins hot, meaning the solution is actually worse than polling at a reasonable interval.
I have a solution to this problemâÂÂhooking stdin up to a pipeâÂÂbut I am specifically interested in the question as stated out of pure curiosity.
scripting
Other than a FIFO with no writer?
â Ignacio Vazquez-Abrams
Feb 18 at 19:08
Heh, sorry, just clarified why I was hoping for a solution besides a FIFO. (I want to avoid the need to clean the FIFO up.)
â benesch
Feb 18 at 19:10
This sounds like a XY-Problem. What do you want to achieve by this?
â Stefan M
Feb 18 at 19:11
@Stefan M, I added context to the original question. YouâÂÂre right in that I have a solution that solves my original problem, but IâÂÂm still interested in whether a forever-blocking special device exists out of sheer curiosity.
â benesch
Feb 18 at 19:20
1
As for unlinking the FIFO, you can unlink it directly, and it will be cleaned up when netcat no longer has an open filehandle for it.
â frostschutz
Feb 18 at 19:24
add a comment |Â
up vote
1
down vote
favorite
up vote
1
down vote
favorite
IâÂÂm looking for a variant of /dev/null that causes read to block forever, rather than returning EOF immediately. Does such a device exist?
I could probably create a named pipe (via mkfifo) to achieve the desired effect, but IâÂÂd rather not have to deal with unlinking the FIFO at the end of the script.
For context, I want to wait for an RPC server to quit. To avoid polling, I open a connection via netcat:
netcat localhost 12345
The connection will be closed automatically when the server closes. Unfortunately, when running the command via SSH, stdin is set to /dev/null and so netcat exits immediately after sending EOF instead of waiting for the connection to close. netcat -d (donâÂÂt wait for stdin) has a bug? on macOS and spins hot, meaning the solution is actually worse than polling at a reasonable interval.
I have a solution to this problemâÂÂhooking stdin up to a pipeâÂÂbut I am specifically interested in the question as stated out of pure curiosity.
scripting
IâÂÂm looking for a variant of /dev/null that causes read to block forever, rather than returning EOF immediately. Does such a device exist?
I could probably create a named pipe (via mkfifo) to achieve the desired effect, but IâÂÂd rather not have to deal with unlinking the FIFO at the end of the script.
For context, I want to wait for an RPC server to quit. To avoid polling, I open a connection via netcat:
netcat localhost 12345
The connection will be closed automatically when the server closes. Unfortunately, when running the command via SSH, stdin is set to /dev/null and so netcat exits immediately after sending EOF instead of waiting for the connection to close. netcat -d (donâÂÂt wait for stdin) has a bug? on macOS and spins hot, meaning the solution is actually worse than polling at a reasonable interval.
I have a solution to this problemâÂÂhooking stdin up to a pipeâÂÂbut I am specifically interested in the question as stated out of pure curiosity.
scripting
edited Feb 18 at 20:17
asked Feb 18 at 19:07
benesch
1064
1064
Other than a FIFO with no writer?
â Ignacio Vazquez-Abrams
Feb 18 at 19:08
Heh, sorry, just clarified why I was hoping for a solution besides a FIFO. (I want to avoid the need to clean the FIFO up.)
â benesch
Feb 18 at 19:10
This sounds like a XY-Problem. What do you want to achieve by this?
â Stefan M
Feb 18 at 19:11
@Stefan M, I added context to the original question. YouâÂÂre right in that I have a solution that solves my original problem, but IâÂÂm still interested in whether a forever-blocking special device exists out of sheer curiosity.
â benesch
Feb 18 at 19:20
1
As for unlinking the FIFO, you can unlink it directly, and it will be cleaned up when netcat no longer has an open filehandle for it.
â frostschutz
Feb 18 at 19:24
add a comment |Â
Other than a FIFO with no writer?
â Ignacio Vazquez-Abrams
Feb 18 at 19:08
Heh, sorry, just clarified why I was hoping for a solution besides a FIFO. (I want to avoid the need to clean the FIFO up.)
â benesch
Feb 18 at 19:10
This sounds like a XY-Problem. What do you want to achieve by this?
â Stefan M
Feb 18 at 19:11
@Stefan M, I added context to the original question. YouâÂÂre right in that I have a solution that solves my original problem, but IâÂÂm still interested in whether a forever-blocking special device exists out of sheer curiosity.
â benesch
Feb 18 at 19:20
1
As for unlinking the FIFO, you can unlink it directly, and it will be cleaned up when netcat no longer has an open filehandle for it.
â frostschutz
Feb 18 at 19:24
Other than a FIFO with no writer?
â Ignacio Vazquez-Abrams
Feb 18 at 19:08
Other than a FIFO with no writer?
â Ignacio Vazquez-Abrams
Feb 18 at 19:08
Heh, sorry, just clarified why I was hoping for a solution besides a FIFO. (I want to avoid the need to clean the FIFO up.)
â benesch
Feb 18 at 19:10
Heh, sorry, just clarified why I was hoping for a solution besides a FIFO. (I want to avoid the need to clean the FIFO up.)
â benesch
Feb 18 at 19:10
This sounds like a XY-Problem. What do you want to achieve by this?
â Stefan M
Feb 18 at 19:11
This sounds like a XY-Problem. What do you want to achieve by this?
â Stefan M
Feb 18 at 19:11
@Stefan M, I added context to the original question. YouâÂÂre right in that I have a solution that solves my original problem, but IâÂÂm still interested in whether a forever-blocking special device exists out of sheer curiosity.
â benesch
Feb 18 at 19:20
@Stefan M, I added context to the original question. YouâÂÂre right in that I have a solution that solves my original problem, but IâÂÂm still interested in whether a forever-blocking special device exists out of sheer curiosity.
â benesch
Feb 18 at 19:20
1
1
As for unlinking the FIFO, you can unlink it directly, and it will be cleaned up when netcat no longer has an open filehandle for it.
â frostschutz
Feb 18 at 19:24
As for unlinking the FIFO, you can unlink it directly, and it will be cleaned up when netcat no longer has an open filehandle for it.
â frostschutz
Feb 18 at 19:24
add a comment |Â
1 Answer
1
active
oldest
votes
up vote
0
down vote
You can create one with cryptsetup (or, I guess, dmsetup works too).
# truncate -s 8M luksblock.img
# cryptsetup luksFormat luksblock.img
# cryptsetup luksOpen luksblock.img luksblock
# cryptsetup luksSuspend luksblock
# cat /dev/mapper/luksblock
( ... no output because it's blocked / suspended ... )
What it looks like in dmsetup:
# dmsetup info luksblock
Name: luksblock
State: SUSPENDED
Read Ahead: 256
Tables present: LIVE
Open count: 0
Event number: 0
Major, minor: 253, 71
Number of targets: 1
UUID: CRYPT-LUKS1-87bc6d9fd7fa419bbf15425c062d0916-luksblock
You can use dmsetup to suspend a device:
dmsetup suspend luksblock
So it should be possible to create a suspended device mapping that does not need to be backed by a luksblock.img file in the first place, but I will leave that final bit to you. :-P
Of course this approach has a major downside. This device will be listed among all the other block devices in /proc/partitions, and everything that monitors or detects devices (like LVM looking for new physical volumes) will try to read and get stuck on the block as well. This will stop devices from being detected (because the processes doing so are stuck) and the machine might no longer reboot either (because the processes handling shutdown procedures are stuck).
add a comment |Â
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
0
down vote
You can create one with cryptsetup (or, I guess, dmsetup works too).
# truncate -s 8M luksblock.img
# cryptsetup luksFormat luksblock.img
# cryptsetup luksOpen luksblock.img luksblock
# cryptsetup luksSuspend luksblock
# cat /dev/mapper/luksblock
( ... no output because it's blocked / suspended ... )
What it looks like in dmsetup:
# dmsetup info luksblock
Name: luksblock
State: SUSPENDED
Read Ahead: 256
Tables present: LIVE
Open count: 0
Event number: 0
Major, minor: 253, 71
Number of targets: 1
UUID: CRYPT-LUKS1-87bc6d9fd7fa419bbf15425c062d0916-luksblock
You can use dmsetup to suspend a device:
dmsetup suspend luksblock
So it should be possible to create a suspended device mapping that does not need to be backed by a luksblock.img file in the first place, but I will leave that final bit to you. :-P
Of course this approach has a major downside. This device will be listed among all the other block devices in /proc/partitions, and everything that monitors or detects devices (like LVM looking for new physical volumes) will try to read and get stuck on the block as well. This will stop devices from being detected (because the processes doing so are stuck) and the machine might no longer reboot either (because the processes handling shutdown procedures are stuck).
add a comment |Â
up vote
0
down vote
You can create one with cryptsetup (or, I guess, dmsetup works too).
# truncate -s 8M luksblock.img
# cryptsetup luksFormat luksblock.img
# cryptsetup luksOpen luksblock.img luksblock
# cryptsetup luksSuspend luksblock
# cat /dev/mapper/luksblock
( ... no output because it's blocked / suspended ... )
What it looks like in dmsetup:
# dmsetup info luksblock
Name: luksblock
State: SUSPENDED
Read Ahead: 256
Tables present: LIVE
Open count: 0
Event number: 0
Major, minor: 253, 71
Number of targets: 1
UUID: CRYPT-LUKS1-87bc6d9fd7fa419bbf15425c062d0916-luksblock
You can use dmsetup to suspend a device:
dmsetup suspend luksblock
So it should be possible to create a suspended device mapping that does not need to be backed by a luksblock.img file in the first place, but I will leave that final bit to you. :-P
Of course this approach has a major downside. This device will be listed among all the other block devices in /proc/partitions, and everything that monitors or detects devices (like LVM looking for new physical volumes) will try to read and get stuck on the block as well. This will stop devices from being detected (because the processes doing so are stuck) and the machine might no longer reboot either (because the processes handling shutdown procedures are stuck).
add a comment |Â
up vote
0
down vote
up vote
0
down vote
You can create one with cryptsetup (or, I guess, dmsetup works too).
# truncate -s 8M luksblock.img
# cryptsetup luksFormat luksblock.img
# cryptsetup luksOpen luksblock.img luksblock
# cryptsetup luksSuspend luksblock
# cat /dev/mapper/luksblock
( ... no output because it's blocked / suspended ... )
What it looks like in dmsetup:
# dmsetup info luksblock
Name: luksblock
State: SUSPENDED
Read Ahead: 256
Tables present: LIVE
Open count: 0
Event number: 0
Major, minor: 253, 71
Number of targets: 1
UUID: CRYPT-LUKS1-87bc6d9fd7fa419bbf15425c062d0916-luksblock
You can use dmsetup to suspend a device:
dmsetup suspend luksblock
So it should be possible to create a suspended device mapping that does not need to be backed by a luksblock.img file in the first place, but I will leave that final bit to you. :-P
Of course this approach has a major downside. This device will be listed among all the other block devices in /proc/partitions, and everything that monitors or detects devices (like LVM looking for new physical volumes) will try to read and get stuck on the block as well. This will stop devices from being detected (because the processes doing so are stuck) and the machine might no longer reboot either (because the processes handling shutdown procedures are stuck).
You can create one with cryptsetup (or, I guess, dmsetup works too).
# truncate -s 8M luksblock.img
# cryptsetup luksFormat luksblock.img
# cryptsetup luksOpen luksblock.img luksblock
# cryptsetup luksSuspend luksblock
# cat /dev/mapper/luksblock
( ... no output because it's blocked / suspended ... )
What it looks like in dmsetup:
# dmsetup info luksblock
Name: luksblock
State: SUSPENDED
Read Ahead: 256
Tables present: LIVE
Open count: 0
Event number: 0
Major, minor: 253, 71
Number of targets: 1
UUID: CRYPT-LUKS1-87bc6d9fd7fa419bbf15425c062d0916-luksblock
You can use dmsetup to suspend a device:
dmsetup suspend luksblock
So it should be possible to create a suspended device mapping that does not need to be backed by a luksblock.img file in the first place, but I will leave that final bit to you. :-P
Of course this approach has a major downside. This device will be listed among all the other block devices in /proc/partitions, and everything that monitors or detects devices (like LVM looking for new physical volumes) will try to read and get stuck on the block as well. This will stop devices from being detected (because the processes doing so are stuck) and the machine might no longer reboot either (because the processes handling shutdown procedures are stuck).
edited Feb 19 at 12:40
answered Feb 18 at 19:18
frostschutz
24.5k14774
24.5k14774
add a comment |Â
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f425006%2fis-there-a-special-device-that-causes-read-to-block-forever%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Other than a FIFO with no writer?
â Ignacio Vazquez-Abrams
Feb 18 at 19:08
Heh, sorry, just clarified why I was hoping for a solution besides a FIFO. (I want to avoid the need to clean the FIFO up.)
â benesch
Feb 18 at 19:10
This sounds like a XY-Problem. What do you want to achieve by this?
â Stefan M
Feb 18 at 19:11
@Stefan M, I added context to the original question. YouâÂÂre right in that I have a solution that solves my original problem, but IâÂÂm still interested in whether a forever-blocking special device exists out of sheer curiosity.
â benesch
Feb 18 at 19:20
1
As for unlinking the FIFO, you can unlink it directly, and it will be cleaned up when netcat no longer has an open filehandle for it.
â frostschutz
Feb 18 at 19:24