This happens if both tsafs and tsands are autoloaded via statements in smdr.conf. From my experience it works if you autoload just tsafs and load tsands manually later via "smsconfig -l tsands". Personally, i load tsands only on specific master boxes (without nss volumes) anyway, but i've some time on troubleshooting this. Defect #1171767 is already open regarding this issue, you might want to open a SR and reference it. The larger the headcount of affected users, the higher the priority.

You are correct, loading the tsands manually does work.

Do you load tsands before each backup job and unload it afterwards or do you only load it once and let it run as long as the server is up?

Personally, (which means for me and my customers) in run dsbk backups on all servers, a tsands backup on ONE box which doesn't host NSS volumes (tsands only), and FS backups on all the others (tsafs only). Hence, i've (let's say WE'VE) never been affected by this issue. But i've played around and based on this playings it SEEMS that it's enough NOT to autoload tsands. So essentially:

- autoload ONLY tsafs

- postload tsands via let's say after.local

- backup whatever you want (NDS, NSS) successfully in any order as often as you like, i've tried with any combination of tsatest and SEP Sesam

While it seems (limited testing,though) to be easy to work around, please open a SR and reference the bug ID given to raise pressure...

It seems, that after.local runs too early after the startup of smdr in my case. With after.local it starts about 8 seconds after smdr is up. And then it shows the same behaviour as if it is autoloaded - that means crash.

I currently don't have my original lab available, but in another (clustered, that makes a difference) OES2018SP2 offset it seems that you need to have one "tsafs-only" action before loading tsands. So in this offset i need something like the stuff below as after.local. You'll have to set username and password in the "tsatest" line. And you'll have to adapt the path, of course, to match something with just a few files in it...

The "TERM" statement itself is mandatory (the tip mentioned saved me some time), it's value might also be something else (such as "linux").

#! /bin/sh
#
# Copyright (c) 2010 SuSE LINUX Products GmbH, Germany. All rights reserved.
#
# Author: Werner Fink, 2010
#
# /etc/init.d/after.local
#
# script with local commands to be executed from init after all scripts
# of a runlevel have been executed.
#
# Here you should add things, that should happen directly after
# runlevel has been reached.
# Thanks to StefanR for the tip mentioned here
# https://askubuntu.com/questions/905027/crontab-error-opening-terminal-unknown

sleep 60

export TERM=xterm-256color

/opt/novell/sms/bin/tsatest --path=/media/nss/DATA/some-very-small-dir -u .admin.services -p password --nowaitonexit

sleep 10

/opt/novell/sms/bin/smsconfig -l tsands

Ok, that with the "TERM" statement is new information - I'll try it with that - and thanks for the hint!

The other idea with a "tsatest" and some sleep statements I already tried - without success, probably because of the missing "TERM" statement.

All in all a quite complicated workaround for this problem. I have a SR open on this issue, but as I am only a small shop, the momentum of my SR is rather tiny, too.

tsatest won't run from after.local without a TERM statement, you'd even see the corresponding error in messages (without a hint WHY it failed, though). Nevertheless this pretty dirty workaround should help.

And the more SRs reference the defect, the better.

Indeed it does!

Just tested it on 2 servers. And on one server without NSS volumes (a DSfW server) the "--path=/usr/novell/sys" helped.

This is really weird .

In the meantime (2 days ago) Novell support provided me with a working version of novell-smdr

"novell-sms-1.5.4-0.92.8.1739.0.PTF.1171767.x86_64" with corresponding interface-libs.

This version cured all issues described in this thread and 2 backup jobs did work without issues.

Now deploying it to all OES production servers.