some mfstools.sh symlinks don't work (endless recursion) #886
Comments
fogti
changed the title
fogti
added a commit
to fogti/lizardfs
that referenced
this issue
Aug 12, 2020
Fixes lizardfs#886. An example error message was: LC_ALL=C bash -x /usr/bin/mfssetgoal --help ++ basename /usr/bin/mfssetgoal + tool=mfssetgoal + mfssetgoal --help bash: warning: shell level (1000) too high, resetting to 1
fogti
added a commit
to fogti/lizardfs
that referenced
this issue
Aug 12, 2020
Fixes lizardfs#886. An example error message was: LC_ALL=C bash -x /usr/bin/mfssetgoal --help ++ basename /usr/bin/mfssetgoal + tool=mfssetgoal + mfssetgoal --help bash: warning: shell level (1000) too high, resetting to 1
fogti
added a commit
to fogti/lizardfs
that referenced
this issue
Aug 20, 2020
Fixes lizardfs#886. An example error message was: LC_ALL=C bash -x /usr/bin/mfssetgoal --help ++ basename /usr/bin/mfssetgoal + tool=mfssetgoal + mfssetgoal --help bash: warning: shell level (1000) too high, resetting to 1
uristdwarf
added a commit
to leil-io/saunafs
that referenced
this issue
Mar 19, 2024
This test was problematic for a number reasons, from broken links and version tags to incompatible versions to recursive bash calls (that almost crashed my VM) to shadow not connecting to master. First was broken links. While this was generally easy to fix, previous LizardFS (rightly) did not include build information in the package versions. Including this information is problematic for both the script (which works around for the moment) and the user, since they both need to find the build information when downgrading, which is not standard behaviour expected of Debian packages. Second problem was incompatible version changes. It seems that #15 (thanks @lgsilva3087 for pointing me towards this) broke the expected behaviour of `saunafs-admin info` command, so older clients couldn't parse the requests. While this wasn't a problem for fixing the tests (since we shouldn't test mixed versions anyway), it reminded me about the problem of what is exactly our public API, and I believe that anything affecting protocol should be considered our public API in terms of semantic versioning. We should also test this API somehow, perhaps by using a custom client to check how they behave with newer versions of master/chunkserver/etc. Third was recursive bash. It seems this issue from LizardFS (lizardfs/lizardfs#886) came back knocking and almost crashed my VM. Seems it's problematic in our tests as well... Finally, newer shadow also had incompatibility with older master. Why I do not know, however for now I worked around by using the older shadow to start and then later switching over to newer once master is restarted. This may have not been the intention of the test though. Which brings me to my final point, and that is testing mix versions of SaunaFS. I don't see why this is exactly necessary, we shouldn't even probably allow newer versions to interact with older versions (that are in the SaunaFS repository, discarding custom clients) and require a full upgrade instead. This test doesn't do that, but gradually upgrades and checks if everything is working. Perhaps this test needs some rethinking. For now, I've kept the changes minimal.
uristdwarf
added a commit
to leil-io/saunafs
that referenced
this issue
Mar 19, 2024
This test was problematic for a number reasons, from broken links and version tags to incompatible versions to recursive bash calls (that almost crashed my VM) to shadow not connecting to master. First was broken links. While this was generally easy to fix, previous LizardFS (rightly) did not include build information in the package versions. Including this information is problematic for both the script (which works around for the moment) and the user, since they both need to find the build information when downgrading, which is not standard behaviour expected of Debian packages. Second problem was incompatible version changes. It seems that #15 (thanks @lgsilva3087 for pointing me towards this) broke the expected behaviour of `saunafs-admin info` command, so older clients couldn't parse the requests. While this wasn't a problem for fixing the tests (since we shouldn't test mixed versions anyway), it reminded me about the problem of what is exactly our public API, and I believe that anything affecting protocol should be considered our public API in terms of semantic versioning. We should also test this API somehow, perhaps by using a custom client to check how they behave with newer versions of master/chunkserver/etc. Third was recursive bash. It seems this issue from LizardFS (lizardfs/lizardfs#886) came back knocking and almost crashed my VM. Seems it's problematic in our tests as well... Finally, newer shadow also had incompatibility with older master. Why I do not know, however for now I worked around by using the older shadow to start and then later switching over to newer once master is restarted. This may have not been the intention of the test though. Which brings me to my final point, and that is testing mix versions of SaunaFS. I don't see why this is exactly necessary, we shouldn't even probably allow newer versions to interact with older versions (that are in the SaunaFS repository, discarding custom clients) and require a full upgrade instead. This test doesn't do that, but gradually upgrades and checks if everything is working. Perhaps this test needs some rethinking. For now, I've kept the changes minimal.
lgsilva3087
pushed a commit
to leil-io/saunafs
that referenced
this issue
Mar 23, 2024
This test was problematic for a number reasons, from broken links and version tags to incompatible versions to recursive bash calls (that almost crashed my VM) to shadow not connecting to master. First was broken links. While this was generally easy to fix, previous LizardFS (rightly) did not include build information in the package versions. Including this information is problematic for both the script (which works around for the moment) and the user, since they both need to find the build information when downgrading, which is not standard behaviour expected of Debian packages. Second problem was incompatible version changes. It seems that #15 (thanks @lgsilva3087 for pointing me towards this) broke the expected behaviour of `saunafs-admin info` command, so older clients couldn't parse the requests. While this wasn't a problem for fixing the tests (since we shouldn't test mixed versions anyway), it reminded me about the problem of what is exactly our public API, and I believe that anything affecting protocol should be considered our public API in terms of semantic versioning. We should also test this API somehow, perhaps by using a custom client to check how they behave with newer versions of master/chunkserver/etc. Third was recursive bash. It seems this issue from LizardFS (lizardfs/lizardfs#886) came back knocking and almost crashed my VM. Seems it's problematic in our tests as well... Finally, newer shadow also had incompatibility with older master. Why I do not know, however for now I worked around by using the older shadow to start and then later switching over to newer once master is restarted. This may have not been the intention of the test though. Which brings me to my final point, and that is testing mix versions of SaunaFS. I don't see why this is exactly necessary, we shouldn't even probably allow newer versions to interact with older versions (that are in the SaunaFS repository, discarding custom clients) and require a full upgrade instead. This test doesn't do that, but gradually upgrades and checks if everything is working. Perhaps this test needs some rethinking. For now, I've kept the changes minimal.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
mfstools.shcontains the following line:lizardfs/src/tools/mfstools.sh
Line 5 in 968f735
which leads to the following error(s) e.g.:
mfstools.shshould support both thelizardfsand themfsprefixes instead of hardcoding one of it.The text was updated successfully, but these errors were encountered: