My role have two handlers: start service and restart service. I want to run start service only if service was installed, and I want to restart service if I changed service configuration file.
(That were normal ansible handlers, now complicated part starts)
I want to avoid doing restart if I start application (started handler was executed).
Basically, if:
1. package was installed
2. config was changed
=> start service
if:
1. package wasn't changed
2. config was changed
=> restart service
I tried to play with listen, but it's designed for different purposes and can't help here.
Can someone give me an idea who to do this?
Related
I'm targeting ubuntu 22.04
I know how to use cloud-init to do simple stuff like runcmd and add user using users in the yaml.
I have two scripts that I like to be triggered via systemd
before-shutdown-script.sh : this script is to be triggered before the server is shutdown or before the server goes into reboot. The script's job is to call a webhook so network must at least be working before the script is activated. The webhook is simply to tell a centralized place, hey this server is powering down.
upon-bootup-script.sh : this script is to be triggered when the server is booted up. The script's job is to call a webhook so network must at least be working before the script is activated. The webhook is simply to tell a centralized place, hey this server has just booted up.
I am not confident of how to use systemd and how to use cloud-init to configure this. How should I script the cloud-init yaml?
Ansible handler is given a task to start a particular service. What will Ansible handler do if the service is already started when it is called?
That depends on what module and what definition you are using to restart the service. Typically (such with the service module) when a service is already started and you specify state: started, then nothing happens.
In handlers, you typically want to use state: restarted, which will make sure a service is restarted when the handler runs.
Services are being managed using an NSIS installer. On uninstallation those services are stopped using net stop, because it is synchronous, then flagged for deletion using sc delete, as they do not have to be deleted immediately/synchronously.
Now I am wondering about the installation process. The order of calls is such:
net stop service1
net stop service2
sc config service1 depend=dependency1
sc config service2 depend=dependency2
sc start service1
sc start service2
Is there an intrinsic order to queries passed to sc? Are they worked through in the order sc is called (I assume they are not)? Are they being delegated to the respective service and queued there (this is what I hope for), e.g. whether service1 or service2 is stopped and configured first is ambiguous, but the sc config, sc start order is not? Is the order entirely ambiguous?
In addition I am curious to know what happens when mixing net and sc calls. Assume the following order:
net stop service
sc config service
net start service
Is it reasonable to assume that the service would likely be stopped, then started before any configuration occurred?
Supposedly the general question is, how to ensure proper service setup via concatenated sc/net calls. The required order:
Stop service (it may or may not exist on system)
Create service / conffigure service
Start service
Uninstallation is less pressing, because stopping services and flagging them for deletion is sufficient.
Mixing sc and net calls should not be a problem because it is the SCM (Service Control Manager) process that controls the services, other applications simply asks the SCM to perform a specific operation.
The documentation for the ChangeServiceConfig API function states that:
If the configuration is changed for a service that is running, with the exception of lpDisplayName, the changes do not take effect until the service is stopped.
This leads me to believe that a installer can use the following sequence:
Install/Configure --> Stop (synchronous) --> Start.
Performing "Stop --> Configure --> Start" is always going to have a race condition issue because another process might trigger a service start at the wrong time.
I have a sysv style init file for a service being used in centos 7.1
When the system boot up, the systemd generates a service file and it
seems to be enabled for both level 2 and level 3.
I have following questions:
1) Can the service be started twice at each run level ? [How can I prevent
it if it can start]
2) How can I check at which run-level the currently executing service
was started on ?
Thanks
Arvind
This depends on your service. If your service is an active service then starting it will not do anything. You can find if your service is an active service or not by running "systemctl status yourservice.service". In case your service is not active, you can tell systemd to treat it as an active service even after it quits. The directive for this is RemainAfterExit= (https://www.freedesktop.org/software/systemd/man/systemd.service.html#RemainAfterExit=).
To find out which run level your service has been started by you need to look at the "systemctl show yourservice.service" output. Look at what is listed on WantedBy= or RequiredBy= fields.
I am having trouble when I have one Windows service try to install another Windows service.
Specifically, I have a TeamCity agent running tests for me on a Windows 2008 AWS instance. The tests are written in Java, which shell out to a .bat script to install a service (let's call it Service A), giving it a unique name each time.
The offending line is in the .bat script: sc create "%serviceName%" binPath= %binPath% DisplayName= "%serviceDisplayName:"=%" start= %serviceStartType%. I believe as long as the service name is unique that should work.
And indeed it does work if I run the tests manually on the command line, using an administrator account. Service A is installed, the test completes and Service A is uninstalled at the end.
I have tried running the TeamCity agent as LocalSystem, as Administrator, and as another user that is member of the administrators group. I have also tried disabling UAC completely.
Presumably the problem is access denied type errors, although that is not clear at this point. There are a few avenues to explore still, but it is a simple question really: are processes running as services forbidden from installing other services? Are there special things I have to do to configure the machine/ account to allow it to do this?
The point of the test it to install and use Service A, so workarounds are not relevant - Service A must be operated as a black box.
Thanks!
There are no restrictions on creating services with regards to how the creating process can execute, as long as the process has the appropriate permissions. That is to say, a process could be running as a service and create another service -- the only consideration here is the appropriate permission level.
The problem that often occurs with running batch scripts from within processes (as opposed to directly through user input on the command line) is that the environment expected isn't always the environment that is loaded. In this case, it appears that the env variables referred to in the batch script weren't properly set when running as a service, which of course then caused the service install failure. Correcting the environment loaded when the batch script is shelled out is the correct solution here.