I'm keeping the "Log On As" info on upgrade for the service I'm installing.
<InstallServices>NOT WIX_UPGRADE_DETECTED</InstallServices>
<DeleteServices>NOT UPGRADINGPRODUCTCODE</DeleteServices>
However, the upgrade fails if the user/password are incorrect.
How can I allow my service to fail to start?
I'm able to do this by adding
<ServicesStart>0<ServicesStart>
and using a custom action to start the services. Although it works, I don't quite like it.
The custom action simply runs a batch file with the following line:
net start FoobarService
I use quiet execution in the MSI, but running this batch file from the command line I have the following output:
System error 1069 has occurred.
The service did not start due to a log-on failure.
That's the expected behavior - the upgrade must proceed even if the service fails to start. If the service doesn't start, someone will notice it very quickly and will change the credentials.
Related
I accidentally screwed up my darktable configuration, so I reloaded it from scratch. To avoid losing all my recorded changes I have done to my pictures, I wrote a powershell backup script for the darktable database. I want to launch this script from the windows task scheduler when ever I launch darktable. I have found the event id which indicates in the security log of a new process has occurred which I should be able to use to automatically launch my backup script from task scheduler. I want to add code to the script to check the services to see if darktable is actually running and only perform the backup if it is. Anyone know how I can identify this?
I am trying to publish an upgrade of a Service Fabric application from Visual Studio 2017 to our Azure Service Fabric Cluster. In mid-September, I successfully published an upgrade of this same app with same PowerShell script to SFC with no issues. I am now trying to upgrade it at the next version number and suddenly getting this error.
I get the following error during Publish, related to Powershell.
2>Started executing script 'Deploy-FabricApplication.ps1'.
2>powershell -NonInteractive -NoProfile -WindowStyle Hidden -ExecutionPolicy Bypass -Command ". 'C:\Users\pj\Source\Workspaces\VDevelopment\trunk\Services\Sources\src\For.Application.ServiceFabric.Sources\Scripts\Deploy-FabricApplication.ps1' -ApplicationPackagePath 'C:\Users\pj\Source\Workspaces\VDevelopment\trunk\Services\Sources\src\For.Application.ServiceFabric.Sources\pkg\Debug' -PublishProfileFile 'C:\Users\pj\Source\Workspaces\VDevelopment\trunk\Services\Sources\src\For.Application.ServiceFabric.Sources\PublishProfiles\Cloud.xml' -DeployOnly:$false -ApplicationParameter:#{} -UnregisterUnusedApplicationVersionsAfterUpgrade $false -OverrideUpgradeBehavior 'None' -OverwriteBehavior 'SameAppTypeAndVersion' -SkipPackageValidation:$false -ErrorAction Stop"
2>Copying application package to image store...
2>Upload to Image Store succeeded
2>Registering application type...
2>Register application type started. Use Get-ServiceFabricApplicationType to query for status.
2>Running Image Builder process ...
2>Application package is registered.
2>Start upgrading application...
2>aka.ms/upgrade-defaultservices
2>Start-ServiceFabricApplicationUpgrade : aka.ms/upgrade-defaultservices
2>At C:\Program Files\Microsoft SDKs\Service
2>Fabric\Tools\PSModule\ServiceFabricSDK\Publish-UpgradedServiceFabricApplication.ps1:317 char:13
2>+ Start-ServiceFabricApplicationUpgrade #UpgradeParameters
2>+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2> + CategoryInfo : InvalidOperation: (Microsoft.Servi...usterConnection:ClusterConnection) [Start-ServiceFa
2> bricApplicationUpgrade], FabricException
2> + FullyQualifiedErrorId : UpgradeApplicationErrorId,Microsoft.ServiceFabric.Powershell.StartApplicationUpgrade
2>
2>Finished executing script 'Deploy-FabricApplication.ps1'.
2>Time elapsed: 00:07:39.0407526
2>The PowerShell script failed to execute.
========== Build: 1 succeeded, 0 failed, 10 up-to-date, 0 skipped ==========
========== Publish: 0 succeeded, 1 failed, 0 skipped ==========
Any idea what's going on here? Again, when I last published this in September, with the same script, no issues at all, and I haven't made any changes to the solution other than upgrading the Manifest versions to push it out as a new upgraded version.
I noted this S/O thread: Getting error as part of trying to upgrade Service Fabric Application using Start-ServiceFabricApplicationUpgrade and saw the user's error was similar, but the answer does not apply to my issue because all three steps in the answer provided are definitely included in my powershell deploy script.
I can add the deployment script if helpful, but will wait until that is requested as it's long, and I only want to post it here if someone feels it's needed to diagnose.
You are getting this error because you are changing some parameters in a DefaultService that are not allowed by default.
The link aka.ms/upgrade-defaultservices shown in the error logs explain this.
Some default service parameters defined in the application manifest
can also be upgraded as part of an application upgrade.
Only the service parameters that support being changed through
Update-ServiceFabricService can be changed as part of an upgrade. The
behavior of changing default services during application upgrade is as
follows:
Default services in the new application manifest that do not already exist in the cluster are created.
Default services that exist in both the previous and new application manifests are updated. The parameters of the default
service in the new application manifest overwrite the parameters of
the existing service. The application upgrade will rollback
automatically if updating a default service fails.
Default services that do not exist in the new application manifest are deleted if they exist in the cluster. Note that deleting a default
service will result in deleting all that service's state and cannot be
undone.
Also, there is this other SO question about the same thing: Default service descriptions can not be modified as part of upgrade set EnableDefaultServicesUpgrade to true
The item 1 above is a common approach, where new services are added to the solution and later created during the upgrade without errors, the item 2 and 3 are the restricted approach that requires the EnableDefaultServicesUpgrade.
The item 2, is like described in the answer you've added, you changed MinReplicaSize and TargetReplicaSize to 1 during a manual update, when SF validated the state of your service for upgrade, it identified the difference and prevented the upgrade to continue, if you had set cluster setting EnableDefaultServicesUpgrade to true it would continue and override the default values.
The item 3, would occur you when you removed the service and added again, you had changed or misspelled the name, SF default settings would prevent the deletion of this service.
Regarding the solution you've found(delete and recreate), is not ideal,
In scenarios where you have stateful services running in production, would be risky to apply, because you would have to backup the state, re-deploy the services, and restore the backup, in some cases, depending on what these changes are, you wouldn't be able to restore the backup, because they have to match with the original services definitions (partitions type, number, and son on). You would also lose the benefits of Rolling Updates, and your service would go down maybe for a while if these backups are big.
The issue had to do with us trying to push out the application with mismatched node instances. We have a stateful service running under this application that is supposed to have MinReplicaSize and TargetReplicaSize set to 3. Yesterday, due to an issue, we deleted and re-created this service inside the SF Explorer. Upon doing so, it reset the replica size parameters back to 1. So we used a Powershell script to change them back to 3, but that script did not include all the necessary commands to get the service back to the exact state it was in before we deleted it. So today when we went to upgrade the app, the app in SFC wouldn't accept an upgrade from VS deployment, because of mismatches between what was in the parameters of the solution vs. what was in our SFC. To resolve, we re-deleted those services first, then deployed from VS, and no more error.
In Informatica we have mapping source qualifiers connecting to Amazon Web Services—AWS.
We often and erratically get a failure that our s3 bucket names do not comply with naming standards. We restart the workflows again and they continue on every time successfully.
Is there a way to trap for this specifically and then maybe call a command object to restart the workflow command via PMCMD?
How are you starting the workflows in regular runs?
If you are using a shell script, you can add a logic to restart if you see a particular error. I have created a script a while ago to restart workflows for a particular error.
In a nut shell it works like this
start workflow (with pmcmd)
#in case of an error
check repository db and get the error
if the error is specific to s3 bucket name
restart the workflow
Well... It's possible for example to have workflow one (W1):
your_session --> cmd_touch_file_if_session_failed
and another workflow (W2), running continuously:
event_wait_for_W1_file --> pmcmd_restart_W1 --> delete_watch_file
Although it would be a lot better to nail down the cause for your failures and get it resolved.
I have create a small script file to test.
This my script.bat file.
sc create myService binpath= C:\Users\Admin\Desktop\test.bat start= auto
This is my test.bat file.
echo "Welcome to Wizard"
Problem Statement
I am unable to start the service from control panel Service section.
I get following error.
[SC] StartService FAILED 1053:
The service did not respond to the start or control request in a timely fashion.
That is why I am using nssm.
NOW what happening is that when I run following command on powershell
.\nssm install myService, I dialogue box appears. I give it the path of my script file and click on install service.
After successfull installation of service. I go to control panel -> Service -> click on start against myService but it get paused and following dialog box appears
How can I fix this?
Is there anyother way to do it without doing manual steps and not using third party tool.
I am doing all this on window 10. Do I need any server to perform this task?
NOTE: I cannot use Always up or window scheduler in my case.
The NSSM behaviour is caused by the script terminating almost instantly. Try the following script:
echo Hello World
pause
This should allow the service to start, but you will not necessarily see a console window. Even if you tick 'allow service to interact with desktop', it will not be your desktop that it interacts with!
Windows implements 'session zero isolation' as a security feature, and this essentially prevents services interacting with end user desktops.
In terms of a solution, it's possible to write Windows 'service' applications fairly simply using Visual Studio. It's outside my area of expertise, but based on the Windows applications I'm familiar with, you would generally have a user-mode application running to provide desktop interaction. The user-mode application can interact with services hosted by the service application.
Probably this is resolved by now, but in case it helps anyone, what saved the day for me was checking again my input in the arguments field in nssm. I had an extra "-" which created the error. To edit my service, I went via nssm edit <servicename>
I would also add on the fix that worked for me. I added "" (quotes) in the argument path and that solved the issue for me.
I have a service MyService.exe that is babysitting my application MyApp.exe, meaning it starts the application when this one crashes or whatever. Basically when the service is stopped the application is stopped (by the service) and when the service is started the application is started by the service.
In order to stop my service and by that my application when uninstalling I'm doing:
<ServiceControl Id='MyServiceControl' Name='MyServiceForTest' Start='install' Stop='uninstall' Remove='uninstall'/>
But when I want to uninstall everything I get the error message: "The setup must update files or services that cannot be updated while the system is running. If you choose to continue, a reboot will be required to complete the setup.". If I manually stop the service before running the uninstaller I don't get this msg as both my service and my application aren't then running anymore.
In the log file I noticed that this happens in InstallValidate and I get this message b/c of MyApp.exe being running.
I think what happens is: the uninstallers checks the running applications, it notices that the MyService.exe and MyApp.exe are both running, detects probably that the MyService.exe will be stopped by the uninstaller itself as instructed, but doesn't know about the MyApp.exe that this one will also be terminated once the service will be stopped so it will show the reboot-message.
I can't just close MyApp.exe from uninstaller b/c the service will restart it again.
How could I solve this problem so that the user won't need to reboot or to manually stop the service before doing an uninstall/upgrade? Also, I can't change MyService and MyApp code anymore so I will have to do this from the (un)installer only.
TIA,
Viv
I would expose a mechanism in your service in which your installer can instruct it to stand down and terminate the application. This way when Windows Installer costing looks for locked files it doesn't find any.