Ez talán segít. [link] Sajnos én már elfelejtettem hogy van a syntax. Ha csak lehet inkább megírom valamelyik programnyelven a kódot. A kapcsos zárójelre írja, hogy talán ki kéne venni.

[ Szerkesztve ]

Buliban hasznos! =]

a fordított aposztróf elvileg futtatja a parancsot.
tehát a vsftpd változóba a státusz kimenete kerül, nem pedig a parancs, amivel lekéred a státuszt.
ezért az ifben az echo után a szintén fordított aposztróf nem a státusz lekérésére szolgáló parancsot fogja futtatni, hanem a státusz eredményét akarja parancsként végrehajtani, ami eléggé kétesélyes

szerintem azt kellene, hogy (egyrészt van rá szaktopic ) a vsftpd változóba a státusz eredményét rakod, valahogy így:

vsftpd=$( service vsftpd status| grep -q -i pid)
if [ $vsftpd -eq 0 ]; then

de ez sem lesz jó, mert nem szám lesz benne, hanem string.
a legegyszerűbb:

service vsftpd status | grep -q -i pid || service vsftpd start

Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

Jó lehet az első megoldás is. Jelen állapotában annyi, hogy az exit status-t kell vizsgálni (persze ekkor felesleges a vsftpd változóban letárolni az egyébként is üres kimenetet):

service vsftpd status| grep -q -i pid
if [ $? -eq 0 ]; then

Vagy nem quiet-be grep-elünk és a visszaadott sorok számát számoljuk:

vsftpd=$( service vsftpd status| grep -i pid | wc -l)

[ Szerkesztve ]

Alex

Több baj is van itt. Eleve változónév naming convention alapján legyen mondjuk végig nagybetűs.
Aztán: vsftpd-be beleteszed a status outputot, majd ezt az outputot akarod elindítani (mert felüldefiniáltad), ha nem fut a cucc.

[ Szerkesztve ]

https://www.coreinfinity.tech

Miért indítaná az outputot? Nem $vsftpd-vel hivatkozik rá...

Alex

Rendben, azt eltévesztettem, de attól még felüldefiniálta, ezért kap syntax errort.

https://www.coreinfinity.tech

Úgy nézem, hogy mindenképpen helyben kell futtatnom a fejlesztő környezetet a PI-n, ha hozzá szeretnék férni pl. a GPIO portokhoz.

Azt most megcsináltam, hogy fut az Eclipse-CDT a raspberry-n. Kíváncsiságból ssh -X -el elindítottam az Eclipse-t ami át is jött hozzám az asztali gépemre, de ebben a formájában használhatatlanul lassú. (kisebb progikkal tök jól ment ez)

Mit lenne célszerű használni ami erre való? Egyik lehetőség gondolom a TeamViewer használata és teljes távoli asztal...

Nincs más - csak egy szál gitár - szidom a rendszert - forradalmár. - Én vagyok egyedül 88 telén. (Auróra)

Mit definiált felül? A vsftpd az egy lokális shell változó lesz. Ha hivatkozni akarna a változóra, akkor egy $ kell elé, azaz $vsftpd.

Pl.:

[gavarga@gavarga-5500 temp]$ ls=$(echo akarmi)
[gavarga@gavarga-5500 temp]$ ls
taj.lua
[gavarga@gavarga-5500 temp]$ $ls
bash: akarmi: parancs nem található

Láthatod, hogy attól, hogy van egy ls nevű változóm, az ls parancs továbbra is működik.

Bambano leírta, hogy mi okozza a hibát.

[ Szerkesztve ]

Alex

de, dollárral hivatkozik rá.
ez van az eredeti hsz-ben:
if [ echo `"$vsftpd" | grep -q "pid"` -eq 0 ];

az idézőjelen belül kifejti a $vsftpd-t, ami az előző futtatás eredményét tartalmazza, majd mivel fordított aposztrófok között van, ezért azt forkolja és egy subshellben elindítja a csővezetékkel, greppel egyetemben.
azért kap syntax errort, mert a parancsok kimenete rendszerint nem futtatható.

Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

próbáljunk már unixosan gondolkodni, mert ez kupleráj

két dolog miatt lassú:
1. az eclipse nagy. tehát lehet, hogy akkor is lassú lenne, ha közvetlen képernyőt dugnál a pi-re. egyébként miért is nem dugsz képernyőt a pi-re?
2. az ssh titkosít. ezért minden rajta átküldött adat lassabban megy át és összeszed egy rakás késleltetést, ami interaktív desktopon idegesítő tud lenni.
3. a teamviewer ezen a két tételen tovább tud rontani, várhatóan elég sokat

tehát ha nem elektromos csellentyűcskékben gondolkodunk, hanem meg akarjuk oldani a problémát, akkor az eredeti unixos megoldást kell használni: az X kliens-szerver alapú.

- elindítasz egy terminált a pc-den, beleírod, hogy xhost +
- miközben kifejezetten nagy erőkkel odafigyelsz arra, hogy az ssh parancssori paraméterei között NE szerepeljen a -X.
- ssh-val bemész a pi-re, ott beírod, hogy:
export DISPLAY=desktoppcipcime:0
- ezután elindítod az eclipse-t.

ekkor gyorsabb lesz. hogy ez neked elég gyors-e, az szubjektív kérdéskör. miután a pi-n gyakorlatilag nincsenek perifériák (arra célzok, hogy az ethernet is usb-n lóg), ezért ott lehet, hogy ez is lassú lesz, majd eldöntöd.

azt ne zárjuk ki, hogy agyhalott csomagolók gyári állapotában letiltották a pc-n a hálózati X-et, ilyenkor meg kell keresned azt a parancsfájlt, ami az X-et indítja, megnézni, hogy van-e -notcp kapcsoló és azt ki kell gyalulni.

az biztos, hogy rendes gigás ethernettel rendelkező rendes számítógépek között az X minimum elfogadhatóan, de inkább jól működik. 10 gigás neten pedig semmi különbség nincs a lokális és a távoli programok között. én mindkettőt használom.

Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

Jah kupleráj, de ez nekem mind totál új terület.

Most éppen rájöttem, hogy totál hiába kínlódtam eddig az Eclipse-el. Az csak 64 biten létezik, a PI-re ugyan létezik 64-bites oprendszer is amire fel is települ, viszont a GPIO portok buzerálásához kellő wiringPi nem működik 64 biten, meg amúgy is egy kínlódás volt olyan toolchaint találnom, ami 64 bites arm-en le is tudott fordítani valamit...

Szóval per pillanat visszaálltam az eredeti raspberry OS-re, és ott Geany alatt elkezdtem dolgozni, szépen megy a GPIO kezelés, még a végén az egész projektet az alatt csinálom meg...

Most még meg tudom csinálni, hogy teszek monitort meg perifériákat a PI-re, viszont a fejlesztés későbbi szakaszában már be lesz építve a termékbe ahol nem fogok hozzáférni a hdmi-hez, de debuggolni már ott kell majd helyben.

Egyébként a Geany egész jó sebességgel használható ssh -X -en keresztül, és még az általa futtatott program is átjött hozzám. Viszont majd megpróbálom megvalósítani amit írtál.

Nincs más - csak egy szál gitár - szidom a rendszert - forradalmár. - Én vagyok egyedül 88 telén. (Auróra)

De a kolléga azt írta, hogy: "vsftpd-be beleteszed a status outputot, majd ezt az outputot akarod elindítani (mert felüldefiniáltad), ha nem fut a cucc"

majd

"Rendben, azt eltévesztettem, de attól még felüldefiniálta, ezért kap syntax errort."

Nem definiál felül semmit. Én erre reagáltam. Az egy másik probléma, amit te írsz. Arra írtam, hogy megírtad, mi a probléma...

Alex

Először is köszönöm a válaszotokat!

Igazából, csak általánosan gondolkodva ezt akartam volna megvalósítani:

vsftpd= service vsftpd status #ennek a kimenete egy sor amiben van 'pid' szó
if -ben, kiíratom a vsftpd változó értékét echoval és átadom a grepnek, hogy a -q miatt logikai értéket adjon vissza, amit hasonlíthatok az -eq-val. Ami 0-val tér vissza, ha a pid szerepel a vsftpd string sorban.
Sajnos systemctl nem használható, mert RedHat 6.8 a szerver.

De az if-ben elrontom a színtaktikát. Sajnos nem vagyok bash guru, az echo elé téve a fordított aposztrófot sem megy.

Ha lehetne zárójelezni mint C-ben jobban átlátható lenne. Mert a fordított aposztróffal egy zárójelet akartam felyettesíteni, hogy annak a két parancsnak a kimenetét hasonsítsa az -eq.

vsftpd=`service vsftpd status`
if [ `echo "$vsftpd" | grep -q "pid"` -eq 0 ];
then
        echo "a service fut"
else 
        service vsftpd start
fi

[ Szerkesztve ]

először is megígéred, hogy legközelebb a helyes topicba írsz: [link]
másodszor azért lehet gondod a fordított aposztróffal, mert egyáltalán nincs szükséged rá. nem azért nem megy, mert az echo elé vagy mögé tetted, hanem azért, mert tetted.
harmadszor lehet zárójelezni, sőt, erősen javasolt is, mert a fordított aposztróf idejétmúlt, de nincs rá szükséged. a processzbehelyettesítés régi módszere a fordított aposztróf volt, az új pedig a $( )

Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

Azon kívül, amit a többiek írtak, én megjegyezném, hogy a scripted egy másik oldalról is sántít. Cselesen eltitkoltad, hogy milyen disztró, de pl. a legtöbb disztró systemd-s, és ott kiadod ezt a service parancsot, és képen vág egy service: command not found sorral, hogy a fal adja a másikat.

Látszik, hogy valahonnan összeollóztad a scriptet, kicsit bele is hegesztettél saját kútfőből, és az egész több sebből vérzik. Ez azért is veszélyes, mert ha még le is fut, ha nem jól van megírva, akkor más környezetben vagy egy újratelepített rendszeren nem fogod érteni, hogy miért nem működik.

Nem, ezt én írtam, de hát olyan faék egyszerű..
Az if-ben levő részét napi szinten kiadom, dolgozom vele. Így csak ki akartam bővíteni egy if-el, ha scriptben fut...

Srácok, van egy saját írású mono service-em aminek ugyan vannak még gyermekbetegségei, de mostanság egy forrás REST API időnkénti elérhetetlensége miatt failure után leáll. A hibát le fogom kezelni, de alapvetően a service úgy van beállítva, hogy failure esetén restartoljon:

Restart=on-failure
RestartSec=30

Mivel a fenti, leállással járó hiba ritkán fordul elő, és ha a service újraindul, legközelebb már jól végzi dolgát. HA újraindulna... és itt van a probléma. A lock file létezése miatt a syslog tele van entryvel, hogy nem tud elindulni.
Ha kiszedem a lock file-t, és failure-re fut a program, simán restartol 30 másodperc múlva és megy minden a maga rendjén. Mivel "szerveren" fut a program, sajnos nem opció, hogy amikor a monitoring alertál arról, hogy leállt a service, kézzel újraindítom, hisz lehet hogy épp alszom. Jó lenne, ha maga indulna újra. Az a baj, hogy ez a probléma (a lock file miatti sikertelen újraindítás) sokkal nagyobb gond, mint az ezt kiváltó program exception.

Hogy vehetném rá a service-t, hogy failure restart esetén nyugodtan írja felül a lock file-t?

ExecStartPre=-/usr/bin/rm /var/valami/lockfile

Eeezz az, köszönöm
Service restartnál ki is írja hogy az rm lefutott 0/Success kóddal (jó, persze most nem volt feladata, de ha ez ugyanígy megy a program failure esetén is, az király lesz)

[ Szerkesztve ]

Sziasztok.

Kis segítséget szeretnék kérni.

Van a két RAID kártyám. Nem hardveres, hanem az olcsóbbik cpu-t dolgoztató fajta. Az egyik valami SIL3xxx, a másik JMB366. Bármelyikkel csinálok egy RAID0 (128k) tömböt 2db HDD-ből, linux-on belül a GParted külön-külön hdd-nak jelzi és nem jelzi a logikai tömböt.

Direkt kártyával szeretném megcsinálni és nem mdadm-el, hogy Win alatt is tudjam olvasni majd a tömböt.

Mi az oka, hogy nem látom egyben a dupla hdd méretű tömböt?

"Mi az oka, hogy nem látom egyben a dupla hdd méretű tömböt?": "Nem hardveres, hanem az olcsóbbik cpu-t dolgoztató fajta."

Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

Nade ettől még kellene látnom, nem? Különben mi értelme volna?

Ehh, meggyőztem magam, hogy nem bohóckodom ezekkel a kártyákkal. Ha már a cpu-t használja legyen mdadm. Ha fejreáll netán a rendszer akkor usb-s live linux-al akkor is elérhető marad a tartalom.

Ha van lehetőséget a R-Pi-re rakni gcc-t és gdbservert meg ami mind kell ahhoz hogy tudj fordítani az SSH-án keresztül akár a beágyas Linuxon, akkor én azt javaslom próbálkozz inkább a Visual Studio 2019-ben lévő remote debug-val. Annak a gdbserver-es verziója a jelenlegi legjobb szerintem.

Röviden tömören, amikor buildelsz az SSH-án keresztül feltölti a forrásfájlokat, és az R-Pi-ben lévő gcc-vel fordít mindent, és ez a legjobb, így nem megy félre semmi. Aztán amikor debugban futtatod, akkor SSH-án a buildet cuccot elindítja úgy, hogy a gdbserver is megy közben a Linuxon, és azon keresztül tudsz a VS 2019-ben a saját PC-den breakpointozni, meg mindent amit akarsz, úgy hogy valójában a progi az ARM-en fut. Abban is okos a VS2019, hogy a remote Linux fordítójának és rendszereiben elérhető headerjeiről is csinál egy cahcelt állapotot, és 100%-osan tud működni az IntelliSense a Linuxban lévő includok alapján.

Amúgy ez létezik az Eclipsben is, de kb fél évig tarthat a bekonfigolása, meg én is azt vettem észre, hogy alig van normális blog bejegyzés vagy valami tutorial hozzá, ami gond nélkül ugyan ezt összerakná.

Gigabyte GA-Z170-D3H, Intel Core i7-7700K, Corsair Vengeance 2x8GB DDR4-3600MHz, Intel 545s 256GB SSD, EVGA GeForce GTX 1060 GAMING 6GB

Amúgy a jelenlegi "state of the art" az lenne, ha a már meglévő C vagy C++ libjeiteket beraknátok egy igazi C/C++-os Python modulba, tehát egy olyan .so-ba amit a python betud importálni, és abból az ehhez megcsinált osztályokkal egy sima python scriptben tudnátok a top level szintű működést megvalósítani.

Én kb fél éve ezt megcsináltam, egy ugyan ilyen ARM-es Linux alá, és a világ legkorszerűbben és leggyorsabban fejleszthető cucca lett az eredmény ebből.

Amúgy az Eclipse valamilyen tcf-agent cuccal tudja ugyan azt a gdbserveres debugolást mint a VS2019 vagy a VS Code.

[ Szerkesztve ]

Gigabyte GA-Z170-D3H, Intel Core i7-7700K, Corsair Vengeance 2x8GB DDR4-3600MHz, Intel 545s 256GB SSD, EVGA GeForce GTX 1060 GAMING 6GB

a kifejezés, amit kerestél: remote debuggal.
egyébként ez egy jó példa arra, hogy a unix filozófiát nem ismerők hogyan kókányolnak keresztül-kasul, hogy elérjenek valami eredményt, ahelyett, hogy megcsinálnák normálisan.

minek másolgatnál mindent jobbra-balra? ha nem felel meg a verziókezelő repója erre (de, megfelel), akkor is feltalálták az nfs-t.

Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

Minden ssh-n küldi ezeket Abból az egyszerű okból, hogy ssh szerver kell a gdbhez is szóval az alapból van, tök felesleges lenne még egy protocol.

Fájlátvitelre a Visual Studio és az ingyenes Visual Code is igazából az rsync-et használja, tehát amikor buildelsz, akkor a PC-én lévő project mappádat az ARM-es Linuxra beszinkonrizálja és kész. Utána lescriptelt módon belép az SSH-án ott a gcc-vel fordít egyet és a gdbserverrel együtt elindítja a debugolandó progidat. Innentől kezdve már nincs SSH, a gdbserver saját protokolja szerint megy a debug, aminél nincs hatékonyabb jelenleg.

Ebben a módszerben, amit az MS megcsinált szerintem sehol semmi kókányolás nincs, maximálisan követ egy unix filozófiát, és a usernek minimalizálja az extra konfigurálási kényszert, tehát nem kell hozzánemértő módon NFS megosztással bajlódni, ami mindenképp külön telepítgetéseket követel és hozzáértő beállítást, az nem lenne user friendly és nem eladható széleskörben.

Gigabyte GA-Z170-D3H, Intel Core i7-7700K, Corsair Vengeance 2x8GB DDR4-3600MHz, Intel 545s 256GB SSD, EVGA GeForce GTX 1060 GAMING 6GB

Köszi, ez is beáll mint lehetőség a sorba. Csak most bejött nagyobb munka, így ez a projekt eléggé hátra került a prioritásban...

Nincs más - csak egy szál gitár - szidom a rendszert - forradalmár. - Én vagyok egyedül 88 telén. (Auróra)

Sziasztok!
Egy-egy szerviz leállását melyik log fájlba találom? Órák óta bújom, de nem találok infót mi lehetett az oka, hogy leálltak szombaton az ftp és samba szervizek..
Red Hat 6.8

Köszi!

nezd meg dmesg-et, hátha az oom killer dolgozott. lehet nincs beállítva, hogy küldje messagesbe is.

CentOS-en hogyan tudok auditot/logolást beállítani egy specifikus kapcsolatra (az érdekel, milyen userid és process nyitja)? A meglévő eszközöket kell használni, nincs lehetőség telepítésre, fizikailag nem hozzáférhető a szerver.

https://www.coreinfinity.tech

Hello,

Érdeklődök, mert ismerősék kifogytak az ötletekből.

Linux, amit valami értelmes(?) létforma btrfs-re telepített. (Adatok meg ext4-en. )
Nemrég elkezdte, hogy boot után pár órával elmegy a / /opt /var /tmp /minden, ami egy Linux működéséhez kell 100% telítettségbe, read-only lesz az összes rendszerpartíció, és telehányja a dmesg-et ilyennel :
[2938413.951351] BTRFS: error (device sda2) in btrfs_drop_snapshot:5493: errno=-28 No space left
meg ilyennel :
[    6.335131] BTRFS warning (device sda2): block group 28710010880 has wrong amount of free space [    6.335135] BTRFS warning (device sda2): failed to load free space cache for block group 28710010880, rebuilding it now

Na most nekem az a meredek, hogy úgy látszanak a rendszerkönyvtárak, mintha külön partíciók lennének, de mind az sda2-n van, és nyilván ezért "telnek fel" egyszerre. Ez valami btrfs feature?

lsof|delete -t persze elfelejtettek nézni (Amikor még futott a cucc, most meg hétfőig nem férnek hozzá .) Mármint hogy az van-e, hogy valami tényleg teleírja a /-t, de az szerintem látszana a df kimenetén. Márpedig nem látszik, egyszer csak ilyen lesz :
/dev/sda2                                   40G   21G     0 100% /
/dev/sda2                                   40G   21G     0 100% /srv
Nem is megtelik, hanem 0-ra zuhan a szabad hely. WTF

Kapott egy fsck force-t boothoz, de mintha nem ment volna le a btrfs javítása. Jelenleg el se indul.

Tök olyan, mintha kiesegetne a storage a gép alól, de a storage team szerint nincs ilyen, és más, ugyanonnan futó gépeknek sincs baja. Viszont ez évek óta ment rendben, most egy update előtt adta meg magát.

Valaki btrfs tapasztalattal tud erre ötletet adni?

[ Szerkesztve ]

Mutogatni való hater díszpinty

Szerintem szedd le a hbmnf-t, és a hmpft-t is, majd húzd rá a mbaklh-ra. Ha ezután is fck üznetet ad, akkor hány ki a méhtelepre.

-=ecchphoto=-

Milyen disztró, milyen kernel? Van beállítva valamilyen automatikus snaphot tool? A ram vagy a diskhiba sem elvetendő, vmnél sem

Süsü, nem tudom a kernelt, a snapshotot sem, de szerintem nincs.
RAM/diszk hiba kizárható, más gépekre is hatna.

[ Szerkesztve ]

Mutogatni való hater díszpinty

Na, kiderült, hogy van snapshot. Na de eddig is volt...

Mutogatni való hater díszpinty

Van a snapper nevű utility, az btrfs esetén by default be van kapcsolva. Gyárilag kicsit sok snapshotot csinál és pont ez lesz az eredmény. Át kell configolni vagy kikapcsolni. Nincs vele baj, ha nagyobb root-ot használsz kb. 100G-t

Elvileg már próbálták, de nyilván mutatom majd nekik itt az itteni válaszokat. De azon kívül okozhat valami egyéb ilyet?
Illetve nekem meredek, hogy a free space cache összeomlik akkor, ha nem fér el a snapshot :S

[ Szerkesztve ]

Mutogatni való hater díszpinty

Nem nagyon, főleg nem susén ahol a btrfs az alap fájlrendszer és elég alaposan tesztelt. A ramhiba onnan jött elő amúgy, hogy egyszer jártam így, szétszedte a metadatat, hiába töröltem fájlokat továbbra is tele volt. A régebbi susékon a snapper default configja nem igazán szerencsés, újabbakon már agreszzívebben takarít.

space_cache
nospace_cache

Ezeket a mount opciókat is kipróbálhatod, de lehet a clear_cache opció a jó megoldás.

Csak tippelgetek, ha még nem olvasgattad volna ezeket végig:

[link]
[link]
[link]
btrfs mount

[ Szerkesztve ]

Köszi! Én nem, nem én supportálom a cuccot (sajnos), mint mondtam, ismerősök az előző melóhelyről

[ Szerkesztve ]

Mutogatni való hater díszpinty

Sziasztok!

Egyik RedHat 6.8 szerveremen nagyon sok, több száz, ez a hiba a dmesg-ben:
CIFS VFS: SMB signature verification returned error = -13

Igazából nem találtam megoldást rá...

Nem látom ezt, de ha a RH se tudja...
Amúgy kernel mikori? Mert erre 2020.03-as bugreport van, a 6.8 meg talán már csak extended-ben támogatott?

Mutogatni való hater díszpinty

Sziasztok,

tudna abban vki segíteni, h hogyan tudok egy adott könyvtárra kiadni úgy egy törlést, h minden 3 napnál régebbi állományt töröljön, de csak akkor ha az adott könyvtárban van fiatalabb állomány? Napi mentés megy az adott könyvtárba, de azt szeretném megoldani, h ha bármi miatt nem fut le mentés kliens oldalon, akkor se törlődjön 3 nap után az összes, hanem legalább egy mindig maradjon meg. Egy Synology nasról van szó egyébként, ha jól emléxem, ezeken FreeBsd alapú linux fut, ha ez számít.

̿' ̿'\̵͇̿̿\з=(◕_◕)=ε/̵͇̿̿/'̿'̿ ̿