Roger Oberholtzer wrote:

On Wed, 2011-11-02 at 17:36 +0100, Per Jessen wrote:

...

Roger Oberholtzer wrote:

...

I want to use startproc to start more than one instance of a program in an rc script. Is this possible? It seems that it ignores any subsequent starts of the binary if it has already started it once. None of the option for startproc seemed to matter. If I make a link to the binary with a different name and use that, then I get another proc running. Have I missed something?

Hi Roger,

the man page says:

For the possibility of having two different sessions of one binary program, the option -i ignore_file allows to specify a pid file which pid number is used to ignore all processes of corresponding process session.

On 11.2, where I am running this, the man page rather confusingly only says this about the option:

-i ignore_file The pid found in this file is used as session id of the same binary program which should be ignored by startproc. Obviously this option does not work if option -f is specified.

I see words. But they don't really say anything to me...

Your explanation provided more insight. Thanks.

Hmm, I'm not sure my "explanation" was worth much, I had trouble understanding that paragraph myself.

But I am still unclear on this. Should I give it the pid file controlling the first instance of the binary, which was made by the first instance of startproc? Since I leave making that file to startproc, how would I find out the name it used? Or is this something else?

I think you'll have to experiment to find out what it really does. /Per -- Per Jessen, Zürich (7.6°C) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Fri, 2011-11-04 at 00:22 +1030, Rodney Baker wrote:

I'd suggest you many need multiple entries in /etc/rc.d/init.d (e.g. 51- <process>.rc, 52-<process>.rc...n-<process>.rc). I'd see the flow something like:

I perhaps could have lived with that. But it 'seems' it is not the rc script name that is behind this. It is the binary that you run. In my case I am running /sbin/vblade. The second call to startproc senses that /sbin/vblade is already running and does nothing. If I make a copy of the binary called /sbin/vblade2, then I can start another.

-start first instance -check for running instance -get pid of running instance -start second instance with -i <pid of running instance> - repeat for subsequence instances

I think there can only be a second instance, since you can only give one pid with -i. A third instance would require that you tell two pids to ignore. Seems like the -i option to startproc is really a hack. Unless it is only the documentation that makes it appear to be so.

YMMV. I've never tried it - just guessing from the rather cryptic documentation snippets you've posted.

I will post back when I see what works. Yours sincerely, Roger Oberholtzer OPQ Systems / Ramböll RST Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 roger.oberholtzer@ramboll.se ________________________________________ Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden www.rambollrst.se -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Fri, 2011-11-04 at 16:34 +0100, Per Jessen wrote:

Roger Oberholtzer wrote:

...

On Fri, 2011-11-04 at 00:22 +1030, Rodney Baker wrote:

...

I'd suggest you many need multiple entries in /etc/rc.d/init.d (e.g. 51- <process>.rc, 52-<process>.rc...n-<process>.rc). I'd see the flow something like:

I perhaps could have lived with that. But it 'seems' it is not the rc script name that is behind this. It is the binary that you run. In my case I am running /sbin/vblade. The second call to startproc senses that /sbin/vblade is already running and does nothing. If I make a copy of the binary called /sbin/vblade2, then I can start another.

hi Roger

this is a poor workaround:

create a tiny script, e.g. /sbin/runvblade:

----- #!/bin/sh exec /sbin/vblade --------

You should be able to run "startproc -s /sbin/runvblade" as many times as you want.

Curious. Why would this work? I will of course try it. But I would like to know what is different between running a script and the program direct. Will it 'status' and 'stop' commands to the rc script also work? Yours sincerely, Roger Oberholtzer OPQ Systems / Ramböll RST Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 roger.oberholtzer@ramboll.se ________________________________________ Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden www.rambollrst.se -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Tue, 2011-11-08 at 08:31 +0100, Per Jessen wrote:

...

Curious. Why would this work? I will of course try it. But I would like to know what is different between running a script and the program direct.

It works because the name of executable changes when the script does 'exec'.

Perhaps I need something stronger than my morning coffee today. If the script name is the same, why would the name of the executable be different?

...

Will it 'status' and 'stop' commands to the rc script also work?

Depends on the script :-) If it uses killproc, it probably won't do what you expect, no. Basically, startproc/killproc were meant to manage single instances, not multiple.

Seems that is true. Seems a bit of an oversight, IMHO. The assumption is that any service started will always work as a single instance of the executable. In my case, I need the vblade server to make disk images available on more than one ethernet interface. The docs imply that the ethernet device given must be like 'eth0'. I do not see syntax for a list of interfaces, or even a wildcard like 'all' or 'any'. Multiple server instances are required for this. Of course, I do not have to use startproc. But as it handles tracking and killing the programs it strarts, it seemed like a good choice. Yours sincerely, Roger Oberholtzer OPQ Systems / Ramböll RST Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 roger.oberholtzer@ramboll.se ________________________________________ Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden www.rambollrst.se -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 11/8/2011 3:01 AM, Roger Oberholtzer wrote:

On Tue, 2011-11-08 at 08:31 +0100, Per Jessen wrote:

...

...

Curious. Why would this work? I will of course try it. But I would like to know what is different between running a script and the program direct.

It works because the name of executable changes when the script does 'exec'.

Perhaps I need something stronger than my morning coffee today. If the script name is the same, why would the name of the executable be different?

...

...

Will it 'status' and 'stop' commands to the rc script also work?

Depends on the script :-) If it uses killproc, it probably won't do what you expect, no. Basically, startproc/killproc were meant to manage single instances, not multiple.

Seems that is true. Seems a bit of an oversight, IMHO. The assumption is that any service started will always work as a single instance of the executable. In my case, I need the vblade server to make disk images available on more than one ethernet interface. The docs imply that the ethernet device given must be like 'eth0'. I do not see syntax for a list of interfaces, or even a wildcard like 'all' or 'any'. Multiple server instances are required for this. Of course, I do not have to use startproc. But as it handles tracking and killing the programs it strarts, it seemed like a good choice.

You don't really need to use startproc/killproc to have a well-integrated start/stop script that tracks the running/not-running state. You can write shell functions that do the actual starting/stopping according to whatever logic you happen to need, and that merely return with the proper exit values that are meaningful to rc_status. In my start/stop script for lxc containers, to start-up, I have to walk a tree of directories looking for config files, and run some commands based on what I find. The most immediate binary is actually just gnu screen, not even a binary that makes up the "service" itself, it just serves as a virtual console for each started container vm. Then the container starter binary itself doesn't even stay running, it just sets up the kernel space to run a vm in, and launches that containers /sbin/init in it, and the lxc-start command itself goes away almost instantaneously. To stop, I have to run a few different commands to determine which vm's are even running at that time. Mostly along the lines of looking for instances of "init" that aren't pid #1, and which actually correlate with one of the config files above. And then the command to actually stop is not killing any binary but sending a powerfail signal to the vm's init process and waiting for it to take down the processes within the vm. For status, there is a similar process of scanning for possible running vm's by looking for a few different things and correlating with the config files. This is so that it ignores anything that was not started by the same start script, which is essentially the same reason simpler start scripts use pid files. The start script needs to be sure to only kill a process it itself started, and ignore the very same process that someone may have started manually. In all cases the number of instances is unpredictable. There may be 0 or any number of valid and enabled vm config files. There may be 0 or any number of currently running vm's. 0 or any number of the currently running vm's may be associated with any of those config files. And all of these can change before during and after start-time and stop-time, so it all has to be determined dynamically on the spot right when you say start or stop or status. But the script is integrated well enough because each of those complex and dynamic tasks is written into a shell function, and the function has at it's end one or more return commands that sets the exit value to the specific values that are meaningful to the "rc_status -v" command which immediately follows. In my case, the start and stop functions always actually return success but the key one is status, where it returns a 3 instead of 0 if any configured vm's are found to be running. That, and the way that the stop case is written, prevents the host from shutting down until the vm's have all gracefully shut themselves down. As with everything there is work to be done of course, if a vm hangs it prevents the host from ever finishing it's own shutdown. The point was to show the method itself. Your script can be better and more complete than mine. Init script: https://build.opensuse.org/package/view_file?file=lxc.init&package=rclxc&project=home%3Aaljex&srcmd5=4dc6f1d81df55fa2a50c7c9a50b5cb63 (Note the web viewer hides the _ in rc_status at least in some browser/font/resolution combos. actually in my screen every single line of the script has it's own tiny scroll bar that can be scrolled down to show the _ now, it didn't used to have that some time ago.) Exit values documentation: http://en.opensuse.org/openSUSE:Packaging_init_scripts#Exit_Status_Codes -- bkw -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Wed, 2011-11-09 at 08:35 +0100, Per Jessen wrote:

Roger Oberholtzer wrote:

...

In my case, I need the vblade server to make disk images available on more than one ethernet interface. The docs imply that the ethernet device given must be like 'eth0'.

I've just looked up what your vblades are for - AoE, right? YOu've probably got a reason for needing AoE, so this might not help you much, apologies in advance, but with iSCSI you'd only have one target-daemon.

I use KIWI to make diskless versions of openSUSE. In our system, these run in diskless computers that boot via PXE. Having booted, they need a root file system. In fact, all diskless systems share the same root file on the boot server, which is provided via vblade. They do not modify this root image. All changes are in RAM on the diskless machine, When they reboot all is fresh. We use these systems to do things like manage special hardware (VME-bus access, JPEG2000 hardware compression cards, etc.). It is really great not having to install an operating system on these slave systems. Add the proper entry to dhcpd.conf and you have a new data collection computer. As all this is in a vehicle on the road, worries about power loss are not an issue with these systems. We do have a proper UPS that makes powerloss unlikely. Each instance of vblade will serve an image to any number of clients on a single ethernet interface. If there are clients on more than one interface, you need more than one vblade instance. All this works surprisingly well. Yours sincerely, Roger Oberholtzer OPQ Systems / Ramböll RST Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 roger.oberholtzer@ramboll.se ________________________________________ Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden www.rambollrst.se -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Wed, 2011-11-09 at 14:23 +0100, Per Jessen wrote:

I recognise the setup, I have a fairly similar one, but for a number of storage servers. I serve the root filesystem via NFS though. (and I use iSCSI, not AoE).

The advantage of vblade is that the served file system is a single image on the host. No chance of file permissions in the image getting messed up. We package the image in an installable, and only need to worry about the image file. Makes life a bit easier. We could also do this via NFS. Yours sincerely, Roger Oberholtzer OPQ Systems / Ramböll RST Office: Int +46 10-615 60 20 Mobile: Int +46 70-815 1696 roger.oberholtzer@ramboll.se ________________________________________ Ramböll Sverige AB Krukmakargatan 21 P.O. Box 17009 SE-104 62 Stockholm, Sweden www.rambollrst.se -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org