Dotaz: who neukazuje přihlášené uživatele

[MilanC]

Ahoj, mám Ubuntu 16.04 a nefunguje mi příkaz who. Resp. po spuštění mi nic nevrátí, nevypíše žádného uživatele ani chybu. Nevíte někdo čím to může být? Docela mi to chybí. :(

root@test:/# who
root@test:/#

Jsem připojen přes SSH jako root.

---

---

Odpovědi

[NN]

A co samotne 'w'.

[MilanC]

# w
 11:40:39 up 6 days, 41 min,  0 users,  load average: 5.01, 4.24, 4.20
USER     TTY      FROM             LOGIN@   IDLE   JCPU   PCPU WHAT

[rastos]

Existuje súbor /var/run/utmp ? Ak áno, má nejaký aktuálny čas? Aké má prístupové práva, vlastníka a skupinu? Aké má prístupové práva, vlastníka a skupinu adresár /var/run ?

[MilanC]

ls: cannot access '/var/run/utmp': No such file or directory

# ls -l /var | grep log
drwxrwxr-x 12 root syslog 4096 Dec  4 06:25 log

[rastos]

Na mojom stroji:

$ ls -ld /var/run/utmp /var/run 
drwxr-xr-x 1 root root   428 Nov 17 11:26 /var/run/
-rw-rw-r-- 1 root utmp 10752 Dec  6 12:31 /var/run/utmp

Na nejakom inom stroji čo tu mám:

$ ls -ld /var/run/utmp /var/run /run
drwxr-xr-x 29 root root 1220 Dec  6 11:31 /run
lrwxrwxrwx  1 root root    4 Oct  5  2014 /var/run -> /run
-rw-rw-r--  1 root utmp 4992 Dec  6 11:31 /var/run/utmp

Takže by som v prvom kole skúsil ten súbor vytvoriť, dať mu chown root.utmp a chmod 664.

[MilanC]

Pardon, postnul jsem log místo run. Zkusil jsem utmp nahrát z jiného stroje kde ho mám + reboot, ale nepomohlo.

# ls -l /var | grep run
lrwxrwxrwx  1 root root      9 Oct 14 15:35 lock -> /run/lock
lrwxrwxrwx  1 root root      4 Oct 14 15:35 run -> /run
# ls -l / | grep run
drwxr-xr-x  30 root root  1040 Dec  6 12:36 run

[MilanC]

Jinak po rebootu tam zase utmp nemám.

[rastos]

Nie je na tom systéme systemd?

[MilanC]

Myslím že ano.

# pstree | grep system
systemd-+-accounts-daemon-+-{gdbus}
        |-systemd-journal
        |-systemd-logind
        |-systemd-timesyn---{sd-resolve}
        |-systemd-udevd

[rastos]

Systemd si asi utmp spravuje sám. Veľa šťastia

[cezz]

Ten utmp subor by mal vytvorit service ktory sa vola systemd-tmpfiles-setup. Cize pre zaciatok by som pozrel dve veci:

systemctl status  systemd-tmpfiles-setup.service

Skontroluj ci je v stave active. Potom by som skontroloval logy:

journalctl -u   systemd-tmpfiles-setup.service

Pozri, ci sa tam neobjavi nieco podozrive a pripadne to pastni do commentu.

No a na zaver je mozno na mieste skontrolovat konfiguraciu systemd-tmpfiles. Ten tvoj konkretny utmp subor by mal byt nakonfigurovany v /usr/lib/tmpfiles.d/systemd.conf - pozri sa ci tam mas tento riadok:

F! /run/utmp 0664 root utmp -

[MilanC]

Díky všem. Nakonec jsem se vykašlal na systemd a nahodil zpět upstart. Se systamd jsem měl jen problémy a vůbec do toho neviděl. Who mi již funguje.

Jediné co mi vadí, tak se mi v grubu vytvořily nějaké systemd menuentry, nevíte jak to zruším, ať mi tam nestraší?

  menuentry 'Ubuntu, with Linux 4.4.0-47-generic' --class ubuntu --cl ...
  menuentry 'Ubuntu, with Linux 4.4.0-47-generic (systemd)' --class u ...
  menuentry 'Ubuntu, with Linux 4.4.0-47-generic (recovery mode)' --c ...
  menuentry 'Ubuntu, with Linux 4.4.0' --class ubuntu --class gnu-lin ...
  menuentry 'Ubuntu, with Linux 4.4.0 (systemd)' --class ubuntu --cla ...
  menuentry 'Ubuntu, with Linux 4.4.0 (recovery mode)' --class ubuntu ...

Odebrat ručně ze souboru a update-grub nebo se to dělá nějak lépe? (mám jen cli). Díky

[pavlix]

Ten update-grub má vlastní konfiguráky, ze kterých generuje konfigurák v /boot, takže ano.

[MilanC]

Myslel jsem odebrat odtud /boot/grub/grub.cfg

[pavlix]

Nerozumím.

[MilanC]

No, jestli je postup správný když odeberu ty menuentry (se systemd) z /boot/grub/grub.cfg. Resp. asi se mi tam po update-grub znovu nagenerují? Otázka asi měla spíše být, proč se mi tam generují menuentries pro systemd, když jsem ho ze systému vypakoval. :)

[NN]

Smazat si vygenerovanou konfiguraci? Podivej se do /etc/default/grub ..

[k3dAR]

/boot/grub/grub.cfg je generovany pomoci update-grub kterej cte konfiguraci z /etc/default/grub a pouziva pridruzene scripty (ted nevim kde :)
takze kdyz upravis grub.cfg a pak pustis ty nebo update systemu update-grub, tak samozrejme o veskere svoje zmeny prijdes :)
v /etc/default/grub (v 16.04) nevidim zadnej switch co by resil tvuj dotaz, bud tam musis (jako u spouty ostatnich voleb) tam pridat sam, nebo upravit nejaky ten pridruzeny script...

[k3dAR]

na prasaka (pokud to nepujde jinak) jde asi o v /etc/grub.d/10_linux

SUPPORTED_INITS="sysvinit:/lib/sysvinit/init systemd:/lib/systemd/systemd upstart:/sbin/upstart"

odebrat tedy tu cast systemd:/lib/systemd/systemd pripadne zkontrolovat ze to na disku opravdu uz nemas...

[k3dAR]

jeste sem to okouknul, takze konfiguracni volba zadatelna do /etc/grub/default pro to opravdu neni... update-grub nacita a pousti z /etc/grub.d vse, 10_linux pak pro ty uvedene SUPPORTED_INITS zjistuje jestli existuje a ma spustitelny priznak, pokud ano vygeneruje polozku s dovetkem daneho initu, vynechava pritom init ktery je nastaven v GRUB_CMDLINE_LINUX a/nebo GRUB_CMDLINE_LINUX_DEFAULT, tomu dela polozky normalni vychozi bez dovetku...

takze predchozi neni na prasaka, resp. je to nejcistejsi moznost...
akora ze pokud /lib/systemd/systemd existuje, tak neni potreba to mazat, ale staci odebrat atribut spustitelny, tedy:

sudo chmod -x /lib/systemd/systemd

[k3dAR]

EDIT: konfiguracni volba zadatelna do /etc/grub/default pro to opravdu neni.
melo byt samozrejme
konfiguracni volba zadatelna do /etc/default/grub pro to opravdu neni.

[MilanC]

/lib/systemd/systemd neexistuje a přesto se to generuje, grr. Dám to pryč tedy ručně.

[k3dAR]

sem zvedav kdy napises ze sis prehledl a ze to tam existovalo ;) nerikam ze sem necco nemohl v "update-grub" a vsem okolo prehlednout, ale to co sem psal bylo celkem jasne a dane, ta polozka vznika jen pokud ten soubor existuje a musi zaroven byt sputitelny... v 10_linux se o to stara tahle cast:

  for supported_init in ${SUPPORTED_INITS}; do
    init_path="${supported_init#*:}"
    if [ -x "${init_path}" ] && [ "$(readlink -f /sbin/init)" != "${init_path}" ]; then
      linux_entry "${OS}" "${version}" "init-${supported_init%%:*}" \
                  "${GRUB_CMDLINE_LINUX} ${GRUB_CMDLINE_LINUX_DEFAULT} init=${init_path}"
    fi
  done

ted kdyz koukam znovu tak sem pretim kecal, GRUB_CMDLINE_LINUX a GRUB_CMDLINE_LINUX_DEFAULT se nekontroluje na pritomnost init nastaveni, ta kontrola je podle toho kam smeruje link /sbin/init, tedy ze vychozi init polozku nepridava s dovetkem ale jako vychozi polozky

[pavlix]

Popisuješ přesný opak toho, co jsem psal. Je potřeba upravovtat stabilní konfiguraci a generovat generovanou, nic víc v tom není. Konkrétní cesty máš už v reakcích ostatních. :)