[tarantool-patches] Re: [PATCH v2] travis-ci: fix OSX max files limits

[tarantool-patches] Re: [PATCH v2] travis-ci: fix OSX max files limits

[Alexander Turenko]

Still cannot say whether this is good or bad (don't know enough about
Mac OS). The only comment from me is about `echo password | sudo <...>`,
see
https://www.freelists.org/post/tarantool-patches/PATCH-v1-travisci-fix-OSX-max-files-limits,1

If you need LGTM from me, then I formally ok. Let's proceed with Kirill
(CCed).

[tarantool-patches] [PATCH v2] travis-ci: fix OSX max files limits

[Alexander V. Tikhonov]

Increased the maximum number of open file descriptors on macOS.

Travis-ci: needed the "ulimit -n <value>" call, because found
that the tests fail without it even with launchctl limit tool set.

Gitlab-ci: needed the "launchctl limit maxfiles <value>" call,
because under gitlib-ci it is needed the password to change the
limits and we call the sudo tool which separates the local set
of the environment.

Closes #4373
---

Github: https://github.com/tarantool/tarantool/tree/avtikhon/gh-4373-travis-osx-files
Issue: https://github.com/tarantool/tarantool/issues/4373

 .travis.mk | 31 +++++++++++++++----------------
 1 file changed, 15 insertions(+), 16 deletions(-)

diff --git a/.travis.mk b/.travis.mk
index 7d349bc21..6e0afc0b1 100644
--- a/.travis.mk
+++ b/.travis.mk
@@ -134,22 +134,21 @@ build_osx:
 	make -j
 
 test_osx_no_deps: build_osx
-	# Increase the maximum number of open file descriptors on macOS
-	echo tarantool | sudo -S echo "Initialize sudo for the next commands..." :
-	sudo sysctl -w kern.maxfiles=${MAX_FILES} || echo tarantool | sudo -S sysctl -w kern.maxfiles=${MAX_FILES} || :
-	sysctl -w kern.maxfiles || :
-	sudo sysctl -w kern.maxfilesperproc=${MAX_FILES} || echo tarantool | sudo -S sysctl -w kern.maxfilesperproc=${MAX_FILES} || :
-	sysctl -w kern.maxfilesperproc || :
-	sudo launchctl limit maxfiles ${MAX_FILES} || echo tarantool | sudo -S launchctl limit maxfiles ${MAX_FILES} || :
-	launchctl limit maxfiles || :
-	sudo ulimit -S -n ${MAX_FILES} || echo tarantool | sudo -S ulimit -S -n ${MAX_FILES} || :
-	ulimit -S -n || :
-	sudo ulimit -H -n ${MAX_FILES} || echo tarantool | sudo -S ulimit -H -n ${MAX_FILES} || :
-	ulimit -H -n
-	# temporary excluded replication/ suite with some tests from other suites by issues #4357 and #4370
-	cd test && ./test-run.py --force $(TEST_RUN_EXTRA_PARAMS) \
-		app/ app-tap/ box/ box-py/ box-tap/ engine/ engine_long/ long_run-py/ luajit-tap/ \
-		replication-py/ small/ sql/ sql-tap/ swim/ unit/ vinyl/ wal_off/ xlog/ xlog-py/
+	# Limits: Increase the maximum number of open file descriptors on macOS:
+	#   Travis-ci needs the "ulimit -n <value>" call
+	#   Gitlab-ci needs the "launchctl limit maxfiles <value>" call
+	# Also gitlib-ci needs the password to change the limits, while
+	# travis-ci runs under root user. Limit setup must be in the same
+	# call as tests runs call.
+	# Tests: Temporary excluded replication/ suite with some tests
+	#        from other suites by issues #4357 and #4370
+	echo tarantool | sudo -S launchctl limit maxfiles ${MAX_FILES} || : ; \
+		launchctl limit maxfiles || : ; \
+		ulimit -n ${MAX_FILES} || : ; \
+		ulimit -n ; \
+		cd test && ./test-run.py --force $(TEST_RUN_EXTRA_PARAMS) \
+			app/ app-tap/ box/ box-py/ box-tap/ engine/ engine_long/ long_run-py/ luajit-tap/ \
+			replication-py/ small/ sql/ sql-tap/ swim/ unit/ vinyl/ wal_off/ xlog/ xlog-py/
 
 test_osx: deps_osx test_osx_no_deps
 
-- 
2.17.1

[tarantool-patches] Re: [PATCH v2] travis-ci: fix OSX max files limits

[Kirill Yukhin]

Hello,

On 25 июл 14:33, Alexander V. Tikhonov wrote:
> Increased the maximum number of open file descriptors on macOS.
> 
> Travis-ci: needed the "ulimit -n <value>" call, because found
> that the tests fail without it even with launchctl limit tool set.
> 
> Gitlab-ci: needed the "launchctl limit maxfiles <value>" call,
> because under gitlib-ci it is needed the password to change the
> limits and we call the sudo tool which separates the local set
> of the environment.
> 
> Closes #4373

I've checked the patch into master.

--
Regards, Kirill Yukhin