No omni.service on Linux after "successful" client installation

I see an odd issue with Data Protector 24.4 on SLES 15 SP6 (x86_64):

A backup showed IPC connection errors, so I inspected the client that had been booted after a kernel update yesterday:

× omni.socket - DATA-PROTECTOR-INET
Loaded: loaded (/usr/lib/systemd/system/omni.socket; disabled; preset: disabled)
Active: failed (Result: resources)
Listen: 172.20.2.24:5565 (Stream)
Accepted: 0; Connected: 0;
CPU: 1ms

Jan 23 17:32:23 localhost (sd-listen)[796]: omni.socket: Failed to create listening socket (172.20.2.24:5565): Cannot assign requested address
Jan 23 17:32:23 localhost systemd[1]: omni.socket: Failed to receive listening socket (172.20.2.24:5565): Input/output error
Jan 23 17:32:23 localhost systemd[1]: omni.socket: Failed to listen on sockets: Input/output error
Jan 23 17:32:23 localhost systemd[1]: omni.socket: Failed with result 'resources'.
Jan 23 17:32:23 localhost systemd[1]: Failed to listen on DATA-PROTECTOR-INET.

When I tried to inspect the omni.service unit, I could not find it. When I tried to find out whether this had been delivered by RPm or not, it even gets more strange:

I found a /usr/lib/systemd/system/omni.socket, but that is not part of any RPM (says "rpm -qf /usr/lib/systemd/system/omni.socket").

So I removed all the RPMs and re-installed the client.

The client installation log claimed that every component installed sucessfully (!), but the client could not be imported.

When checking the client after that, I see that there still is no omni.servcie unit, and no process is listening on the omni socket 5565/tcp.

Here are the essential logs from that installation:

Jan 24 08:07:52 pc [RPM][9533]: Transaction ID 67933c48 started
Jan 24 08:07:55 pc [RPM][9533]: install OB2-CORE-24.4-1.x86_64: success
Jan 24 08:07:55 pc [RPM][9533]: install OB2-CORE-24.4-1.x86_64: success
Jan 24 08:07:55 pc [RPM][9533]: Transaction ID 67933c48 finished: 0


Jan 24 08:09:01 pc [RPM][10111]: Transaction ID 67933c8d started
Jan 24 08:09:08 pc [RPM][10111]: install OB2-TS-CORE-24.4-1.x86_64: success
Jan 24 08:09:08 pc [RPM][10111]: install OB2-TS-CORE-24.4-1.x86_64: success
Jan 24 08:09:08 pc [RPM][10111]: Transaction ID 67933c8d finished: 0

Jan 24 08:09:12 pc [RPM][10626]: Transaction ID 67933c98 started
Jan 24 08:09:13 pc [RPM][10626]: install OB2-CMNUTILS-24.4-1.x86_64: success
Jan 24 08:09:13 pc [RPM][10626]: install OB2-CMNUTILS-24.4-1.x86_64: success
Jan 24 08:09:13 pc [RPM][10626]: Transaction ID 67933c98 finished: 0

Jan 24 08:09:17 pc [RPM][10916]: Transaction ID 67933c9d started
Jan 24 08:09:18 pc [RPM][10916]: install OB2-DA-24.4-1.x86_64: success
Jan 24 08:09:18 pc [RPM][10916]: install OB2-DA-24.4-1.x86_64: success
Jan 24 08:09:18 pc [RPM][10916]: Transaction ID 67933c9d finished: 0

Jan 24 08:09:23 pc [RPM][11244]: Transaction ID 67933ca3 started
Jan 24 08:09:26 pc [RPM][11244]: install OB2-AUTODR-24.4-1.x86_64: success
Jan 24 08:09:26 pc [RPM][11244]: install OB2-AUTODR-24.4-1.x86_64: success
Jan 24 08:09:26 pc [RPM][11244]: Transaction ID 67933ca3 finished: 0

Note that every install is logged as successful twice, and the delays between package installs is significant (4-5 seconds). I could not see any kind of error message.

I also checked the package installation scripts using "rpm -q --scripts $(rpm -qa OB2\*)", but could not find where the socket file comes from.

  • Verified Answer

    +1

    My fault: The service unit is not omni.service, but omni@.service as it will have multiple instances.

    But given the multiple instances, using a fixed PID-file name (PIDFile=/var/run/omni.pid) makes no sense at all; the syslog warning brought that to my attention:

    systemd[1]: /usr/lib/systemd/system/omni@.service:7: PIDFile= references a path below legacy directory /var/run/, updating /var/run/omni.pid → /run/omni.pid

    Maybe that explains the IPC connection errors, because if the PID file contains a valid PID, the servcie is considered to be running already. Also if no script ever used the PID file, why create one explicitly at all? Looks very much like a design mistake IMHO.

    So I decided to fix the issue locally by adjusting a copy of the service like this:

    # cp -p /usr/lib/systemd/system/omni@.service /etc/systemd/system

    # vi /etc/systemd/system/omni@.service

    # systemctl cat omni@.service
    # /etc/systemd/system/omni@.service
    [Unit]
    Description=DATA-PROTECTOR-INET
    Requires=omni.socket
    After=nss-lookup.target

    [Service]
    StandardInput=socket
    #PIDFile=/var/run/omni.pid
    ExecStart=/opt/omni/lbin/inet -log /var/opt/omni/log/inet.log
    SuccessExitStatus=0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58>
    Type=simple
    KillMode=process

    [Install]
    WantedBy=default.target

    Now when importing the client it worked smoothly without any warning in syslog. And due to the copy being made it also survives a client upgrade ;-)

    And the IPC connection issues are gone now.