Dotaz: skript po startu pod sudo

[teevee70]

Dobré dopoledne , nějak se mi nedaří rozchodit skript na kontrolu zapnutí ventilátoru dle teploty tak, aby se spustil při event startu nebo restartu počítače . Skript samotný spouštěný z terminálu funguje dobře , ale pokud to zkusím cronem nebo rc.local , neproběhne požadované nastavení teploty . Kam ho dát, aby se spustil ?

díky za event pomoc

echo 50000 | sudo tee /sys/devices/virtual/thermal/thermal_zone0/trip_point_4_temp

---

---

Odpovědi

[pet I.]

Pokud to cheš spustit v rc.local, tak tam dej

echo 50000 > /sys/devices/virtual/thermal/thermal_zone0/trip_point_4_temp

rc.local při startu běží pod rootem.

[teevee70]

díky , ale bohužel se hodnota teploty takto spouštěným skriptem nezmění . Skript tedy neproběhne. Armbian 64 HW Odroid N2+

[Filip Jirsák]

V té odpovědi to nebylo explicitně napsané, ale začněte tím, že odstraníte to nesmyslné sudo. Ten skript už pod rootem běží, sudo ničemu nepomůže, akorát to může rozbít.

[billgates]

Pozri do sudoers, ci tam nemas nieco v zmysle:

Defaults   !visiblepw

Potom to odmietne bezat, ak to nema terminal. Cize ak mas, tak zakomentuj.

[billgates]

Resp. odstran vykricnik.

[teevee70]

Díky za ochotu. Nic takového v sudoers nemám. Stejně mi skript nejde i přes sudo crontab -e Z terminálu spouštěný jede OK . Jsem z toho jelen.

[billgates]

Skus pridat:

Defaults visiblepw

[Filip Jirsák]

Raději ty nesmyslné změny v sudoers zase vraťte do původního stavu. Ve skriptu, který běží pod rootem, je nesmysl spouštět sudo.

[billgates]

Nie je tam explicitne napisane, ze z cronu to spusta pod rootom.

[Filip Jirsák]

Je tam napsané, že se to spouští z rc.local. Pokud by se to z nějakého záhadného důvodu pokoušel spouštět z cronu jiného uživatele, je nejjednodušší řešení přesunout to do systémového cronu. A upřímně řečeno, nemyslím si, že by tazatel věděl, že existuje uživatelský cron…

[teevee70]

skript v cronu @reboot echo 50000 > /sys/devices/virtual/thermal/thermal_zone0/trip_point_4_temp

nejede ani v uživatelském cronus crontab -e ani v SU cronu sudo crontab -e

[Filip Jirsák]

V cronu musíte uvádět absolutní cestu k příkazu, málokdy je tam nějak rozumně nastavená proměnná PATH. Lepší je dát do cronu (absolutní) cestu k nějakému skriptu a teprve v tom skriptu mít výkonný kód.

[pavele]

Po zkušenostech s cronem jsem vždy do cronu dal jen odkaz na bash skript, který spouští.

Taky dávám jeden prázdný řádek na konec crontabu - někdy se mi stávalo, že bez prázdného řádku na konci se to nespustilo.

Podle distribuce jsou v cronu různě omezené proměnné $PATH (shell je většinou /bin/sh).

Dá se to dobře odladit - můžu třeba root cron spouštět každou minutu a ve skriptu mít:

echo "jede" >>/root/jedetest.txt

Takže příklad pro sudo crontab -e:

* * * * * /root/mujskript.sh

Spustitelný skript /root/mujskript.sh:

#!/bin/bash

echo "jede" >>/root/jede.txt

[Jendа]

Tipuju, že není aktivovaná systemd služba, která spouští rc.local -- mám pocit, že třeba na CentOSu to defaultně není a musíš si ji napsat. Pro představu takto vypadá v Debianu:

# /lib/systemd/system/rc-local.service
#  SPDX-License-Identifier: LGPL-2.1-or-later
#
#  This file is part of systemd.
#
#  systemd is free software; you can redistribute it and/or modify it
#  under the terms of the GNU Lesser General Public License as published by
#  the Free Software Foundation; either version 2.1 of the License, or
#  (at your option) any later version.

# This unit gets pulled automatically into multi-user.target by
# systemd-rc-local-generator if /etc/rc.local is executable.
[Unit]
Description=/etc/rc.local Compatibility
Documentation=man:systemd-rc-local-generator(8)
ConditionFileIsExecutable=/etc/rc.local
After=network.target

[Service]
Type=forking
ExecStart=/etc/rc.local start
TimeoutSec=0
RemainAfterExit=yes
GuessMainPID=no

# /lib/systemd/system/rc-local.service.d/debian.conf
[Unit]
# not specified by LSB, but has been behaving that way in Debian under SysV
# init and upstart
After=network-online.target

# Often contains status messages which users expect to see on the console
# during boot
[Service]
StandardOutput=journal+console
StandardError=journal+console

Nejdřív bych udělal systemctl status rc<TAB><TAB> (musíš mít nainstalovaný bash-completion balíček) abys zjistil jestli už neexistuje. Pokud ne, tak ji vytvoř /etc/systemd/system/rc-local.service, systemctl enable rc-local.service, a po restartu systemctl status rc-local.service. Taky si v tom skriptu třeba vytvoř touch /tmp/foo ať víš že se to spustilo.

Když ti to nefunguje v cronu, tak to bude buď v syslogu, nebo ti to pošle email - musíš mít v systému funkční maily, což já dělám většinou pomocí ssmtp.

[Filip Jirsák]

Lepší řešení je vytvořit si oneshot service. Je to přehlednější než rc.local, uvidí, jestli ta konkrétní věc selhala a uvidí k ní výstup z logů ve statusu.

rc.local, @reboot apod. ptákoviny už prosím ne.

[BFU]

Tohle by bylo lepsi resit pres udev, treba napsat /etc/udev/rules.d/99-thermal.rules s obsahem neco jako:

ACTION=="add", KERNEL=="thermal_zone0", SUBSYSTEM=="thermal", ATTR{trip_point_4_temp}="50000"

[billgates]

Na CentOS je taka sluzba a je aj spustena, ale trik je v tom, ze rc.local nema defaultne executable bity nastavene a sluzba subor nevykona, kym pouzivatel umyselne nenastavi tomuto suboru +x. Je to okrem ineho priamo v nom aj napisane ako komentar.

# THIS FILE IS ADDED FOR COMPATIBILITY PURPOSES
#
# It is highly advisable to create own systemd services or udev rules
# to run scripts during boot instead of using this file.
#
# In contrast to previous versions due to parallel execution during boot
# this script will NOT be run after all other services.
#
# Please note that you must run 'chmod +x /etc/rc.d/rc.local' to ensure
# that this script will be executed during boot.