starred/s3fs-fuse

Fork 0

mirror of https://github.com/s3fs-fuse/s3fs-fuse.git synced 2026-04-25 05:16:00 +03:00

[GH-ISSUE #986] Is there any way to check if data is mounted already? #547

New issue

Closed

opened 2026-03-04 01:46:38 +03:00 by kerem · 9 comments

kerem commented

2026-03-04 01:46:38 +03:00

Owner

Originally created by @soolaugust on GitHub (Mar 22, 2019).
Original GitHub issue: https://github.com/s3fs-fuse/s3fs-fuse/issues/986

Hi,

I am trying to use s3fs-fuse docker image as init container in Kubernetes, as init container need to be completed status eventually. so is there any way to check if data is mounted already and stop s3fs-fuse process.

Any idea for this?

Originally created by @soolaugust on GitHub (Mar 22, 2019). Original GitHub issue: https://github.com/s3fs-fuse/s3fs-fuse/issues/986 Hi, I am trying to use s3fs-fuse docker image as init container in Kubernetes, as init container need to be completed status eventually. so is there any way to check if data is mounted already and stop s3fs-fuse process. Any idea for this?

kerem closed this issue

2026-03-04 01:46:38 +03:00

kerem commented

2026-03-04 01:46:39 +03:00

Author

Owner

@soolaugust commented on GitHub (Mar 22, 2019):

I solved by using mount | grep s3fs, current seems okay. If any better idea, please contact me. Thanks ❤️

@soolaugust commented on GitHub (Mar 22, 2019): I solved by using `mount | grep s3fs`, current seems okay. If any better idea, please contact me. Thanks ❤️

kerem commented

2026-03-04 01:46:39 +03:00

Author

Owner

@kahing commented on GitHub (Mar 22, 2019):

There's also a mountpoint command

@kahing commented on GitHub (Mar 22, 2019): There's also a `mountpoint` command

kerem commented

2026-03-04 01:46:39 +03:00

Author

Owner

@gaul commented on GitHub (Mar 25, 2019):

Does -o nonempty address this issue?

@gaul commented on GitHub (Mar 25, 2019): Does `-o nonempty` address this issue?

kerem commented

2026-03-04 01:46:39 +03:00

Author

Owner

@soolaugust commented on GitHub (Mar 25, 2019):

@kahing mountpoint is better, thx 👍

@gaul -o nonempty will check if target directory is not empty. If not empty, will not mount. this is a little different from my situation, I need to check mount is successfully or not.

@soolaugust commented on GitHub (Mar 25, 2019): @kahing `mountpoint` is better, thx 👍 @gaul `-o nonempty` will check if target directory is not empty. If not empty, will not mount. this is a little different from my situation, I need to check mount is successfully or not.

kerem commented

2026-03-04 01:46:39 +03:00

Author

Owner

@gaul commented on GitHub (Mar 25, 2019):

@soolaugust Would it help if s3fs had a mode that was similar to -f but only ran in background when the mount was successful?

@gaul commented on GitHub (Mar 25, 2019): @soolaugust Would it help if s3fs had a mode that was similar to `-f` but only ran in background when the mount was successful?

kerem commented

2026-03-04 01:46:39 +03:00

Author

Owner

@soolaugust commented on GitHub (Mar 26, 2019):

@gaul I think this way would be helpful for other situations. As process in init container should exit eventually, so s3fs should exit instead of running in background in my situation.

@soolaugust commented on GitHub (Mar 26, 2019): @gaul I think this way would be helpful for other situations. As process in init container should exit eventually, so s3fs should exit instead of running in background in my situation.

kerem commented

2026-03-04 01:46:39 +03:00

Author

Owner

@gaul commented on GitHub (Mar 26, 2019):

This is a bit tricky since s3fs should only check in the foreground for interactive terminals. When run headless, e.g., fstab, performing a network operation could stall the boot process. Maybe checking isatty suffices?

@gaul commented on GitHub (Mar 26, 2019): This is a bit tricky since s3fs should only check in the foreground for interactive terminals. When run headless, e.g., fstab, performing a network operation could stall the boot process. Maybe checking `isatty` suffices?

kerem commented

2026-03-04 01:46:39 +03:00

Author

Owner

@kahing commented on GitHub (Mar 26, 2019):

Stalling the boot process is the right thing to do given that if you mount it in fstab you may need the data at boot time (or container start up time). NFS for instance has a bg mount option that you can adopt for the opposite behavior.

@kahing commented on GitHub (Mar 26, 2019): Stalling the boot process is the right thing to do given that if you mount it in fstab you may need the data at boot time (or container start up time). NFS for instance has a bg mount option that you can adopt for the opposite behavior.

kerem commented

2026-03-04 01:46:39 +03:00

Author

Owner

@soolaugust commented on GitHub (Mar 26, 2019):

Thanks, I will check those ideas :)

@soolaugust commented on GitHub (Mar 26, 2019): Thanks, I will check those ideas :)