Nis not starting

I have two pis running osmc, which are supposed to access videos from my main NAS via NFS.
The NFS mounts happen via autofs, which in turn gets configured via NIS.

Since “a few days” nis does not start anymore… all I see in the system journal is this:

root@osmcdownstairs:~# journalctl -u nis.service
-- Logs begin at Fri 2020-10-23 14:12:09 CEST, end at Fri 2020-10-23 15:38:33 CEST. --
Okt 23 14:13:44 osmcdownstairs systemd[1]: Starting LSB: Start NIS client and server daemons....
Okt 23 14:14:07 osmcdownstairs nis[339]: Starting NIS services: ypbindbinding to YP server...........................................failed (backgrounded).
Okt 23 14:14:07 osmcdownstairs nis[339]: .
Okt 23 14:14:07 osmcdownstairs systemd[1]: Started LSB: Start NIS client and server daemons..

Needless to say that “systemctl restart nis” does not work.
Here’s the fun part: just starting ypbind without any arguments from a root shell works.

This only happens on the two pis running osmc - two other pis running “vanilla” raspbian buster, several openSUSE installations, a Fedora32 and a RHEL8 all work fine.

Any ideas?

one detail:
on the osmc pis the nis package is 3.17.1-3+b1, on the two other pis its 3.17.1-3+b2 …

hm… digging deeper:

/etc/apt/sources.list was last modified on oct. 20, and in my apt logs I see that there was a HUGE number of updates around that time. Could it be that that was a migration from stretch to buster?

All my hosts are managed via puppet and/or ansible so updates are automatic…

Yes, see

NIS is a blast from the past, though I can’t claim to remember much about it.

Perhaps something will show up in the logs: grab-logs -A

well, the other way to have a centralized “repository” for useraccounts, configuration files, and such, would be to set up a LDAP directory … so i’ll stick with NIS. I’m NOT migrating from nis to ldap+kerberos just because it is (slightly) newer.

So no logs then?

1 Like

https://paste.osmc.tv/texicekupa

I haven’t forgotten about you. After a few early config issues, I was able to reproduce the problem on a NIS client. The server at least ran ypserv, though nothing else, but ypbind on the client gave that error when run from systemd. Nevertheless ypbind does seem to be doing something (as evidenced from tshark) and rpcinfo -p shows it has bound to ports.

However… you mention that RaspiOS does work. I have RaspiOS 64-bit running on a newly-acquired Pi4, which uses the Debian repo for its arm64 code. Here’s what I see:

pi@raspberrypi:~ $ uname -a
Linux raspberrypi 5.4.51-v8+ #1333 SMP PREEMPT Mon Aug 10 16:58:35 BST 2020 aarch64 GNU/Linux
pi@raspberrypi:~ $ dpkg -l nis
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name           Version      Architecture Description
+++-==============-============-============-=============================================================
ii  nis            3.17.1-3+b1  arm64        clients and daemons for the Network Information Service (NIS)
pi@raspberrypi:~ $ systemctl status nis
● nis.service - LSB: Start NIS client and server daemons.
   Loaded: loaded (/etc/init.d/nis; generated)
   Active: active (running) since Fri 2020-10-23 22:27:25 BST; 10min ago
     Docs: man:systemd-sysv-generator(8)
  Process: 863 ExecStart=/etc/init.d/nis start (code=exited, status=0/SUCCESS)
    Tasks: 3 (limit: 1915)
   CGroup: /system.slice/nis.service
           └─876 /usr/sbin/ypbind

Oct 23 22:24:29 raspberrypi systemd[1]: Starting LSB: Start NIS client and server daemons....
Oct 23 22:27:25 raspberrypi nis[863]: Starting NIS services: ypbindbinding to YP server...........................................failed (backgrounded
Oct 23 22:27:25 raspberrypi nis[863]: .
Oct 23 22:27:25 raspberrypi systemd[1]: Started LSB: Start NIS client and server daemons..
pi@raspberrypi:~ $ rpcinfo -p
   program vers proto   port  service
    100000    4   tcp    111  portmapper
    100000    3   tcp    111  portmapper
    100000    2   tcp    111  portmapper
    100000    4   udp    111  portmapper
    100000    3   udp    111  portmapper
    100000    2   udp    111  portmapper
    100007    2   udp    628  ypbind
    100007    1   udp    628  ypbind
    100007    2   tcp    629  ypbind
    100007    1   tcp    629  ypbind

It’s also running 3.17.1-3+b1 and failing in the same way. Right now, I’d guess that it’s an upstream (Debian) problem.

it seems top be already fixed upstream, my two “non osmc” raspis are running the nis package version 3.17.1-3+b2 and it works fine…

on closer investigation there is a significant difference between debian buster on my OSMC pis and on the two other pis…

The OSMC2 pis use the arm repositories on debian.org - the other two (where nis works ok) use the repositories from raspberrypi.org:

root@osmcupstairs:/etc/apt# cat sources.list
deb http://ftp.debian.org/debian buster main contrib non-free
deb http://ftp.debian.org/debian/ buster-updates main contrib non-free
deb http://security.debian.org/ buster/updates main contrib non-free
deb http://apt.osmc.tv buster main
root@osmcupstairs:/etc/apt# cat /etc/debian_version
10.6
root@osmcupstairs:/etc/apt#

root@campi:/etc/apt# cat sources.list
deb http://raspbian.raspberrypi.org/raspbian/ buster main contrib non-free rpi
# Uncomment line below then 'apt-get update' to enable 'apt-get source'
#deb-src http://raspbian.raspberrypi.org/raspbian/ buster main contrib non-free rpi
root@campi:/etc/apt# cat /etc/debian_version
10.6
root@campi:/etc/apt#

“campi” is a pi zero W, “osmcupstairs” is a Pi 3 running OSMC.

Would it be safe (as in, would OSMC still work) if I were to replace the debian repos on my osmc pis with the ones from raspberrypi.org and ran an update?

No this is not recommended and will almost certainly cause issues.

Pi0/1 have different repos because we use Raspbian as a base.
Pi2/3 use upstream Debian.