btrfs-scrub időről időre

Had menjen inkább systemd-ből, mithogy kézzel keljen állandóan futtatni.

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.

> 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?

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:)

É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?

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?

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?

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:)

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!"..

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?

( Zahy v | 2018. 03. 28., sze – 21:03 )

"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?

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)

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?