Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

bug: Resource temporarily unavailable #182

Open
Harshit933 opened this issue Jan 29, 2024 · 6 comments · Fixed by #227
Open

bug: Resource temporarily unavailable #182

Harshit933 opened this issue Jan 29, 2024 · 6 comments · Fixed by #227
Assignees
Labels
bug Something isn't working P-hight Hiight Priotity issue

Comments

@Harshit933
Copy link
Collaborator

This is the stack trace. When I tried to to ran lampo-cli getinfo.

2024-01-29T11:06:27.793Z INFO lampo_channel_manager listening on chain event on the channel manager. [lampod/src/ln/channe_manager.rs:145]
2024-01-29T11:06:27.796Z INFO lampo Litening for in-bound connection on 0.0.0.0:19735. [lampod/src/ln/peer_manager.rs:147]
2024-01-29T11:07:10.151Z INFO jsonrpc blocking with err Os { code: 11, kind: WouldBlock, message: "Resource temporarily unavailable" }!. [lampo-jsonrpc/src/lib.rs:225]
2024-01-29T11:07:10.151Z INFO jsonrpc buffer read {"method":"getinfo","params":{},"id":"0". [lampo-jsonrpc/src/lib.rs:232]

Although lampo does not crashes but it is not usable. Is this related to #120?

@vincenzopalazzo
Copy link
Owner

This is the stack trace.

It is not a stacktrace, is a log line at the info level

but it is not usable.

define not usable, WouldBlock is an expected error while you are trying to write async code

To me this is good, what is the behaviours that you are experiencing?

@Harshit933
Copy link
Collaborator Author

I did not get any output after running lampo-cli getinfo. This is what I got.

harshit@harshit:~$ lampo-cli getinfo
✗ JSON decode error: Connection reset by peer (os error 104)

@Harshit933 Harshit933 changed the title bug: Resource temporarily unavavailable bug: Resource temporarily unavailable Feb 5, 2024
@vincenzopalazzo
Copy link
Owner

Closing in favor of #184

@vincenzopalazzo
Copy link
Owner

I reproduced by changing cloud machine

➜  ~ lampo-cli --network testnet fundchannel --node_id 030b686a163aa2bba03cebb8bab7778fac251536498141df0a436d688352d426f6 --amount 4000000000 --public true --node_id 030b686a163aa2bba03cebb8bab7778fac251536498141df0a436d688352d426f6 --addr 65.108.246.14 --port 19735
✗ Error: JSON decode error: Connection reset by peer (os error 104)
➜  ~ lampo-cli --network testnet getinfo
✗ Error: IO error response: No such file or directory (os error 2)

I think the bug is inside the lampo-jsonrpc

@vincenzopalazzo vincenzopalazzo added the bug Something isn't working label Apr 16, 2024
@vincenzopalazzo vincenzopalazzo added this to the v24.06 milestone Apr 16, 2024
@Harshit933
Copy link
Collaborator Author

I think this could be related to the unixlistener. This is the documentation surrounding the set_nonblocking() method inside unixlistener.

/// This will result in the `accept` operation becoming nonblocking,
/// i.e., immediately returning from their calls. If the IO operation is
/// successful, `Ok` is returned and no further action is required. If the
/// IO operation could not be completed and needs to be retried, an error
/// with kind [`io::ErrorKind::WouldBlock`] is returned.

@vincenzopalazzo
Copy link
Owner

I think the problem is inside my jsonrpc implementation

@vincenzopalazzo vincenzopalazzo self-assigned this May 13, 2024
vincenzopalazzo added a commit that referenced this issue May 13, 2024
Link: #182
Signed-off-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com>
vincenzopalazzo added a commit that referenced this issue May 15, 2024
We already are forced to use tokio, so at this point
it is better that we use tokio and we leave our experimentation
for another memont

Link: #182
Signed-off-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com>
vincenzopalazzo added a commit that referenced this issue May 15, 2024
We already are forced to use tokio, so at this point
it is better that we use tokio and we leave our experimentation
for another memont

Link: #182
Signed-off-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com>
vincenzopalazzo added a commit that referenced this issue May 15, 2024
We already are forced to use tokio, so at this point
it is better that we use tokio and we leave our experimentation
for another memont

Link: #182
Signed-off-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com>
vincenzopalazzo added a commit that referenced this issue May 15, 2024
We already are forced to use tokio, so at this point
it is better that we use tokio and we leave our experimentation
for another memont

Link: #182
Signed-off-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com>
vincenzopalazzo added a commit that referenced this issue May 15, 2024
We already are forced to use tokio, so at this point
it is better that we use tokio and we leave our experimentation
for another memont

Link: #182
Signed-off-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com>
@vincenzopalazzo vincenzopalazzo added the P-hight Hiight Priotity issue label May 30, 2024
@vincenzopalazzo vincenzopalazzo removed this from the v24.06 milestone Jun 17, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working P-hight Hiight Priotity issue
Projects
Status: No status
2 participants