mirror of
https://github.com/s3fs-fuse/s3fs-fuse.git
synced 2026-04-25 21:35:58 +03:00
[GH-ISSUE #2029] S3FS hanging on Ubuntu 22.04 on AWS EC2 instance #1018
Labels
No labels
bug
bug
dataloss
duplicate
enhancement
feature request
help wanted
invalid
need info
performance
pull-request
question
question
testing
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/s3fs-fuse#1018
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @jpedrick on GitHub (Sep 8, 2022).
Original GitHub issue: https://github.com/s3fs-fuse/s3fs-fuse/issues/2029
Additional Information
Linux Distribution: Ubuntu 22.04 stock AWS AMI as of 2022-08-08
Version of s3fs being used (s3fs --version)
V9.1 compiled from source
Version of fuse being used (pkg-config --modversion fuse, rpm -qi fuse, dpkg -s fuse)
Fuse Version: 3.10.5
Kernel information (uname -r)
_command result: 5.15.0-1019-aws
GNU/Linux Distribution, if applicable (cat /etc/os-release)
_command result:
s3fs command line used, if applicable
/etc/fstab entry, if applicable
s3fs syslog messages (grep s3fs /var/log/syslog, journalctl | grep s3fs, or s3fs outputs)
if you execute s3fs with dbglevel, curldbg option, you can get detail debug messages
Details about issue
After the above output the program seems to just hang.
my-bucket is a placeholder for the actual s3 bucket I am trying to access.
@ggtakec commented on GitHub (Sep 24, 2022):
You run by specifying
url=https://s3.ap-east-1.amazonaws.comon the command line, but it seems to be accessing the instance metadata URL(169.254.169.254and port 80).Normally, I think s3fs would access the host as
s3.ap-east-1.amazonaws.com.Please check if you have set anything such as hosts or proxy or etc.
@porelli commented on GitHub (Dec 5, 2022):
The instance metadata url is to retrieve the token and then the credentials. After retrieving the credentials it will connect to the specified S3 endpoint.
I did encounter the same problem using Debian 11, I tried the s3fs-fuse package both in the stable and testing repositories and also the latest release checked out of git.
The interesting part is that the AWS CLI works and also invoking the IMDSv2 manually doesn't seem to behave any differently. However, for some reasons, s3fs-fuse hangs while trying to retrieve the same set of credentials in the same way when running on Debian or Ubuntu.
The very same command and settings worked without any issue on another Amazon Linux sharing the same VPC, security group and role.
@ggtakec commented on GitHub (Jan 12, 2023):
@porelli I'm sorry for my fault about not noticing your
iam_roleoption and metadata url.And I was able to reproduce the problem you pointed out, so I'll investigate.
@ggtakec commented on GitHub (Jan 12, 2023):
@porelli
It seems that the instance you are using cannot use
IMDSv2, so you can avoid the problem by setting it to useIMDSv1.Specifying
iam_rolewill tryIMDSv2first and fall back toIMDSv1if that fails. However, this phenomenon occurs because it does not supportIMDSv2.So you can specify
imdsv1onlyoption to avoid it.I think this option will solve your problem.
Please try it.
@porelli commented on GitHub (Jan 16, 2023):
Thank you for checking!
If it was, I'm not sure why the Debian instance had IMDSv2 disabled. Surely it should have had at least the IMDSv1 enabled but I do not have the instance anymore to re-try.
You are 100% correct, with the "-o imdsv1only" I can successfully mount the bucket. Altough, I'm not able to see the entire content. I suspect this might be because it was created manuall and not using using s3fs.
Regarding IMDSv2, I collected some more data that might be helpful for further investigation.
I just tried again with the latest code in the git repo and I can still reproduce the same problem on a new instance that definitely has both IMDSv1 and IMDSv2 enabled:
IMDSv1:
IMDSv2:
IMDSv2 with wrong token:
S3FS hangs as @jpedrick reported in this ticket:
If I press ctrl+c it continues but then hangs again:
At this point, if I try to access the folder from another terminal, the shell hangs there. Pressing CTRL+C once more in the original shell:
For the record, both instance and bucket are in us-east-2. If I do not specify the '-o url=https://s3.us-east-2.amazonaws.com/' option I get similar behaviour but after the two CTRL-C the log ends with:
aws cli is working as expected and can see the entire bucket content:
@ggtakec commented on GitHub (Jan 22, 2023):
I think that the not-found objects created using tools other than s3fs can be resolved by adding the
compat_diroption.(Because the default behavior of s3fs has changed, objects will be invisible if this option is not given.)
We will continue to investigate this report.
@ggtakec commented on GitHub (Feb 12, 2023):
I believe this issue is resolved by merging #2103. (See #2098)
This issue will be closed, but please reopen it if you still have problems.
@jacky96623 commented on GitHub (Feb 13, 2023):
Hi @ggtakec , thanks for the fix! May I know usually it takes how much time for the latest change to be reflected in Linux repository?
@ggtakec commented on GitHub (Feb 19, 2023):
@jacky96623
I think it will be reflected after we release(tag)...It is a few weeks?
(Official packaging is done by another great collaborator, so I can't state in detail)
@jacky96623 commented on GitHub (Feb 19, 2023):
@ggtakec Thanks for the information. I asked the question since it appears to me that the latest version of s3fs (1.91), which was released nearly a year ago, is not yet available in the official repositories of some Linux, e.g., Ubuntu 22.04. I was just wondering if I should try building the latest version from source code by myself.
Perhaps I should just wait for some time more - hopefully it is just the repository owner/maintainer needing time to review/evaluate.