Start program from boot, which needs library in non-standard place
David Kirkby
be setting this up with svcadm, but I'm afraid to say I've just put a
script in /etc/init.d
The important bit of my script is this.
su - sageserv /local-bins/start-sage
This calls a script, which has
#!/usr/bin/env bash
LD_LIBRARY_PATH=/usr/sfw/lib
export LD_LIBRARY_PATH
nohup /homes/sageserv/sage-4.3.0.1-Solaris-10-SPARC-sun4u-or-sun4v/
sage /homes/sageserv/notebook.py >> /homes/sageserv/logfile.out&
The problem is, the program that gets run, /homes/sageserv/
sage-4.3.0.1-Solaris-10-SPARC-sun4u-or-sun4v/sage needs to find the
OpenSSL libraries which are at /usr/sfw/lib. Despite my best efforts
(see LD_LIBRARY_PATH above), I can't get the server to find the
libraries, so it does not fully function.
If I type at a command promt
$ export LD_LIBRARY_PATH=/usr/sfw/lib
$ /homes/sageserv/sage-4.3.0.1-Solaris-10-SPARC-sun4u-or-sun4v/sage
so the program loads and finds the libraries.
How can I force the program to find the libraries, when started as the
system boots?
I've tried setting LD_LIBRARY_PATH in $HOME/.profile and
$HOME/.bashrc, but the thing will not load the libraries properly.
Dave
David Kirkby
I don't suppose this is relevant, but the server is running in a zone
Chris Ridd
> I want to start a server when a Solaris system boots. I know I should
> be setting this up with svcadm, but I'm afraid to say I've just put a
> script in /etc/init.d
Wimp :-)
It isn't *so* hard writing an SMF manifest that'll do the job. The
trick is working out what start exec_method to use; for something that
runs and isn't monitored (ie restarted) I think you want something like
this:
<exec_method type="method"
name="start"
exec="/local-bins/start-sage"
timeout_seconds="0">
<method_context>
<method_credential user="sageserv"/>
<method_environment>
<envvar name="LD_LIBRARY_PATH" value="/usr/sfw/lib"/>
</method_environment>
</method_context>
</exec_method>
<exec_method type="method"
name="stop"
exec=":true"
timeout_seconds="60"/>
<property_group name="startd" type="framework">
<propval name="duration" type="astring" value="transient"/>
</property_group>
Verbose... but it seems to work. I'm a bit unsure about the stop method.
But maybe you want a more normal service that just runs whatever your
script runs, and monitors it for crashes?
Is it easier to get -R/usr/sfw/lib passed the linker when linking stuff?
--
Chris
ji...@specsol.spam.sux.com
When you link it, add -R/usr/sfw/lib and you won't have this problem.
--
Jim Pennino
Remove .spam.sux to reply.
David Kirkby
> On 2010-02-03 21:15:18 +0000, David Kirkby said:
>
> > I want to start a server when a Solaris system boots. I know I should
> > be setting this up with svcadm, but I'm afraid to say I've just put a
> > script in /etc/init.d
>
> Wimp :-)
Yes, I know. It is someing I should learn.
> It isn't *so* hard writing an SMF manifest that'll do the job. The
> trick is working out what start exec_method to use; for something that
> runs and isn't monitored (ie restarted) I think you want something like
> this:
>
> <exec_method type="method"
> name="start"
> exec="/local-bins/start-sage"
> timeout_seconds="0">
> <method_context>
> <method_credential user="sageserv"/>
> <method_environment>
> <envvar name="LD_LIBRARY_PATH" value="/usr/sfw/lib"/>
> </method_environment>
> </method_context>
> </exec_method>
>
> <exec_method type="method"
> name="stop"
> exec=":true"
> timeout_seconds="60"/>
>
> <property_group name="startd" type="framework">
> <propval name="duration" type="astring" value="transient"/>
> </property_group>
>
> Verbose... but it seems to work. I'm a bit unsure about the stop method.
There is currently no 'clean' stop method for this program, so it will
just stop when the OS is no longer running.
> But maybe you want a more normal service that just runs whatever your
> script runs, and monitors it for crashes?
That would be an extra luxury I must admit.
> Is it easier to get -R/usr/sfw/lib passed the linker when linking stuff?
-R is not a great option, as potentially someone might have other
(newer) libraries in another place such /usr/local/openssl/lib. I
want to distribute this as a binary (though its open-source). So I
don't really want to hard-code the path. I've specifically built this
on the earliest Solaris release 10 (03/05).
> --
> Chris
David Kirkby
Chris Ridd
> On 3 Feb, 21:55, Chris Ridd <chrisr...@mac.com> wrote:
>> � � <exec_method type="method"
>> � � � � � � � � �name="stop"
>> � � � � � � � � �exec=":true"
>> � � � � � � � � �timeout_seconds="60"/>
>>
>> � � <property_group name="startd" type="framework">
>> � � � <propval name="duration" type="astring" value="transient"/>
>> � � </property_group>
>>
>> Verbose... but it seems to work. I'm a bit unsure about the stop method.
>
> There is currently no 'clean' stop method for this program, so it will
> just stop when the OS is no longer running.
The above is what my "always running" job does. It certainly seems to
do what I want.
>
>> But maybe you want a more normal service that just runs whatever your
>> script runs, and monitors it for crashes?
>
> That would be an extra luxury I must admit.
That would be a very much simpler manifest.
>
>> Is it easier to get -R/usr/sfw/lib passed the linker when linking stuff?
>
> -R is not a great option, as potentially someone might have other
> (newer) libraries in another place such /usr/local/openssl/lib. I
It is a bit risky to assume that any two versions of a library are
binary/link compatible and can be switched between by a user. OpenSSL
has historically been very bad about this.
> want to distribute this as a binary (though its open-source). So I
> don't really want to hard-code the path. I've specifically built this
> on the earliest Solaris release 10 (03/05).
I'm a bit surprised sage doesn't include its own copy of openssl :-)
--
Chris
David Kirkby
It would be against the GPL 2, since OpenSSL is not GPL compatible. It
is specifically listed at
http://www.gnu.org/licenses/license-list.html#GPLIncompatibleLicenses
The theory is, as it's supplied with the operating system, it is OK.
The GPL
http://www.gnu.org/licenses/gpl-2.0.html
says ..."However, as a special exception, the source code distributed
need not include anything that is normally distributed (in either
source or binary form) with the major components (compiler, kernel,
and so on) of the operating system on which the executable runs,
unless that component itself accompanies the executable. "
I must admit, I'm of the opinion that OpenSSL can't really be classed
as a major component of the operating system. But then I never thought
a compiler was part of the operating system!
Otherwise, that would be the easy solution!
Dave
David Kirkby
message. I have to use Google groups now, since my ISP has stopped
suporting newsgroups. I find that more frustrating, and easy to miss
things. Anyway ...
On Feb 4, 7:35 am, Chris Ridd <chrisr...@mac.com> wrote:
> On 2010-02-04 06:57:21 +0000, David Kirkby said:
>
> > On 3 Feb, 21:55, Chris Ridd <chrisr...@mac.com> wrote:
> >> <exec_method type="method"
> >> name="stop"
> >> exec=":true"
> >> timeout_seconds="60"/>
>
> >> <property_group name="startd" type="framework">
> >> <propval name="duration" type="astring" value="transient"/>
> >> </property_group>
>
> >> Verbose... but it seems to work. I'm a bit unsure about the stop method.
>
> > There is currently no 'clean' stop method for this program, so it will
> > just stop when the OS is no longer running.
>
> The above is what my "always running" job does. It certainly seems to
> do what I want.
OK. I know this is one of those things I should learn, but somehow
whenever I've needed to solve the problem, adding an entry in /etc/
init.d has always seemed the easy solution.
> >> But maybe you want a more normal service that just runs whatever your
> >> script runs, and monitors it for crashes?
>
> > That would be an extra luxury I must admit.
>
> That would be a very much simpler manifest.
I just need to read about this.
> >> Is it easier to get -R/usr/sfw/lib passed the linker when linking stuff?
>
> > -R is not a great option, as potentially someone might have other
> > (newer) libraries in another place such /usr/local/openssl/lib. I
>
> It is a bit risky to assume that any two versions of a library are
> binary/link compatible and can be switched between by a user. OpenSSL
> has historically been very bad about this.
I thought that by specifically using the first release of Solaris
(03/05), I would be safe. As far as I can see, Solaris 10 has not
updated from 0.9.7 of OpenSSL - only bug fixes have been applied.
> > want to distribute this as a binary (though its open-source). So I
> > don't really want to hard-code the path. I've specifically built this
> > on the earliest Solaris release 10 (03/05).
>
> I'm a bit surprised sage doesn't include its own copy of openssl :-)
I answered that before - GPL issues.
Sorry I did not reply fully to your post before.
Another problem with the -R solution is that setting CFLAGS globally
seems to cause a problem in Sage. In fact, it causes havoc, for
reasons I don't understand.
Chris Ridd
> Sorry Chris, for some reason I did not address the other parts of your
> message. I have to use Google groups now, since my ISP has stopped
> suporting newsgroups. I find that more frustrating, and easy to miss
> things. Anyway ...
Ouch, googlegroups is painful. The service from news.individual.net is
very good, for something like €10 per year.
>
> On Feb 4, 7:35 am, Chris Ridd <chrisr...@mac.com> wrote:
>> On 2010-02-04 06:57:21 +0000, David Kirkby said:
>>
>>> -R is not a great option, as potentially someone might have other
>>> (newer) libraries in another place such /usr/local/openssl/lib. I
>>
>> It is a bit risky to assume that any two versions of a library are
>> binary/link compatible and can be switched between by a user. OpenSSL
>> has historically been very bad about this.
>
> I thought that by specifically using the first release of Solaris
> (03/05), I would be safe. As far as I can see, Solaris 10 has not
> updated from 0.9.7 of OpenSSL - only bug fixes have been applied.
With OpenSSL the letter following the numbers forms part of the version.
OpenSSL's willingness/need to break binary compatibility may be the
reason that Sun has not updated the library in its entirety, and
instead just fixed bugs.
NB I haven't noticed if OpenSSL still frequently break binary
compatibility or not. The last time I saw this was a few years back.
--
Chris
David Kirkby
> On 2010-02-04 14:41:13 +0000, David Kirkby said:
> Ouch, googlegroups is painful. The service from news.individual.net is
> very good, for something like €10 per year.
That sounds good. I was in fact intending to ditch my ISP over this. I
should have done it as soon as I knew they were withdrawing the
service. There was an announcement in some low-traffic lists I read
occasionally read (like comp.unix.tru64), but I did see anything in
those I visit more often, until they withdrew the service. The
annoucments I previously see indicated they were removing those
newsgroups, not all newsgroups.
The only good thing about my ISP is that I get a fixed IP address.
That's quite hard to get unless you start paying quite a bit extra.
Otherwise I'd switch to BT as an ISP.
> With OpenSSL the letter following the numbers forms part of the version.
Yes, I was aware of that. But the version in Solaris is simply 0.9.7 -
there are no letters.
> OpenSSL's willingness/need to break binary compatibility may be the
> reason that Sun has not updated the library in its entirety, and
> instead just fixed bugs.
There is a long discusson about the issues here
http://blogs.sun.com/janp/entry/on_openssl_versions_in_solaris
One good thing on reading that, is that OpenSSL is actually quite an
important part of Solaris. Which makes it easy to claim that we are
not breaching the GPL by linking against it. I thought were were on
dodgy ground with that one, but it appears not.
Dave
Chris Ridd
> There is a long discusson about the issues here
>
> http://blogs.sun.com/janp/entry/on_openssl_versions_in_solaris
That's a useful page, thanks.
> One good thing on reading that, is that OpenSSL is actually quite an
> important part of Solaris. Which makes it easy to claim that we are
> not breaching the GPL by linking against it. I thought were were on
> dodgy ground with that one, but it appears not.
Great!
--
Chris
Drazen Kacar
> On 3 Feb, 21:55, Chris Ridd <chrisr...@mac.com> wrote:
> > Is it easier to get -R/usr/sfw/lib passed the linker when linking stuff?
>
> -R is not a great option,
But it is. You just need to ask for proper feature. :-)
> as potentially someone might have other
> (newer) libraries in another place such /usr/local/openssl/lib. I
> want to distribute this as a binary (though its open-source). So I
> don't really want to hard-code the path. I've specifically built this
> on the earliest Solaris release 10 (03/05).
Then link with '-R$ORIGIN/../extralib'. Create extralib directory (you
could just use lib if you want) at the same level with your bin (or sbin)
directory. In the installation script search for the proper library on the
system and place a symlink pointing to it in the extralib directory.
That should work and you also provide a way for the user to switch to
another library.
I'm not sure about your original problem. Is the executable setuid or
setgid, by any chance?
--
.-. .-. Yes, I am an agent of Satan, but my duties are largely
(_ \ / _) ceremonial.
|
| da...@fly.srk.fer.hr
David Kirkby
> David Kirkby wrote:
>
> I'm not sure about your original problem. Is the executable setuid or
> setgid, by any chance?
No. The code is started at boot by root, but switches to a non-root
user. The non-root user executes that script. So I can't see why it
does not follow LD_LIBRARY_PATH
Darren Dunham
> No. The code is started at boot by root, but switches to a non-root
> user. The non-root user executes that script. So I can't see why it
> does not follow LD_LIBRARY_PATH
Don't know either, but I'd be interested in if 'pargs -e <PID>' shows
LD_LIBRARY_PATH to be set the way you think it should. If not, I'd be
interested in what part of the execution is dropping it from the
environment.
--
Darren