Как передать команды в пользовательскую службу Linux с помощью bash / терминал - PullRequest
0 голосов
/ 28 сентября 2019

Цель: запустить собственный скрипт bash как службу в linux и разрешить мне передавать ему команды, как вы можете, большинству других служб через терминал / bash.

У меня уже установлен и протестирован скриптэто может делать то, что мне нужно, за исключением того, что я не могу понять, как можно передавать ему команды, как если бы это были другие службы.
Пример: nano открывает редактор nano для чтения указанного файла.Я хочу выполнить 'fan on', который вызовет новую службу 'fan' и выполнит команду 'on'.
Бонус: возможность сохранения переменных в файле конфигурации, который будет изменен позже.Но сейчас у меня есть переменные, установленные в верхней части скрипта, так что это не совсем необходимо.

Текущий файл модуля:

[Unit]
Description=Fan control Service                                                                                                                                                                         
[Service]
Type=simple
Restart=always
RestartSec=30
ExecStart=/home/pi/Documents/FanControl.sh
User=pi

[Install]
WantedBy=multi-user.target

Скрипт:

#!/bin/bash


#########################################################
#  User Settings
#GPIO Pin Number to use to control fan transistor.
fanpin=3
#Celsius temp to turn fan on/off
offtemp=55
ontemp=60
#Turn on the looping script automatically or not
autostart=TRUE
#Determine how often to scan temp and turn fan on/off if in auto
sleepinterval=10

#########################################################

#Misc Variables used in script - Leave these alone - Base Settings
MaxTemp=0
FanState=OFF
mode=MANUAL
auto=FALSE

#########################################################
#          Functions Described Below 
#########################################################

before-start() {
    # Check if gpio is already exported
    if [ ! -d /sys/class/gpio/gpio$fanpin ]
    then
      #Export the Pin
      echo $fanpin > /sys/class/gpio/export
      sleep 1 ;# Short delay while GPIO permissions are set up
      echo Fan Pin Exported Successfully.
      # Setup the pin as an output  
      sudo echo "out" > /sys/class/gpio/gpio$fanpin/direction
    fi
    }

#Function to turn fan on
on() {
        # Sets FanPin to high
        echo "1" > /sys/class/gpio/gpio$fanpin/value
        FanState=ON
        mode=Manual
        auto=FALSE
        echo Fan Turned on -- Mode set to Manual.
        echo
    }

#Function to turn fan off
off() {
        # Sets FanPin to low
        echo "0" > /sys/class/gpio/gpio$fanpin/value
        FanState=OFF
        mode=Manual
        auto=FALSE
        echo Fan Turned off -- Mode set to Manual.
        echo
    }   

#Function to set the variables to values
#Haven't actually tested this function yet
Set() {
    if $2 = "ontemp"
    then
        ontemp=$2
    else
        $2=$3
    fi
}

#########################################################
#    Begin Service Execution Code
#########################################################
#Don't know whow to write this section to keep it running as a service
#But it works well for testing purposes
before-start
    on
    sleep 3
    off
echo
read -p "Select an action": Q
$Q
echo
action="$1"
serviceName="Fan-Control Service"
echo Exiting Fan Service

Я могу использовать systemctl daemon-reload, и он может загрузить службу.Я могу использовать 'systemctl start fan', и сервис успешно запускается без ошибок.он также будет запускать вентилятор в течение нескольких секунд, поэтому я знаю, что он хорошо запускается.

Когда я пытаюсь использовать 'fan on' в качестве команды bash, я получаю "команда не найдена"
- как можноя получаю это как рабочую команду?
- какие изменения мне нужны в сценарии, чтобы он оставался в живых, чтобы потом иметь возможность передавать ему такие команды?

1 Ответ

0 голосов
/ 28 сентября 2019

Сервисам нетипично реагировать на интерактивные команды, отличные от команд управления сервисами, взятых из предопределенного набора.Если вы пытаетесь доказать эту концепцию, я бы предложил выбрать другое направление.

Но если вы должны это сделать, у вас есть жизнеспособные альтернативы:

  • длявключите / выключите, рассмотрите возможность установки обработчика сигнала в служебном скрипте, скажем, для SIGUSR1.Вы можете отправлять сигналы напрямую с помощью команды kill, но я бы порекомендовал вместо этого предоставить отдельный сценарий для этой цели.

  • для более сложных инструкций или для очень небольшого числа различныхинструкции, вам нужен какой-то канал связи.Сценарий потенциально может использовать FIFO или сокет для этой цели, и в этом случае я бы снова рекомендовал отдельный сценарий для отправки команд.Но это потребует, чтобы ваш сервис был существенно более сложным.

В любом случае, учтите, что, хотя существует давняя традиция обслуживания - контроль сценарии, сами реализации служб редко являются сценариями.Обычно они представляют собой скомпилированные программы, обычно написанные на C, поскольку это обеспечивает более прямой доступ к системе и более точный контроль, а также считается, что многие более безопасны (если это сделано грамотно).

...