Recently we completed an upgrade from Red Hat 7.9 to 8.10 and UniVerse 12.1 to 12.2.1 on our development machine, which was successful.

However last night we attempted the same task on our production server and ran into an issue with printing. While we were conducting checks after the OS upgrade but before the UniVerse upgrade we found that printing from UniVerse had stopped working.

Printing from the OS level continued to work as normal, all other UniVerse functions appeared to be operating normally also. In the Extensible tool it appeared that the spooler was running initially but after a few minutes we started to get messages like the screenshot below "SH: /usd: No such file or directory " and "The spooler daemon is not running"

All of the printer devices appeared correctly in the extensible tool and uvadm menu. Trying to start the spooler form the uvadm menu we received an error like the one below as well.

Naturally we tried restarting the system several times, and looked at permissions in a few places but couldn't spot any difference between the configuration on our development system and this one, aside from the spooler errors we were receiving.

Unfortunately our outage window had long since expired by this point and we needed to return the system to the business, so we were forced to roll-back to our initial snapshot again.

Has anyone seen this sort of thing happen before?

Matthew,

Difficult to tell in isolation, but I'd start with permissions - including ACLs - and very specifically trying as root rather than uvadm if uvadm was used. Also check whether anyone has changed permissions on 'ipcs' (e.g. setuid) on the machine where the upgrade worked.

If you could set up a RedHat VM and perform the same upgrade process - that would give more time to diagnose by comparison, comparing uvadm and root behaviour, tracing scripts / command execution. 

Also - was there a 'core' file generated? Looking at later release notes (14.1.1)

• UNV-33606 Linux only. Prior to this release, the UniVerse spooler process usd
  may have core dumped when using the default sp.config file with a
  "/dev/lp" printer defined. This issue has been resolved.

There are other changes at later releases but they do not seem related to this fault condition.

Regards

JJ

Matthew,

Difficult to tell in isolation, but I'd start with permissions - including ACLs - and very specifically trying as root rather than uvadm if uvadm was used. Also check whether anyone has changed permissions on 'ipcs' (e.g. setuid) on the machine where the upgrade worked.

If you could set up a RedHat VM and perform the same upgrade process - that would give more time to diagnose by comparison, comparing uvadm and root behaviour, tracing scripts / command execution. 

Also - was there a 'core' file generated? Looking at later release notes (14.1.1)

• UNV-33606 Linux only. Prior to this release, the UniVerse spooler process usd
  may have core dumped when using the default sp.config file with a
  "/dev/lp" printer defined. This issue has been resolved.

There are other changes at later releases but they do not seem related to this fault condition.

Regards

JJ

We managed to get a clone of the server in the post Red Hat update state.  The probelm as it stands now is that the spooler appears to be running: 

[root@unipclone bin]# ./usd.d
[root@unipclone bin]# usd: daemon: spooler already active!

However printing anything from inside UniVerse fails to spool a job, even if we Hold the job, it doesn't show up in the print queue. 

Permissions between the working system and this one seem to be the same, I did notice we had a slightly different owner on the usd.d and usd files (it was uvdb:bin instead of uvsb:staff) changing this did nothing though.

We're at a bit of a loss as to how to proceed if internal the jobs don't even seem to be created, any tips for things to look for would be great!

We managed to get a clone of the server in the post Red Hat update state.  The probelm as it stands now is that the spooler appears to be running: 

[root@unipclone bin]# ./usd.d
[root@unipclone bin]# usd: daemon: spooler already active!

However printing anything from inside UniVerse fails to spool a job, even if we Hold the job, it doesn't show up in the print queue. 

Permissions between the working system and this one seem to be the same, I did notice we had a slightly different owner on the usd.d and usd files (it was uvdb:bin instead of uvsb:staff) changing this did nothing though.

We're at a bit of a loss as to how to proceed if internal the jobs don't even seem to be created, any tips for things to look for would be great!

We managed to get a clone of the server in the post Red Hat update state.  The probelm as it stands now is that the spooler appears to be running: 

[root@unipclone bin]# ./usd.d
[root@unipclone bin]# usd: daemon: spooler already active!

However printing anything from inside UniVerse fails to spool a job, even if we Hold the job, it doesn't show up in the print queue. 

Permissions between the working system and this one seem to be the same, I did notice we had a slightly different owner on the usd.d and usd files (it was uvdb:bin instead of uvsb:staff) changing this did nothing though.

We're at a bit of a loss as to how to proceed if internal the jobs don't even seem to be created, any tips for things to look for would be great!