Vamp

Нужно монтировать /usr/share/elasticsearch/data

volumes:
      - /home/user/green:/usr/share/elasticsearch/data

Существует возможность заменить процесс sh процессом java при помощи команды exec:
sh -c "exec java -jar ol.jar"

В этом случае дочерний процесс займёт место родителя. В частности, получит PID bash процесса, который вам уже известен. Разумеется, если в скрипте после вызова java идут какие-то ещё команды, то они никогда не выполнятся, так как процесс bash перестаёт существовать в момент вызова exec.

Если всё же необходимо выполнить какие-нибудь завершающие команды по окончании работы java процесса, то существует возможность повесить собственные обработчики сигналов:

#!/bin/sh

# Устанавливаем обработчик сигналов HUP INT QUIT TERM и псевдосигнала EXIT.
# В обработчике отправляем сигнал TERM процессу, чей pid будет записан в
# переменной CHILDPID.
trap 'kill $CHILDPID' HUP INT QUIT TERM EXIT

# Запускаем java в фоне.
java -jar ol.jar &

# Сохраняем PID только что запущенного дочернего java процесса.
CHILDPID=$!

# Следующая команда ставит процесс sh на паузу.
# Пауза снимется после завершения фонового java процесса.
# Обработчик сигналов при этом остаётся работоспособным и будет
# корректно отрабатывать во время паузы.
wait

# В этом месте java уже завершилась и можно что-нибудь сделать.
# Например, подчистить временные файлы.
echo Cleanup actions

Как правило, трудностей не возникает. Но всё зависит от того, насколько сильно дистрибутив отличается от своей базы. Ubuntu, например, хоть и основан на Debian, но так сильно от него отличается, что искать решение проблем убунту в дебиановских доках практически бесполезно. Но Mint, основанный на Ubuntu, отличается незначительно, поэтому проблемы минта в доках убунты решаются без проблем.

Хорошо работает подход при гуглении - добавлять название дистрибутива к поисковому запросу и если нет успеха, то добавить название базового дистрибутива.

1. "[описание проблемы] kali"
2. "[описание проблемы] debian"
3. "[описание проблемы]" (если предыдущие два варианта облажались, гугление безотносительно дистрибутива - единственный оставшийся вариант)

upload_tmp_dir нужно указывать в пределах open_basedir, иначе скрипты сайта не смогут получить доступ к загружаемым файлам. Аналогично нужно настроить ещё session.save_path и sys_temp_dir, иначе не будут работать сессии и функции для работы с временными файлами.

Смысл появляется когда у вас больше одного сайта на сервере. В этом случае open_basedir используется для изоляции сайтов друг от друга - чтобы взлом одного сайта не привёл ко взлому всех остальных сайтов на сервере.

Пару лет назад я описывал рабочую схему для усиления безопасности в другом вопросе на тостере. Взгляните.

В вашем случае решения чисто на java нет. Здесь необходимо зарядить регулярную задачу (cron), которая будет смотреть свободную физическую память в системе и убивать самое толстое java приложение при достижении 95% лимита памяти. Например, так:

#!/usr/bin/env bash

# pid'ы отслеживаемых java процессов
# задачку определения актуальных pid'ов оставлю на вас
PID1=1234
PID2=5678

# минимальное допустимое количество свободной памяти в процентах
MIN_MEM_SIZE=5

function get_java_mem {
  jstat -gc $1 | awk 'NR==1 {print ($3 + $4 + $6 + $8 + $10)}'
}

function get_free_mem {
  free | awk 'NR==2 {print ($7 * 100) / $2}'
}

if [ $(echo "`get_free_mem` < $MIN_MEM_SIZE" | bc) -eq "1" ]; then
  if [ $(echo "`get_java_mem $PID1` > `get_java_mem $PID2`" | bc) -eq "1" ]; then
    PID_TO_KILL=$PID1;
  else
    PID_TO_KILL=$PID2
  fi
  echo "Memory shortage detected. Taking heap dump and killing process $PID_TO_KILL"
  jmap  -dump:format=b,file=${PID_TO_KILL}.heapdump.bin $PID_TO_KILL
  kill $PID_TO_KILL
fi

если я пропишу -Xmx2g то оба влезут, но если один процесс использует все 2 гб, то второй не может эту память использовать.

Не очень ясно зачем нужны такие качели. Если приложение нормально работает с -Xmx2g, то с -Xmx4g сильно лучше не станет. Разве что full gc будет происходить немного чаще, только и всего.