This is what I've learned so far while experimenting with multiple coLinux services running at the same time.
- 1 Caveats
- 2 Procedure
- 2.1 Prepare Multiple Images and Configurations
- 2.2 Register Services
- 2.3 Before Starting Services, Modify Dependancies
- 2.4 Start Each Service
- 2.5 Start Individual Consoles
- 2.6 Stop Each Service
- 2.7 Un-Register Each Service
- 2.8 An alternative method
- 2.9 Multiple TAPs
- 2.10 ColinuxAdminTools
- Back-up your registry, we are going to modify it a bit.
- Have backups of your images when testing things -- this is a pre-caution I added prior to my own testing of service mode. I can report that even after some rigorous tests, I have not had problems that required recovery. Of course, YMMV.
- There are currently issues auto-starting multiple colinux services (and perhaps instances) at boot/login. We're looking into a solution for it (when we get the time). It's recommended that you manually start or only autostart 1 service/instance at boot time. Another UGLY work-around is to make them depend on each other, so they'll start in a specific order, although that's not necessarily a 100% solution.
- Win2k SP4, 1 Via Rhine 10/100 Adapter, 1024 MB RAM
- Network adapter bridged with WinPCap 3.1 Beta
- The 20040509 coLinux snapshot was used. The service support in this version fixes issues that were previously experienced with running coLinux as a service.
This may very well work with the TAP driver or with native XP bridging -- please report your experiences.
- Additional Note: gboutwell - Talked with Dan, he said he's had multiple TAPs working before. I still haven't been able to get multiple TAPs work. Please contact me if you have, I'm very interested in getting them working.
- addendum: boots - I have previously asked da-x (on IRC) about running multiple TAPs and to the best of my recollection, he was not using service mode to do so.
- Note about multiple TAP devices:
- I got them working after some testing. Since no real documentation could be found...
- First you have to manually install a second TAP device with the Windows Device Manager or the CLM Tool. Once installed, rename the TAP devices to make them better distinguishable. Now you can allocate the TAP devices to their coLinux Session/Service via the config File.
- Example XML-Config Line:
- The clm tool attempts to automate all of the steps discussed here (as well as a few others) as it was initially written while testing service mode features.
- Watch the taskmanager for dangling processes (eg. colinux-bridged-net-daemon.exe)
- When starting the daemon manually from a CMD prompt (not as a service), you may want to try using *start* which will spawn the daemon in a new process. This is handy to keep all of the output from different daemon's in their own command windows eg:
start c:\colinux\colinux-daemon.exe "@c:\colinux\colinux.conf" -t fltk
IMPORTANT: Do not attempt to open the same configuration in multiple running instances!
- Create multiple images to boot from, each should be completely independant and share no *<block_device>* paths (for example, they should each have separate swap files).
- For each individual image, create a *<image>.colinux.conf* that corresponds to each one. I'm using the bridge network, so I have a different unique MAC attribute for each one.
- If you are going to try to run the services concurrently, then naturally, each Linux image should have a unique IP & unique MAC.
Controlling the colinux-daemon
You use the colinux-daemon.exe to control your colinux process and register coLinux Windows services. Use *c:\colinux\colinux-daemon.exe -h* for help. The following briefly describes the parameters that will be used.
- *-t <type>* specifies the console type to spawn where either fltk or nt is acceptable.
- This is only useful when running an instance of the colinux-daemon and is not used for services. In fact, when registering a service, this will be ignored and the *-d* option (no console spawning) will be automatically used instead.
- *@<path_to_conf_file>* indicates the configuration file to be used. This is required as of 20040509.
- *--install-service "<service name>"* indicates the name that will be registered under Windows Services. (tips on service names: if the service name contains no spaces, then the quotes are not required when refering to them; Windows treats service names as case-insensitive)
Use the colinux-daemon to Register Your coLinux Services
Assuming that you have the coLinux 20040509 snapshot or newer installed in c:\colinux\ and that it contains two unique config definitions (eg: server1.colinux.conf and server2.colinux.conf):
cd c:\colinux colinux-daemon.exe @server1.colinux.conf -p server1.pid --install-service "coLinux Server1" colinux-daemon.exe @server2.colinux.conf -p server2.pid --install-service "coLinux Server2"
For my tests, coLinux Server1 is a Gentoo-i686 image given 386 MB RAM and a 768 MB swap device while coLinux Server2 is a Slackware image given 128 MB RAM and a different 768 MB swap device.
coLinux version 0.7.5 will set dependancy automatically - you can skip this section here.
- Using regedit (regedt32 is a little easier as you will need to modify a REG_MULTI_SZ type value), go to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\<ServiceName>, and modify the key Depend On Service. Leave CoLinuxDriver there, but add either NPF (if using PCAP) or TAP (if using TAP-Win32) to it (or both, if required by your configuration). You will of course need the necessary network driver software already installed, or the service will fail to start. Not doing this means that if you do get your service to start and you haven't run colinux-daemon.exe manually, you will not get networking to work in your service (in other words, your service won't get networking when autostarting at boot time unless you do this step nor will it get networking until you manually run the daemon in non-service mode).
NOTE: The clm tool attempts to automate this procedure by applying the appropriate patch for you.
NOTE: The more recent version of the TAP driver, the dependancy should be 'tap0801co'. This is tested with 0.6.2 under Windows 2000.
ie: replace TAP as tap0801co
You can use the sc tool to query and set the service options and dependencies, instead of editing the registry (which gave me some errors)
A couple of caveats while using sc -
- Make sure there is no space in the name of your service when creating it with colinux-daemon.exe --install-service. Use a name like CoLinuxUnixFlavour instead of "Colinux Unix Flavour". While querying or modifying the service spaces seem to throw the tool off.
- To update the dependencies use
sc config CoLinuxUnixFlavour depend= "CoLinuxDriver/NPF/tap0801co"
- Note the lack of space between depend and =, as well as the space between = and the value in string. It does not work if the spacing is off.
net start "Colinux Server1" net start "Colinux Server2"
NOTE: If the service cannot be started make sure the permissions on the coLinux install dir allow the "Local Service" user to read the configuration file. Running "chmod +r *" inside the directory using Cygwin fixed it for me.
We can attach a console (fltk or nt) to a particular running instance using the *-p pidfile* parameter of the console program. Per default console will attach the first instance of coLinux increments. Thus, startup order of the services is important to know. Note too, that if you stop service '0', but leave '1' running, then the next service you start will take the '0' slot before the '2' slot is taken. You can mix and match which console types you use at your own whim.
In this example, the first console would attatch the service that was started first, Colinux Server1, while the second console attaches to the second console started, Colinux Server2.
cd c:\colinux start colinux-console-nt -p server1.pid start colinux-console-fltk -p server2.pid
Using start causes the console to spawn the console using a new process instead of from within the current CMD prompt process.
NOTE: The clm tool automates common procedures such as starting consoles.
- Even if you can't get both working at the same time, each should work "stand-alone".
- Only one console can be attatched to a given service at any time. (But the consoles can still provide virtual terminals, as usual).
You can stop each service by issuing *poweroff* or *shutdown* from within the consoles. You can also send ctrl-alt-del from the Monitor menu of the fltk console and in an emergency, use Terminate in the Monitor menu. Of course, you can use the standard Windows service controls:
net stop "Colinux Server1" net stop "Colinux Server2"
While you needn't unregister services when not in use, you may want to remove some (or all) of them after you are done testing:
cd c:\colinux colinux-daemon.exe --remove-service "coLinux Server1" colinux-daemon.exe --remove-service "coLinux Server2"
I didn't find this wiki page until after I had already successfully set up coLinux as a service following a recipe from another page. It seems a simpler way to do it. Here are the steps:
- Install cygrunsrv from the cygwin install/setup program. It's located under "Admin".
- Execute this under cygwin:
$ cygrunsrv.exe -I "colinux" -p "/cygdrive/c/progra~1/colinux/colinux-daemon.exe" -a "-d" -t "manual" -c "/cygdrive/c/progra~1/colinux/" -d "colinux" -f "colinux as a service" --shutdown
- Go into Services control panel and set colinux to "Automatic".
Tested under 0.6.1 -- GrahamToal
-- note: AFAIK (boots) cygrunsrv is a general wrapper that allows most any process to be setup as a service. Unfortunately, one difference is that when you shutdown the cygrunsrv spawned coLinux service, it does not send appropriate terminate signals to the co Linux kernel. The method outlined on this page seems complicated, probably because it was written while the service mode was still experimental, so it was done rather verbose to document issues that were current at the time. Again, the clm tool makes installing a service as easy as "clm install service_name"
-- True enough that it doesn't get the shutdown, even if you stop the service manually. I'm not 100% sure though that it is not being sent some sort of shutdown request, it may just not be one that it understands. Is anyone looking at how windows issues a service stop request so it can be translated it into a "shutdown -h now"?
Use cygrunsrv --shutdown
Actually its not critical because ReiserFS recovers from non-graceful shutdowns pretty nicely. I've not had any problems caused by this yet. -- This is of course also possible for the bridge-net driver:
$ cygrunsrv -I CoLinuxNetBridge -p /d/coLinux/colinux-bridged-net-daemon.exe -d /d/co Linux -a "-i 0 -c 0 -mac 00:43:4F:4E:45:30" -y coLinux --shutdown
coLinux depends on CoLinuxDriver and NFP then.
Install a new TAP as a new hardware (add-hardware wizard on windowsXP). Then give it a name, lets say TAP2. Then in the corresponding configuration file edit the network line by adding "name" attribute and set it to "TAP2".
Some tools that are useful for controlling and maintaining services and coLinux.
Good Luck and Have Fun!
MassTranslated on 25 Dec 2004.
MassTranslated on Sun Apr 23 17:36:46 UTC 2006