Skip to content

UniData troubleshooting

Jump to bottom
Gordon Heydon edited this page Aug 24, 2026 · 7 revisions

UniData troubleshooting — deploying udt-git

Read this first. Several entries below describe UniObjects/UniRPC session errors (81xxx, udcs, unirpcd, login rejection). Since #45 the CLI no longer connects that way — it starts a UniData session as you over a pipe, with no host, service or stored password. If you are on 2.0.0 or later, those entries do not apply to udt-git; they are kept for anyone using UniRPC for other reasons.

Still current and worth checking: libgit2 missing or wrong version, the locale rejection, the repository ownership check, and add staging 0 records.

The UniData demo shows the setup on a correctly-configured server. This page is the flip side: symptoms you may hit and how to fix them, mostly around UniObjects/UniRPC, which a stock install (or a Trial Edition) does not always leave ready.

First step for any of these: run the release's preflight, which checks the whole runtime in one shot:

$ UDTHOME=/usr/ud83 sh preflight.sh

cannot open UniData session … (code 81014)

Meaning. 81014 = UVRPC_CANT_FIND_SERVICE — unirpcd could not find the udcs service in its services file. Every udt-git record operation (add, commit/status that read records) fails; init still "works" because it only touches the local git side.

Don't assume the service is missing. udtsetup does configure udcs (and defcs, udserver, …) at install time. But unirpcservices is owned root:bin, mode 600 — reading it as a non-root user returns nothing (permission denied), which is easy to mistake for an empty/missing config. Check it with sudo before touching it:

$ sudo cat /usr/unishared/unirpc/unirpcservices
udcs /usr/ud83/bin/udapi_server * TCP/IP 0 3600
defcs /usr/ud83/bin/udapi_server * TCP/IP 0 3600
...

Overwriting a correctly-configured file (because a non-root cat looked empty) is itself a common way to cause 81014.

If the entry really is missing or malformed, the format is exact — service program host transport flag timeout:

udcs   /usr/ud83/bin/udapi_server * TCP/IP 0 3600
defcs  /usr/ud83/bin/udapi_server * TCP/IP 0 3600

A frequent mistake is a stray field after the name, e.g. udcs 0 /usr/ud83/bin/udapi_server — unirpcd silently fails to parse that line and every session open returns 81014. unirpcd only reads the file at startup, so restart it after any edit:

$ export UDTHOME=/usr/ud83 PATH=$UDTHOME/bin:$PATH
$ sudo -E stopunirpcd ; sudo -E startunirpcd

add succeeds to connect but every login is rejected — fresh/cloud installs

Even with udcs configured, a newly provisioned server (especially a cloud image) is usually missing two things UniObjects login needs:

  • /etc/pam.d/udcs — udtsetup does not create it, and without it PAM falls through to deny, so the login fails. Create it:

    $ printf 'auth     required pam_unix.so nullok\naccount  required pam_unix.so\n' \
    | sudo tee /etc/pam.d/udcs

  • A password on the login user — cloud images create the user key-only (passwd -S shows LK, password locked), so there is nothing for UDT_PASSWORD to authenticate against. Give it one (matching UDT_PASSWORD).

udtsetup (or any udt binary): libunidata.so: cannot open shared object file

Cause. UniData's own shared libraries (libunidata.so, libu2callc.so, …) live in $UDTHOME/bin, which is not on the dynamic loader's path. Even udtsetup's helper accessory needs them, so a fresh install can loop on the license prompt printing this error.

Fix — put $UDTHOME/bin on the loader path once:

$ echo /usr/ud83/bin | sudo tee /etc/ld.so.conf.d/unidata.conf
$ sudo ldconfig

udt: Locale C.UTF-8 does not belong to current language group …

udt refuses to start, printing e.g. Locale C.UTF-8 does not belong to current language group 255/192/129.

Cause. UniData validates the shell's locale against an allow-list of locale names it recognises — and it is the name, not UTF-8, that matters:

$LANG / $LC_ALL udt starts?
en_US.UTF-8 ✅
C ✅
C.UTF-8 ❌
POSIX ❌

So en_US.UTF-8 is fine but C.UTF-8 and POSIX are rejected. The catch is that C.UTF-8 is the default in exactly the contexts where a locale isn't inherited — minimal cloud images, sudo/su, cron, systemd units, and non-interactive ssh — so udt can fail there even when your login shell is a perfectly good en_US.UTF-8.

Fix — give udt a locale it recognises:

$ export LANG=en_US.UTF-8      # or: export LANG=C   (avoid C.UTF-8 / POSIX)
$ udt

Make it durable by exporting LANG in the caller's profile (or the account's UniData login), and in any systemd/cron unit that runs udt. Anything that spawns udt for you inherits the same rule — e.g. udt-git's in-session verb setup shells out to udt, so it needs a recognised LANG in its environment too.

The session connects but the login is rejected

Cause. No PAM service for the connection service, so authentication falls through to pam_deny; or the login user has no password.

Fix.

$ printf 'auth     required pam_unix.so nullok\naccount  required pam_unix.so\n' \
    | sudo tee /etc/pam.d/udcs
# and give UDT_USER a real password that matches UDT_PASSWORD

Cloud images often create the login user key-only (no password) — set one, or the UniObjects login has nothing to authenticate against.

init: repository path '…' is not owned by current user

This is libgit2's check, not a udt-git rule — udt-git only prepends init: and passes the underlying GIT_EOWNER message through. It is git's CVE-2022-24765 mitigation: git/libgit2 refuse to operate on a repository whose top worktree directory is owned by a different user than the running process, because a .git/config (or hooks) you do not control can execute arbitrary commands.

Expect this on UniData. The mitigation targets shared workstations, but it fires constantly here for exactly the opposite reason: a UniData account is almost always a shared directory owned by the DBA / install user (root, unidata, …), while udt-git runs as whichever user invoked it. So the owner rarely matches — this is the normal case, not a misconfiguration.

Allow-list the account directory (libgit2 honours git's safe.directory):

$ git config --global --add safe.directory /usr/ud83/demo   # this account
$ git config --global --add safe.directory '*'              # any account, all users

--global writes the caller's ~/.gitconfig; for a host-wide rule that covers every user, put it in /etc/gitconfig instead:

$ sudo git config --system --add safe.directory '*'

An MVPKG install of git, and a udt-git built with the ownership check disabled for its own sessions, avoid this — the check only makes sense for a multi-user workstation, not a server tool pointed at DBA-owned account files.

(A could not catalog the GIT verb (is the package's CallC library built?) line alongside this is separate and non-fatal: a standalone binary-only install has no CallC library, so the in-session GIT verb can't be catalogued. The udt-git CLI — add / commit / status / log — still works; the in-session GIT verb needs the MVPKG CallC build.)

udt-git add reports staged 0 record(s), status shows nothing

The session opened fine, but the target has no records to stage.

  • The -a <account> directory must be a real UniData account UniData can LOGTO — a valid VOC with file pointers that resolve inside that directory. Copying another account's VOC (e.g. XDEMO's) does not make a working account; use the bundled demo account, or create one properly.
  • The named file must actually contain records — check in a session: COUNT <FILE>.

libgit2 missing or wrong version

Version required. The official EL8 udt-git release binary dynamically links libgit2.so.1.7 — i.e. libgit2 1.7.x. libgit2's soname is major.minor, so a different series (1.8, 1.9, or the ancient 0.26) will not load, even though the file is called libgit2.so. Check what your binary actually needs with ldd ./udt-git | grep libgit2 — preflight.sh reports the same soname.

Install it from EPEL — no compiler needed. RHEL/Rocky/Alma 8 carry the versioned compat package libgit2_1.7 (= 1.7.2, libgit2.so.1.7) in EPEL:

$ sudo dnf install -y epel-release
$ sudo dnf install -y libgit2_1.7

The base-OS libgit2 is only 0.26.8 (libgit2.so.26) and is far too old — libgit2_1.7 is a parallel-installable package, so it does not conflict.

Building udt-git yourself. The engine's floor is libgit2 ≥ 1.0.0 (it uses git_blob_create_from_buffer, added in 1.0); build against libgit2_1.7-devel so your binary matches the EPEL runtime above:

$ sudo dnf install -y libgit2_1.7-devel gcc git
$ LIBGIT2_LIBS='-l:libgit2.so.1.7' UDTHOME=/usr/ud83 sh build-udt.sh <stagedir>

(libgit2_1.7-devel ships no unversioned libgit2.so or pkgconfig, so link the exact soname with -l:libgit2.so.1.7; the headers are the standard /usr/include.) If instead you build against some other libgit2 (say a hand-built 1.9 under /usr/local), your binary then needs that series at runtime — preflight.sh always prints the exact soname to install.

Then re-run sh preflight.sh until the libgit2 line is ok.

UniRPC session error codes (81xxx)

From $UDTHOME/bin/include/intcall.h — the code udt-git prints on a failed session open:

Code Name Meaning / fix
81011 UVRPC_UNKNOWN_HOST bad UDT_HOST, or the host isn't responding
81012 UVRPC_FORK_FAILED unirpcd couldn't fork the service — check the service's program path + perms
81013 UVRPC_CANT_OPEN_SERV_FILE unirpcservices missing/unreadable (wrong path or permissions)
81014 UVRPC_CANT_FIND_SERVICE the udcs service isn't in unirpcservices (or is malformed) — see above
81015 UVRPC_TIMEOUT connection timed out
81016 UVRPC_REFUSED unirpcd isn't running — startunirpcd (or startud)
81018 UVRPC_SERVICE_PAUSED the service is paused on the server
81019 UVRPC_BAD_TRANSPORT invalid transport — check the TCP/IP field in the service line
81030 UVRPC_SSL_NOT_SUPPORTED the client asked for SSL the server doesn't offer

mv_git

Start here

Install

Reference

Related

Clone this wiki locally