A systemd fájljai, amivel alkot egy időzítőt..
:~# cat /etc/systemd/system/btrfs-scrub-sctrl.timer
[Unit]
Description=btrfs filesystes scrubbing
[Timer]
OnCalendar=Sat *-*-22..28 2:25:00
Unit=btrfs-scrub-sctrl.service
[Install]
WantedBy=timers.target
.. és egy szolgáltatást.
:~# cat /etc/systemd/system/btrfs-scrub-sctrl.service
[Unit]
Description=btrfs filesystes scrubbing
[Service]
Type=simple
ExecStart=/usr/local/sbin/btrfs-scrub-systemd.sh
StandardError=journal
Kell még hozzá egy script, ami gyakorlatban végrehajtja a fájlrendszere(ek) scrub-olását.
:~# cat /usr/local/sbin/btrfs-scrub-all.sh
#!/bin/bash -ex
#######################################################
# This is a helper script to be used in a systemd timer
# or cron job to scrub all mounted btrfs filessytems
#
# $Author: gbrks
# $Revision 0.1
# $Date: 2015.05.15
#
# modified to the king-crimson server
# 2018. 03. 20. - 2018. 03. 28.
# ap057r0ph3
[[ `id -u` -ne 0 ]] && exit 0
LOG_FILE="/var/log/btrfs-scrub.log"
TMP_FILE=`tempfile`
trap 'rm -f $TMP_FILE' EXIT
[ "`basename $0 .sh`" = 'btrfs-scrub-systemd' -o "`basename $0 .sh`" = 'btrfs-scrub-crond' ] && exec >> $LOG_FILE
echo "[`date`] btrfs scrub job started."
while read d m t x
do
[[ $t != "btrfs" ]] && continue
cat $TMP_FILE | grep -q $d && continue
echo $d >> $TMP_FILE
echo "[`date`] scrubbing \"$m\""
btrfs scrub start -Bd $m
done </proc/mounts
echo -e "[`date`] Scrub job ended.\n"
rm -f $TMP_FILE
exit 0;
nem kapcsolóval, hanem névvel operálok, mert megtehetem!
:~# ls -l /usr/local/sbin/btrfs-scrub-*
-rwxr-xr-x 1 root root 1570 márc 28 18:06 /usr/local/sbin/btrfs-scrub-all.sh
lrwxrwxrwx 1 root root 20 márc 21 07:24 /usr/local/sbin/btrfs-scrub-systemd.sh -> ./btrfs-scrub-all.sh
No és aktiválni kell, hogy műkodjon is az időzítő.
:~# systemctl enable btrfs-scrub-sctrl.timer
:~# systemctl start btrfs-scrub-sctrl.timer
ééééés!
:~# systemctl list-timers
NEXT LEFT LAST PASSED UNIT ACTIVATES
Wed 2018-03-28 23:05:20 CEST 4h 34min left Wed 2018-03-28 10:18:41 CEST 8h ago motd-news.timer motd-news.service
Thu 2018-03-29 04:14:45 CEST 9h left Wed 2018-03-28 10:04:11 CEST 8h ago apt-daily.timer apt-daily.service
Thu 2018-03-29 06:39:45 CEST 12h left Wed 2018-03-28 06:41:41 CEST 11h ago apt-daily-upgrade.timer apt-daily-upgrade.service
Thu 2018-03-29 07:54:41 CEST 13h left Wed 2018-03-28 07:54:41 CEST 10h ago systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.service
Mon 2018-04-02 05:47:28 CEST 4 days left Mon 2018-03-26 05:57:10 CEST 2 days ago snapd.refresh.timer snapd.refresh.service
Sat 2018-04-28 02:25:00 CEST 4 weeks 2 days left n/a n/a btrfs-scrub-sctrl.timer btrfs-scrub-sctrl.service
6 timers listed.
Pass --all to see loaded but inactive timers, too.
kivárom, hátha működik :))
- apostroph3 blogja
- A hozzászóláshoz be kell jelentkezni
- 1020 megtekintés
Hozzászólások
A crontab már a múlté? :)
- A hozzászóláshoz be kell jelentkezni
nem tudom miért, de ha a cronban megadok egy intervallumot egy dátumra, plusz a 'hétnapja'-t akkor minden 'hétnapja'-n végrehajtja, függetlenül a dátumtól.
ezt meguntam, elég egy hónapban egyszer felsikálni a padlót :)
- A hozzászóláshoz be kell jelentkezni
cron.monthly-ba betéve esetleg?
- A hozzászóláshoz be kell jelentkezni
azzal az a baj, hogy akkor fut le amikor eszébe jut, és nem a hónap harmadik szombatján hajnali 2 óra 25 perckor, amikor nekem jut eszembe:)
- A hozzászóláshoz be kell jelentkezni
Ez érthető. Erre magamnak egy ilyet írtam, esetleg te is leprogramozhatod saját módon, lehet hogy hasznosabb lenne:
https://hup.hu/node/156309?comments_per_page=9999
Vagyis csak akkor fut le, ha nem dolgozok a gépen, mindegy hogy a nap melyik szakában.
De nyilván a fenti megoldásod sem rossz, végülis rendesen integrálod a rendszerbe.
- A hozzászóláshoz be kell jelentkezni
> nem tudom miért,
azért, mert nem olvastad a man crontab -ot. Ez a definíció szerinti viselkedés, rendes oktatáson (pl. amit én tartottam) ezt el is illik mondani, hogy mondjuk a "minden péntek, 13-a" jellegű viccekkel nagyokat lehet szívni ;-) (Persze az is lehet, hogy azért nem tudod, mert rossz oprendszer crontabját olvastad el, rendesebbekben ez le van írva)
=====
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?
- A hozzászóláshoz be kell jelentkezni
nagyon vicces, de nem csak en nem olvastam el, hanem pl. a zfs v. openzfs? karbantartói sem.
# cat /etc/cron.d/zfsutils-linux
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
# Scrub the second Sunday of every month.
# áthelyezve systemd-be
# systemctl status zfsutils-linux-scrub.timer
# 0 20 8-14 * 0 root [ -x /usr/lib/zfs-linux/scrub ] && /usr/lib/zfs-linux/scrub
de lehet hogy ők is rossz man olvastak:)
- A hozzászóláshoz be kell jelentkezni
És biztos, hogy az a szerencsétlen zfs scrub csak minden második vasárnap fog futni?
Amúgy itt az idézet (ez pl. a Vixie-cron doksijából):
Note: The day of a command's execution can be specified by two fields — day of month, and day of week. If both fields are restricted (ie, are not *), the command will be run when either field matches the current time. For example, ``30 4 1,15 * 5'' would cause a command to be run at 4:30 am on the 1st and 15th of each month, plus every Friday.
=====
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?
- A hozzászóláshoz be kell jelentkezni
nem. és pont ezért tettem át systemdbe, mert minden vasárnap lefutott, és nagyon zavaró volt.
- A hozzászóláshoz be kell jelentkezni
Ja, még egy idézet, ezúttal az opengroups-tól (mondjuk úgy, hogy a POSIX szabványból):
"Finally, if either the month or day of month is specified as an element or list, and the day of week is also specified as an element or list, then any day matching either the month and day of month, or the day of week, shall be matched."
Szóval kérdésedre a válasz: ez az elvárt viselkedés, az is igaz, hogy a jó édes .... annak, aki ezt annó így programozta le (aminek hatására aztán ez került a szabványba).
=====
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?
- A hozzászóláshoz be kell jelentkezni
Ja, hogy a felvetésre is reagáljak, ne csak manokat cut'n'paste-oljak: Mivel az esetek 99%-ban a cronból az ember így is úgy is egy shell-scriptet hív, én anno azt javasoltam, hogy fenti problémát úgy kell megoldani, hogy teszem azt fenti mind hó második vasárnapját felvesszük a crontab-ba minden vasárnapi lefutásra, majd pedig a scriptet azzal kezdjük, hogy leteszteljük, hogy jó-e nekünk az időpont, és ha nem, kilépünk azonnal. Pl. így:
d=`date +%d`
[ $d -ge 8 -a $d -le 14 ] || exit 126
Ezzel kissé fölöslegesen terheljük ugyan a gépet (ugye 3, 4 vasárnapon is el fog indulni a scriptünk fölöslegesen), de nem kell várni a systemd megalkotására.
=====
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?
- A hozzászóláshoz be kell jelentkezni
eredetileg én is erre gondoltam, de nem akartam belenyúlni a zfsutils scriptjébe.
- mert azon a gépen kezdtem el agyalni mi legyen, amelyiken zfs van -
aztán meg már a systemd-s magoldásnál maradtam más gépeken is, hogy egységes legyen, és ne keveredjek el.
- A hozzászóláshoz be kell jelentkezni
késő bánat ugyan, de most jutott eszembe a beszélgetésünk okán:
/etc/cron.d/zfsutils-linux :
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
# Scrub the second Sunday of every month.
# áthelyezve systemd-be
# systemctl status zfsutils-linux-scrub.timer
# 0 20 8-14 * 0 root [ -x /usr/lib/zfs-linux/scrub ] && /usr/lib/zfs-linux/scrub
0 20 * * 0 root [ -x /usr/lib/zfs-linux/scrub -a "`date +%d`" -ge 8 -a "`date +%d`" -le 14 ] && /usr/lib/zfs-linux/scrub
nem kell módosítani a scriptet, ha felül is íródik a 'gyári' script upgradenél nem okoz galibát, a /etc-ben lévő cron bejegyzés felülírására rákérdez a apt...
és valószínűleg működik is.
viszont baromi ronda:)
- A hozzászóláshoz be kell jelentkezni
Esetleg valami ilyesmi (Minden hó első vasárnapján)?
0 20 * * 0 test $(echo $((($(date +%d)-1)/7+1))) = 1 && /usr/lib/zfs-linux/scrub
Picivel szebb talán..
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..
- A hozzászóláshoz be kell jelentkezni
Mind a kettőtöknek szólok, hogy mielőtt ezeket a módszereket élesben akarnátok használni, erősen javasolt a fent már emlegetett man 5 crontab, ugyanis van még egy nagyon jól ismert anyázós szintaktikai csemegéje: a parancsban szereplő (nem takart) % karaktert ENTER-re cseréli a következő módon:
a % b % c % d ->
a - ez lesz a lefuttatandó parancs
b
c
d
ez pedig az STDIN-en soronként kapott bemenete. Azaz fenti sor ennek a parancssori konstrukciónak felel meg:
a << E_O_F
b
c
d
E_O_F
Ezt persze egyszerű \% -kal szépen ki lehet küszöbölni, de minimum tudni kell róla.
=====
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?
- A hozzászóláshoz be kell jelentkezni
"Az a jó a systemd-ben, hogy végre megszabadulunk a sok kis szarul megírt, hordozhatatlan shell-scripttől."
Oszt gyakorlatilag ha nincs egy bináris ami pont azt akarja, mint te, no akkor ír az ember magának a szarul megírt shell-script helyett egy szarul megírt shell-scriptet, meg mellé még egy fantasztikusan hordozható service, meg unit, meg timer, meg anyámkínja fájlt is.
(Bocs, nem téged támadlak.)
=====
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?
- A hozzászóláshoz be kell jelentkezni
Ez egy big +1. Pont ugyanezt a tendenciát tapasztalom, a systemd unit-ok tartalma valahogy szeret konvergálni a
ExecStart=/opt/foobar/bin/megiscsak-scriptbol-kell-megoldani.sh
tipusú séma felé.
---
Régóta vágyok én, az androidok mezonkincsére már!
- A hozzászóláshoz be kell jelentkezni
Mert a script + crontab csak egy fájllal kevesebb...
Egyébként szvsz. annyi értelme mindenképp van, hogy garantált környezetet kapsz a futtatott scriptben, függetlenül attól, hogy service-ként indítod [vö. random pistike shellből hívja random init scriptet a saját nevében], socket miatt indul vagy timer miatt indul (vs. inet.d/cron), ugyanannak a usernek a nevében fog futni, ugyanazok a fájlrendszer, hálózat stb. hozzáférési szabályok lesznek életben, stb.
BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)
- A hozzászóláshoz be kell jelentkezni
Ezzel a felével nincs bajom (pont nem is erről beszéltem e miatt), de erre sem biztos, hogy a systemd operációs rendszer létrehozása volt a legjobb megoldás. Ezt speciel meg lehetett volna oldani azzal, hogy az init scriptek végeznek némi önellenőrzést, és ha nem a service parancson keresztül vannak hívva, akkor szépen hibát adnak. A service parancs pedig nyugodtan meg lehetne írva úgy, hogy nem "sh /etc/init.d/service start" -ot mond, hanem "cd / && env -i sh /etc/init.d/service start" - nyilván egy csomó egyéb mellett, ami már eddig is benne volt. De persze ez is csak egy hekk, ami szálkátlan ugyan, de mennyivel jobb egy teljes ökoszisztémát létrehozni, és bekebelezni minden addig már úgy-ahogy kiforrott technikát, és évtizedekre beleveszni a "ma-épp-milyen-faszságot-programozzunk-bele-a-rendszer-legkényesebb-ámde-apró(nak-kéne-lennie)-komponensébe-lehetőleg-hibásan-de-mindenképpen-ellentétesen-a-józan-ésszel".
Tudod, a soxor emlegetett KISS elv. Már az init és az inetd összegyógyítása (socket activation) sem biztos, hogy jó irány volt, node a többi ... (Mindegy, ez a flame már ezerszer meg lett rágva itt is, máshol is)
=====
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?
- A hozzászóláshoz be kell jelentkezni
+1
- A hozzászóláshoz be kell jelentkezni