Hi,
This is a strange one that I've knocked my head against for some time now. Perhaps someone (JC) will have some ideas?
Basically, sesinetd won't start on one of my three Linux machines at boot time. The bizarre thing is, all my machines are running identical Linux distros (OpenSuse10 with up to date patches) with identical Houdini versions (8.0.523).
The sesinetd script in /etc/init.d works fine (though I have to start it manually after boot!!) and there are appropriate links in /etc/init.d/rc5.d and rc3.d etc. Chkconfig –list shows me that they're on (really just showing me the links in rc4.d etc). There is _nothing_ in the logs about sesinetd at boot time.
The boot screen flies by too fast to see if it's starting it when it should, I thought there was a log that showed me all that? If so, it doesn't contain a string “sesi” anywhere, as I've been grepping furiously for it.
My other two machines work fine, identical setups. Very very strange.

Cheers,

Peter B

With Suse I always had to create the directory /etc/rc.d/init.d by hand before installing houdini. Otherwise, I had to start sesinetd by hand. This was with Suse 9.1 or 8.x, I don't know, if this still is necessary with OpenSuse. Just an idea…

Frank

Hi Frank,
Yeah, I had to add the sesinetd launch links by hand, but they're identical to my other two machines which work fine… It's very strange.

Cheers,

Peter B

Yah, sorry Peter, that's an odd one. Personally, I've never run the license server on SUSE yet, but the fact you have it running fine on two machines, well, that sort of limits the possibilities. Obviously something's different on the machines. By way of debugging, you could try replacing the sesinetd with another simple script that outputs something to a text file, that will establish once and for all whether the problem lies with sesinetd running and silently failing, or not being called at all. My guess(and probably yours) is that it's not getting called at all, but at least get that possibility out of the way.

Also, try adding another bogus process, see if that runs. Also try (temporarily only!) changing the “S” number from 89 to something else, just to give it a kick.

Cheers,

J.C.

Hey John,
Yeah, I'll replace the script and see what's up. I've changed the S89 number several times ) Doesn't seem to make any difference.
I was thinking I could piggyback it on another start script, for a massive hack ) Hey, at least it's Unix and I can do all these things easily )

Cheers,

Peter B

FYI, sesinetd is crashing as soon as it starts. The init.d script is working fine, but in the sesinetd_restart log it shows that it crashes.

I have no idea how to proceed. If I manually start it (sudo /etc/init.d/sesinetd start) it works fine and carries on like nothing had happened.

I may put a cron job in that restarts it )

Cheers,

Peter B

<I have no idea what I'm talking about>

Is it possible that sesinetd is being started before some other service that it depends on is being started? Like if networking isn't up and running and sesinetd was started that I would have a hissy-fit. I'm not sure what services sesinetd depends on though. Maybe a drive hasn't been mounted at that point in the init.d script?

Once again…I am just throwing out random ideas.

I'm pretty sure there's no service level requirements in sesinetd - and if there was, it would quietly not start, not crash. You can take a look at those .depend.start/stop/boot hidden scripts in there for more information. Had a crash course in those a while back getting SGE to wait for NFS. Interesting and obfuscated stuff.

One thing that leaps to mind is that whatever standard mechanism that the init services use on SUSE i.e. LSB is different than RH. For example, RH might expect every init script to be started with “foobar start”, whereas perhaps LSB requires “foobar”. Dunno, something to try, perhaps by looking at other scripts and comparing, maybe hacking the sesinetd script. Given you've ensured the script runs fine, and it doesn't start, seems to me the only thing left is the way it's being called.

All interesting stuff to me, since at some point I'm going to need to move our server.

Cheers,

J.C.

Another thing you might want to try is editing the init.d/ file to output some logging information to a file…Like when it was called, with what arguments, etc.

Hey,

i just posted a similar sugg on the ubuntu topic. The one place each linux distro varies greatly is in the start-up scripts (/etc/init.d). Usually, though, these days there's a “local” setup. Look for that. I posted examples of my /etc/conf.d/local.start http://www.sidefx.com/index.php?option=com_forum&Itemid=172&page=viewtopic&t=5361 [sidefx.com]

Basically, you want to start the houdini licenses as one of the last things to happen after booting. My guess is that they're being started too soon in the sequence - but sometimes, due to subtle startup delays (which vary upon every boot), they do manage to run!

Booting isn't a linear sequence. Think of it more as a parallel thing. Processes get “kicked off”, and then complete their startup in the background while more stuff gets started up. So, you can get into trouble if you're relying on (say) networking to be completely up and running before you start a license server. The solution is to start the Houdini license server towards the end of the startup process. That's why starting it manually works. Everything is up and running by then.

Look for your “local” start/stop stuff in /etc/init.d. Try this for starters:

% cd /etc/init.d
% ls *local*

This might not return anything at all (boo!). You're looking for a file called something like “local”. This is the conventional place to start stuff like license servers. If there isn't one, then you might consider making one.

If it does exist, then you know where to add your start/stop lines for the sesi license daemon. There's usually comments in the file that help you work out what to do.

In fact, gentoo now uses another file (in /etc/conf.d) where you list the stuff you want started/stopped. That's kinda good, because it means the files in /etc/init.d don't have to get updated all the time. It makes sense that files in “conf” are the ones YOU change… In my case I have /etc/conf.d/local.start and /etc/conf.d/local.stop

The other type of linux (eg. redhat?) uses symbolic links in a series of rc* directories to start up stuff. Usually they're named S07blah and S08blah. They're run in alphabetical order (so 7 is started before 8 ). Yes alphabetical order (in the order “/bin/ls” lists them!). This sounds crazy, but is cool if you're stuck without a running operating system. You can always make/change symbolic links - so it's good if you've painted yourself into a corner. yeah? – So! In that case you probably want to name your link to the sesi daemon as something like S95StartSesiLicenseDaemon and K05StopSesiLicenseDaemon. The “K” means kill. Note the “95” means that it's going to be run pretty much towards the end of the booting sequence. “05” means it's one of the first things killed when shutting-down.

To be clear, if you have a dir like /etc/rc3.d with lots of links in them, then you'd want to do something like:

# cd /etc/rc3.d
# ln -s ../init.d/sesinetd S95StartHoudiniLicense
# cd /etc/rc0.d
# ln -s ../init.d/sesinetd K05StopHoudiniLicense

(but that's only for those linux'es with rc directories - ie: NOT gentoo, etc).

If you do a “ls -l” in the various /etc/rc* directories you will see the links. The sgi's IRIX worked this way. It had links from the rc dirs into /etc/init.d

In fact, if your linux doesn't generally have or use /etc/init.d, the crazy thing is the Houdini Installation process will create the file: /etc/init.d/sesinetd - In that case, you can leave it there and just make the links in the various rc directories. Just make sure the license server is started late in the boot process. As I said earlier, it's best to use the “local” scripts if they exist. Look for them first. There could be one in the rc dirs already.

You should be seeing some sesinetd start and stop messages in the /var/log/messages file. (try: “grep -i sesi /var/log/messages”). Also, I do see a sesi license server startup message as the last line in the scrolling start-up text, just before the login: line (which disappears as soon as X-Windows starts).

I hope that helps.

cheers,
ben.

Hi,
I solve this by creating sh-script that starts sesinetd, and launches houdini. And made a symlink on this script.
It is interesting that My LMDE Linux Mint creates a desktop launcher that starts server and houdini with that command: /opt/hfs12.5.533/bin/houdinifx %F