Запуск пользовательского экземпляра systemd для пользователя из оболочки
Известные мне оболочки плохо справляются со структурными данными, поскольку у них нет вложенных структур данных. (Это включает Bash, который вы отметили. )Вам нужен список объектов или структур в стиле C -, но все, что у вас может быть, это массивы и ассоциативные массивы.
Один из способов сделать это — создать отдельные ассоциативные массивы для каждой части данных, которые у вас есть (забитые голы, пропущенные голы... )и пометить массивы названиями команд.
Так, например.
declare -A goals_scored goals_conceded
goals_scored[Liverpool]=4
goals_conceded[Liverpool]=2
goals_scored[Tottenham]=3
goals_conceded[Tottenham]=3
for team in "${!goals_scored[@]}"; do # iterate over the keys of goals_scored
echo "$team has scored ${goals_scored[$team]} goals"
done
Это несколько уродливо, так как элементы данных находятся на верхнем уровне, и если бы у вас также были структуры, например, для. игроков, они начнут путаться. (Например, goals_scoredможет относиться к команде или игроку, так что вам придется как-то их разделить.)
Вероятно, было бы лучше использовать правильный язык программирования.
См. Массивы/ассоциативные массивы в BashGuide для получения дополнительной информации об ассоциативных массивах.
Если вы хотите сделать системные вещи для другого пользователя, самое простое — войти в систему как этот пользователь, например, с помощью ssh user@localhost, но вот минимальная альтернатива настройки, позволяющая запустить bash для пользовательского фрагмента:
otheruser=testusr
id=$(id -u $otheruser)
sudo mkdir -p /run/user/$id
sudo chown $otheruser /run/user/$id
sudo systemctl start user@$id
sudo -u $otheruser \
DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/$id/bus \
systemd-run --user --scope /bin/bash
Согласно systemd devs:
"su" is a tool for changing user identities and very few other process credentials temporarily. It's not a tool for opening a completely new login session. A new login session has a very well defined, pristine setup, not inheriting anything from any other session, but this is really not the case for "su" uid changes: most of the execution environment is inherited over, in numerous and non-obvious ways, for example MAC contexts, audit contexts, cgroup contexts, namespace contexts, scheduling, timer granularity,
Вам нужно будет войти в систему как ваш пользователь через TTY, диспетчер отображения, machinectl loginили ssh, чтобы получить сеанс, достаточно чистый для запуска пользовательской шины systemd.
Если ни один из них не имеет смысла для вашего пользователя, то, возможно, ваш пользователь является системным пользователем (, не предназначенным для входа в систему ). В этом случае рассмотрите возможность использования User=в своей службе вместо того, чтобы пытаться запустить это на пользовательской шине.