smdr on OES2018SP2 not working


After upgrading to OES2018 SP2 I noticed, that smdr crashes, if one tries to authenticate. So backup of Edir and NSS volumes via TSAs not working.

I have already a SR open on this issue, which seems to be a known one. According to support they are working with high priority on this problem.

I have switched to backup the virtual disks, on the Vmware hypervisor level, but would prefer to switch back to the smdr file level backup to allow restore at that level.

  • 0  

    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.


  • 0   in reply to Mathias Braun

    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?

  • 0   in reply to Prindl

    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...


  • 0   in reply to Mathias Braun

    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.

  • Verified Answer

    0   in reply to Prindl

    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

    sleep 60

    export TERM=xterm-256color

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

    sleep 10

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



  • 0   in reply to Mathias Braun

    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.

  • 0   in reply to Prindl

    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.

  • 0   in reply to Mathias Braun

    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 .


  • 0   in reply to Prindl



  • 0   in reply to Prindl

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

    "novell-sms-1.5.4-" 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.