Hi,
I am getting the below error when trying to update my view . Also, creds manager service is stopped and not getting started.
As long as the credmanager.exe is not started, none of the view (snapshot or dynamic) will work. So you need to debug that first.
Typically, you would check the ClearCase logs, and the Windows event, to see what the issue is. See "how to fix or investigate 'Operation “view_ws_is_ws_view” failed'?", using cleartool getlog.
That kind of error ("This application has failed to start becauselibatriaks.dllwas not found. Re-installing the application may fix this problem") was seen with rather old versions of ClearCase (7.0.1).
See for instance this thread.
If the DLL is present and the directory is in your path you should never
get this error.
Check to see how far ...\rational\clearcase\bin is down your SYSTEM path, and make sure the DLL's are in there.
ccgzip.exe will be called (by the client process) when checking in any files that fall back to the "compressed_file" element type. It may be called by the view server during file opens and checkouts to construct cleartext if needed. The former uses your user path, the latter will normally use the SYSTEM path.
We've seen odd behavior on Windows when the path gets >500 characters
long, though there seems to be no "official" limit to the length this environment variable (%PATH%) can grow to.
The error message you see is likely a path issue. Whether that's related to the other issue is unknown...
Is the albd server process running? The credential manager service is flagged to depend on this service. If that service fails to start, or terminates, the credential manager service will also fail.
A service startup failure should be in the Application or System Event logs. and from there the "Troubleshooting albd startup failures" technote on ibm.com would likely be a good place to start.
Related
I'm trying to handle all of User Interfaces (UI) dialogs in .msi installing pakage, with EmbeddedUIHandler to do this I have created a setupui.dll which contains three methods: InitializeEmbeddedUI, ShutdownEmbeddedUI, EmbeddedUIHandler, and put it inside of MsiEmbeddedUI table (using installshield) and it worked just fine.
The problem is when setupui.dll is dependent to other external DLLs, this time windows installer won't use my dll and it uses default ui, I have added other DLL dependencies with Installshield as follow:
I'm uncertain of what Windows Installer allows here. There are, however, three things that jump out at me as things to look into:
The MsiEmbeddedUI table's Attributes column should probably have a 3 for SetupUI.dll (as it does), and 0 for the rest. Per the docs, the 2 bit is ignored if the 1 bit isn't present, but all the other files are better described as "It may be a resource used by the user interface."
The verbose log: does it indicate what's going on? Does it show a failure loading SetupUI.dll that provides a useful error code (hint: file not found probably refers to a dependency)? Does it indicate it didn't even try to load your DLL? Look for lines with EEUI, at least in the successful case.
If Windows Installer does attempt to load SetupUI.dll, how far does it get? If it gets far enough for you to run some code and, say, show a message box, what files are already extracted at that point? If the dependencies are extracted, can you ensure that its directory is on the DLL path via SetDllDirectory or AddDllDirectory? If the dependencies are not extracted, are they present at a later point so approches like delay loading could help?
For the third point, Process Monitor may help you diagnose what's going on if you can't get a message box in there, but it will probably be less clear. Alternately, using Loader Snaps and Debug View might get you a related set of information, but it may be drowned in additional noise.
Is anyone aware of a known issue (and workaround) where it seems like Rational ClearCase will corrupt a Microsoft Project file if it is checked out and the network connection changes? I have a laptop that is docked and hardwired to local network most of the time, and I perform some work with the Project file, then I will undock the laptop to go to a meeting or home for the evening, and upon re-docking, the Project file can no longer be opened and appears corrupt.
The error message shown is "Project cannot open the file. -Check that the file name and path are correct. -Check that the file format is recognized by Project..."
There doesn't seem to be anything directly related to Microsoft Project Server regarding ClearCase on ibm.com.
I have seen issues with dynamic views, when the view server is on the network (and said network is abruptly cut).
If this is your case, I would recommend using snapshot views.
You can have similar issue with ClearTeam 8.x web views (since the latest versions support dynamic views)
Regarding snapshot views (meaning files directly on your hard drive), you only need to watch for concurrent processes that might still access your file when undocking. A program like procmon can help.
We've just updated Nagios from 3.5.x to the current version (4.0.7) and subsequently added a new host for monitoring.
The new host shows as 'Down' in Nagios, and this seems to be related to the fact that pnp4nagios is not logging performance data (the individual checks for users, http etc are all find).
Initially there was an error that the directory
/usr/local/pnp4nagios/var/perfdata/newhost.com
that contains the xml setup and rrd files for the new host was missing), so I manually created this directory, but now it complains that the files are missing.
Does anyone know the appropriate steps to overcome this issue?
Thanks,
Toby
PS I'd tag this 'pnp4nagios', but that tag doesn't exist and I can't create them
UPDATE
It's possible that pnp4nagios is a red herring/symptom. Looking more closely I realise that Nagios actually believes the host is down, even though all services are up. The host status information is '(Host check timed out after 30.01 seconds)'...does this make any more sense?
It's indeed very unlikely that pnp4nagios has something to do with your host being down. pnp actually exports output and performance data to feed the rrd database and xml files (via npcd module or evenhandler command).
The fact that nagios reports the host check timed out after 30 sec means that :
- you have a problem with your host check command, please double-check the syntax
- this check command times out after a certain timelapse (most likely defined in nagios.conf) because the plugin was still running.
I'd recommend running this command from the server's prompt. You want to do something like :
/path/to/libexec/check_command -H ipaddress -args
For example:
/usr/local/libexec/nagios/check_ping -H 192.168.1.1 -w 200,40% -c 500,80% -timeout 120
See if something might be hanging. Having the output would be helpful.
Once your host check returns correct output and performance data to nagios, pnp will hopefuly do the rest.
In the unlikely event it helps anyone, pnp4nagios was indeed a red herring. The problem was that ping wasn't enabled for the host being checked, and this is the test for whether a host is up or not. Hence this was failing, despite other services being reported as working.
Some of the windows services will start only after restarting the pc where as some start as soon as software is installed.
For example sql server(instance name) will start as soon as it is installed. Some other service requires restart.After restarting that computer it will start appearing in services.msc. Does it done by using registry? I got a link related to registry of services .But i am not able to track which one does it? Is it registry or something else?
(Setting service to manual or automatic is different,my question is about service added during the install of software for the first time)
You shouldn't be directly manipulating the registry to create a service. You should be using the service control manager API's to create and if desired start the service. The registry values are documented but they are still private to the API and only take effect upon reboot. Using the API will take affect immediately and the registry changes are done by the API.
If you are using Windows Installer you can let the installer handle all of this for you by using the Windows Installer's ServiceInstall and ServiceControl tables.
Some services have dependencies on resources that aren't available until after a reboot. One example might be a locked file that will be overwritten during startup via the Pending Files Rename Operations pattern. Another gotcha is if the service has a dependency on a system environment variable. After updating the registry to set the environment you are supposed to send a message to the broadcast address informing all processes on a settings change. Unfortunately the service control manager ignores these messages so it takes a reboot to catch up.
Other examples would be on a case by case basis.
I just moved my code from subversion to TFS.
When I get latest version, I understand that I can't get write permissions.
However, when I check out and choose the option to take the exclusive lock, a check mark appears next to my files and I am able to edit them.
When I look in Windows explorer, however, some files are still marked "read only."
This becomes a problem when I try and run my application. For some reason, not having write permissions to everything gives me an exception at the target of invocation message (its a wpf project).
When I run the files out of version control, everything is fine. When I run the version under TFS, I get that exception--even when I've exclusively checked the files out.
Any idea what is going on here?
Sounds like quite a bit of confusion here. So i have a number of questions:
Did you specifically check out the files that are still marked "read only"? Or did you just check out other files which may be related to the ones marked "read only".
Did you use the Source Control window or the Solution Explorer when performing the checkout command? Did you select specific files or just the top level project file?
Are the files actually part of the project? or are they simply in the same folder but still under source control?
What exact error message are you getting?
What files are the problem? In other words have you checked in the compiled binaries from the BIN or OBJ folders?
TFS terminology is a little different than SVN.
"Get" represents an update in SVN terms.
"Checkin" commits your changes and both "Checkin" and "Checkout" are responsible for managing file locks.
"Checkin" releases the locks.
"Checkout" requests the locks.
There are 3 types of locking you can use or none at all. I would opt for using None as it's likely to cause the least issues, many of which can be resolved during a merge and a little bit of communication.