Koneen jumiutuminen[RATKAISTU]

[Pendeli]

Koneen Ubuntu jumittuu joskus niin, että mikään ei liiku. Jos saa terminaalin auki niin se on jo hyvä. Mutta usein sekään ei onnistu. Sitten voi kokeilla jotain reisub-konsteja ym. kikkoja.

Usein ei viitsi vaivautua hakemaan laatikon pohjalta mahdollisia auttavia niksejä, mutta kun virrat katkaisee niin tilanne paranee kertaheitolla.

Onko noilla kikkakomennoilla jotain etua verrattuna siihen, että suosiolla katkaisee virrat heti alkuunsa ja säästää aikaa sen sijaan että tuhertaa eri komentojen ja näppäinyhdistelmien kanssa?

[Jakke77]

kerroppa mitä antaa ku päätteessä komennat lspci

[Pendeli]

Oliskohan vaan normaalit kapasiteettiongelmat kyseessä. Jumeja tapahtuu etupäässä silloin kun useampia sivuja on auki kolmella eri selaimella ja osassa suoria streameja menossa.

Se mikä kiinnostaisi tietää, että onko virrankatkaisulla jotain haittaa verrattuna muihin tapoihin?

Koodia: [Valitse]

~$ lspci
00:00.0 Host bridge: Intel Corporation 4th Gen Core Processor DRAM Controller (rev 06)
00:02.0 VGA compatible controller: Intel Corporation 4th Generation Core Processor Family Integrated Graphics Controller (rev 06)
00:03.0 Audio device: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor HD Audio Controller (rev 06)
00:14.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset Family USB xHCI (rev 04)
00:16.0 Communication controller: Intel Corporation 8 Series/C220 Series Chipset Family MEI Controller #1 (rev 04)
00:1a.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset Family USB EHCI #2 (rev 04)
00:1b.0 Audio device: Intel Corporation 8 Series/C220 Series Chipset High Definition Audio Controller (rev 04)
00:1c.0 PCI bridge: Intel Corporation 8 Series/C220 Series Chipset Family PCI Express Root Port #1 (rev d4)
00:1c.3 PCI bridge: Intel Corporation 8 Series/C220 Series Chipset Family PCI Express Root Port #4 (rev d4)
00:1d.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset Family USB EHCI #1 (rev 04)
00:1f.0 ISA bridge: Intel Corporation H81 Express LPC Controller (rev 04)
00:1f.2 SATA controller: Intel Corporation 8 Series/C220 Series Chipset Family 6-port SATA Controller 1 [AHCI mode] (rev 04)
00:1f.3 SMBus: Intel Corporation 8 Series/C220 Series Chipset Family SMBus Controller (rev 04)
02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 0c)

[Jakke77]

voihan se olla resurssi juttukin, voit tietenkin kokeilla muokata /etc/gdm3/custom.conf tiedostoa

Koodia: [Valitse]

sudo gedit /etc/gdm3/custom.conf
sieltä ota risuaidan pois #WaylandEnable=false kohdasta, uudelleen käynnistys tai uloskirjautuminen ton jälkeen ja katso tekeekö mitään jos ei niin voit laittaa risuaidan takas jos niin tahdot

[Tomin]

Voi olla ihan vaan sitäkin, että muisti loppuu kesken. Kannattaa vähän seurailla vaikka järjestelmän valvonnasta onko muistin käyttö ihan tapissa, kun kone jumittuu.

Se mikä kiinnostaisi tietää, että onko virrankatkaisulla jotain haittaa verrattuna muihin tapoihin?

On. Reisub on siitä parempi, että se antaa ohjelmille ainakin mahdollisuuden kirjoittaa muistissa olevat asiat levylle. Jos katkaiset sähköt virtanapista, muistissa olevat puskurit jäävät kirjoittamatta levylle ja voit menettää tietoa. Osittain kirjoitettu data voi aiheuttaa tiedostojen korruptoitumista. Tilanne on siis vähän sama kuin irrotettaessa muistitikku kertomatta siitä ensin käyttöjärjestelmälle. Hyvää on kuitenkin se, että nykyaikaiset tiedostojärjestelmät osaavat suojautua ja tiedostojärjestelmät eivät yleensä sekoa tuosta (tiedostot voivat edelleen mennä itse sekaisin).

Reisub pitää ottaa käyttöön, jotta sitä voi käyttää. Ohjeet: https://www.linux.fi/wiki/SysRq

[Pendeli]

Tuon sivun ohjeen mukaan minulla $ cat /proc/sys/kernel/sysrq
antaa vastaukseksi vain luvun 176. Onko reisub silloin otettu
käyttöön vai mitä tuo luku tarkoittaa?

sysrq-tiedoston sisältö:

Koodia: [Valitse]

# The magic SysRq key enables certain keyboard combinations to be
# interpreted by the kernel to help with debugging. The kernel will respond
# to these keys regardless of the current running applications.
#
# In general, the magic SysRq key is not needed for the average Ubuntu
# system, and having it enabled by default can lead to security issues on
# the console such as being able to dump memory or to kill arbitrary
# processes including the running screen lock.
#
# Here is the list of possible values:
#   0 - disable sysrq completely
#   1 - enable all functions of sysrq
#  >1 - enable certain functions by adding up the following values:
#          2 - enable control of console logging level
#          4 - enable control of keyboard (SAK, unraw)
#          8 - enable debugging dumps of processes etc.
#         16 - enable sync command
#         32 - enable remount read-only
#         64 - enable signalling of processes (term, kill, oom-kill)
#        128 - allow reboot/poweroff
#        256 - allow nicing of all RT tasks
#
#   For example, to enable both control of console logging level and
#   debugging dumps of processes: kernel.sysrq = 10
#
kernel.sysrq = 176
Kannattaisiko jotain muuttaa toisin? Varoituksiakin näköjään sysrq:n  käytöstä, pitäisikö kokemattoman parempi olla ronkkimatta?

[Tomin]

176 = 128 + 32 + 16 eli käytössä ovat reboot, remount ja sync komennot. Et siis voi esimerkiksi tappaa prosesseja, mutta voit kyllä kirjoittaa puskurit levylle, liittää tiedostojärjestelmät vain luku -tilassa ja käynnistää uudelleen eli viimeiset kolme REISUB:n toiminnosta. Jos haluat, voit muuttaa tuon 176 luvuksi 1, jolloin kaikki toiminnot ovat käytössä, tai lisätä siihen 4 ja 64 (yhteensä siis 244), jotta saat vain koko REISUB-komennon käyttöön.

Mainittujen r, e, i, s, u ja b näppäinten lisäksi k on joskus hyödyllinen, jos tietokone jumittelee muistin loppumisen takia. Se nimittäin tappaa ajossa olevat ohjelmat nykyisestä istunnosta eli käytännössä kaikki, mitä työpöydällä on auki (sekä ne, joita käyttäjä ei näe).

Riskit liittyvät lähinnä siihen, että noita SysRq-yhdistelmiä voi käyttää aina, jolloin kuka tahansa, joka pääsee fyysisesti käsiksi tietokoneeseen voi käyttää niitä, vaikka tietokone olisi lukittu. Jos käynnistää tietokoneen suoraan uudestaan painamalla Alt+SysRq+b se on sama kuin käynnistäisi tietokoneen reset-näppäimellä eli tietoa voi kadota. Samanlaisia riskejä toki liittyy myös "tappokomentoihin" eli noihin, jotka lopettavat ajossa olevat ohjelmat. Noista rekisteri ja muistidumpeista (komennot näppäimissä p ja m) voi teoriassa lukea muistin sisältöä, joten sekin on tietoturvariski. Mitään näistä komennoista ei ole mahdollista käyttää ilman näppäimistöä eli ne eivät mahdollista hyökkäystä esimerkiksi etäyhteydellä.

[Pendeli]

Monen mutkan kautta onnistuin saamaan sysrq-tiedoston auki nanomuodossa. Varmaankin siihen joku helppokin tapa olemassa?

Tiedoston viimeisellä rivillä olevaa lukua 176 yritin muuttaa luvuksi 1 mutta  en saanut sitä tallentumaan yhdistelmällä Ctrl+O.  Tallennuksen jälkeen ei Ctrl+X vaihtoehtoa näy. Sen paikalla vain cancel. Onko sama asia poistaa luettelossa ylempänä 1:n edestä risuaita? (#   1 - enable all functions of sysrq)

Ctrl-K poistaa rivin missä kursori sijaitsee, mutta kuinka poistan yksittäisen merkin?

[Tomin]

Luultavasti helpoin tapa käyttää geditiä ja gvfs:n admin-protokollaa (kysyy salasanaa avatessa):

Koodia: [Valitse]

gedit admin:///etc/sysctl.d/90-sysrq.conf
Nanollakin käy:

Koodia: [Valitse]

sudo nano /etc/sysctl.d/90-sysrq.confsitten normaalisti nuolinäppäimillä siirtyilet siellä ja korvaat tuon numeron. Lopuksi Ctrl+x, vastaukseksi kysymykseen tallentamisesta k eli kyllä ja tiedostonimen hyväksyntä enterillä.

Ne alussa olevat selitykset ovat kommentteja, joten niiden edestä ei kannata poistaa risuaitaa. Se aiheuttaisi vain syntaksivirheitä.

[Pendeli]

OK. Nyt toimii taas niin kuin pitääkin. Ainakin toistaiseksi.  Sähläsin aluksi jotain tuon nanotiedoston kanssa kun on tullut harvemmin käytettyä.

[Illu]

Pendeli jo kysyikin "...pitäisikö kokemattoman parempi olla ronkkimatta?" Miten siis on, kun tällä koneella ei ole pelkoa ulkopuolisista käyttäjistä, mutta reisub on melko tuttu komennus. Kone on kyllä sammunut, eikä ainakaan tunnistettavia ongelmia ole esiintynyt uudelleen käynnistyessä.

Koodia: [Valitse]

$ cat /proc/sys/kernel/sysrqKertoo myös 176.

Tiedostoa "/etc/sysctl.d/90-sysrq.conf" ei ole, muita kyllä on ko. kansiossa:
10-console-messages.conf
10-link-restrictions.conf
10-ptrace.conf
10-ipv6-privacy.conf
10-magic-sysrq.conf
10-zeropage.conf
10-kernel-hardening.conf
10-network-security.conf
99-sysctl.conf
README

Joku noista?

[Tomin]

Pendeli jo kysyikin "...pitäisikö kokemattoman parempi olla ronkkimatta?" Miten siis on, kun tällä koneella ei ole pelkoa ulkopuolisista käyttäjistä, mutta reisub on melko tuttu komennus. Kone on kyllä sammunut, eikä ainakaan tunnistettavia ongelmia ole esiintynyt uudelleen käynnistyessä.

Eipä tuo välttämättä mitään riko ja tärkeimmä komennot kuten s onnistuvat tuollakin asennolla. S siis kirjoittaa (synkronoi) muistissa olevat puskurit levylle.

Koodia: [Valitse]

$ cat /proc/sys/kernel/sysrqKertoo myös 176.

Tiedostoa "/etc/sysctl.d/90-sysrq.conf" ei ole, muita kyllä on ko. kansiossa:
10-console-messages.conf
10-link-restrictions.conf
10-ptrace.conf
10-ipv6-privacy.conf
10-magic-sysrq.conf
10-zeropage.conf
10-kernel-hardening.conf
10-network-security.conf
99-sysctl.conf
README

Joku noista?

Nykyinen asetus on luultavasti tiedostossa 10-magic-sysrq.conf. Sinänsä asetuksen voi laittaa mihin vain tiedostoon tuolla hakemistossa, jos se vain päättyy .conf ja joku toinen tiedosto ei ylikirjoita sitä.

[retu]

Ei kai tuota ole mikään pakko mennä säätämään. Ei ainakaan tuon jumittelun takia. Nykyinen oletusarvo 176 sallii ajaa sub-osan reisub-komennosta ja se riittää "hellävaraiseen" uudelleenkäynnistykseen.