A Windows service of type WIN32_SHARE_PROCESS (0x20) runs as a thread in a process which it shares with other services. (Although, in recent Windows 10 builds, it may get its own process anyway.) A Windows service of type WIN32_OWN_PROCESS (0x10) runs in its own isolated process. But, some Windows services have type wIN32_OWN_PROCESS | WIN32_SHARE_PROCESS (0x30). What does that combination mean?
sc query calls that combination WIN32. For example, sc query AppInfo reports:
SERVICE_NAME: AppInfo
TYPE : 30 WIN32
STATE : 4 RUNNING
(STOPPABLE, NOT_PAUSABLE, IGNORES_SHUTDOWN)
WIN32_EXIT_CODE : 0 (0x0)
SERVICE_EXIT_CODE : 0 (0x0)
CHECKPOINT : 0x0
WAIT_HINT : 0x0
The Windows API docs don't mention this possibility. They talk about what each flag means independently, but not in combination. They do reference 0x30 in the documentation of EnumServicesStatusA, but in the context of that function it is documented as returning services with either types set, it doesn't talk about what it means for a service to have both types set.
(The service type field can take several other values: driver services like SERVIC_KERNEL_DRIVER, the SERVICE_INTERACTIVE_PROCESS flag, user services, etc. I am not asking about any of those other values/flags in this question, only about the 0x30 combination.)
As you point out, changes to service host grouping in Windows 10 may result in services of type SERVICE_WIN32_SHARE_PROCESS running in their own, isolated process. Whenever that happens to a service, SC will show it as SERVICE_WIN32 -- the confusing union of SERVICE_WIN32_OWN_PROCESS and SERVICE_WIN32_SHARE_PROCESS.
We've confirmed this situation by playing with the registry.
On our Windows 10 VM (which has ample RAM to trigger the process isolation enhancements), SC says AppInfo is of type WIN32 (30):
Task Manager reported that AppInfo was running in its own process.
As per the documentation, we disabled process isolation for the AppInfo service by adding the SvcHostSplitDisable value:
And after a reboot, SC reported AppInfo of type WIN32_SHARE_PROCESS (20):
The Task Manager confirmed that the process was indeed shared.
So its all down to those changes to service process isolation in Windows 10 Creators Update (version 1703).
Related
I'm running a single ksqlDB Server on embedded mode on our Kubernetes cluster and I want to add a connector.
Adding a connector produces a Request timed out on Kafka Connect exactly similar to this blog post by Robin Moffatt.
So he suggests to change the KAFKA_OFFSET_REPLICATION_FACTOR contained in his docker-compose example.
But unfortunately in our Test environment, I don't have easy access to the existing Kafka cluster (we have admins there), so I think the fastest way to go about is to instead change the:
KSQL_CONNECT_CONFIG_STORAGE_TOPIC - change to a different topic name
KSQL_CONNECT_OFFSET_STORAGE_TOPIC
KSQL_CONNECT_STATUS_STORAGE_TOPIC
KSQL_CONNECT_CONFIG_STORAGE_REPLICATION_FACTOR to -1 (originally this value is 1)
KSQL_CONNECT_OFFSET_STORAGE_REPLICATION_FACTOR to -1 (originally this value is 1)
KSQL_CONNECT_STATUS_STORAGE_REPLICATION_FACTOR to -1 (originally this value is 1)
But when I change the topic names, I can see that new topics are created (using ksqlDB's SHOW TOPICS command), but it always shuts down and restarts forever, here are the logs:
[2021-07-22 01:27:19,889] INFO ProcessingLogConfig values:
ksql.logging.processing.rows.include = false
ksql.logging.processing.stream.auto.create = false
ksql.logging.processing.stream.name = KSQL_PROCESSING_LOG
ksql.logging.processing.topic.auto.create = false
ksql.logging.processing.topic.name =
ksql.logging.processing.topic.partitions = 1
ksql.logging.processing.topic.replication.factor = 1
(io.confluent.ksql.logging.processing.ProcessingLogConfig:372)
[2021-07-22 01:27:19,891] ERROR Aborting application start (io.confluent.ksql.rest.server.KsqlRestApplication:378)
io.confluent.ksql.rest.server.KsqlRestApplication$AbortApplicationStartException: Shutting down application during waitForPreconditions
at io.confluent.ksql.rest.server.KsqlRestApplication.waitForPreconditions(KsqlRestApplication.java:441)
at io.confluent.ksql.rest.server.KsqlRestApplication.startKsql(KsqlRestApplication.java:386)
at io.confluent.ksql.rest.server.KsqlRestApplication.startAsync(KsqlRestApplication.java:370)
at io.confluent.ksql.rest.server.MultiExecutable.doAction(MultiExecutable.java:68)
at io.confluent.ksql.rest.server.MultiExecutable.startAsync(MultiExecutable.java:42)
at io.confluent.ksql.rest.server.KsqlServerMain.tryStartApp(KsqlServerMain.java:89)
at io.confluent.ksql.rest.server.KsqlServerMain.main(KsqlServerMain.java:64)
[2021-07-22 01:27:19,892] INFO Server up and running (io.confluent.ksql.rest.server.KsqlServerMain:90)
[2021-07-22 01:27:19,892] INFO Server shutting down (io.confluent.ksql.rest.server.KsqlServerMain:96)
[2021-07-22 01:27:19,892] INFO ksqlDB shutdown called (io.confluent.ksql.rest.server.KsqlRestApplication:498)
[2021-07-22 01:27:34,926] INFO API server stopped (io.confluent.ksql.api.server.Server:196)
[2021-07-22 01:27:34,927] INFO ksqlDB shutdown complete (io.confluent.ksql.rest.server.KsqlRestApplication:553)
I don't have anymore details, it's just that.
When I return the config, offset and status topic names to what I had at first, the ksqlDB Server starts fine, but again I'm stuck with the problem that I can't create connectors.
I have a fear that when I attempt to delete the topics manually, ksqlDB server wont be able to start properly because it keeps on finding the original config, offset and status topics I had at first.
I have solved the issue, apparently using -1 as value for:
KSQL_CONNECT_CONFIG_REPLICATION_FACTOR
KSQL_CONNECT_OFFSET_REPLICATION_FACTOR
KSQL_CONNECT_STATUS_REPLICATION_FACTOR
doesn’t work properly, the Config topic becomes 20 partitions,
when I read in the Confluent Docs it should only be 1 partition, I think that’s why the ksqlDB Server just restarts endlessly, I just need to gather the right evidences.
Turning those values to 3 (which is our Kafka broker's default rep factor config) I think solved the issue, it was hard, because no error message/s are seen, like when it doesn’t want more than 1 partition of the created Config topic.
I am trying to master in UVM, and completely lost in UVM ports. Please help better understand the ports.
So as I understood there are 3 main types of ports
Put-> get : producer put data and consumer gets the data. This is blocking statement.
Put-> Export->Imp
Analysis->Subscriber : producer transmit the data and other subscribers gets it. This is non-blocking statement.
Also there are TLM_FIFOs which allows to buffer the transaction for later usage. It has 2 types: uvm_tlm_fifo and uvm_tlm_analysis_fifo.
And my questions are:
Is my understanding right?
What is the difference between get and export?
What is the difference between uvm_tlm_fifo and uvm_tlm_analysis_fifo?
Thanks
Hayk
The use of TLM interfaces isolates each component from changes in
other components throughout the environment.
For ports understanding, there are two common terminologies: Producer and Consumer. Instead of producer and consumer, think in terms of initiator and target of communication between components.
An initiator is always having a port connected to it. Just like driver has seq_item_port.
A target always have an export. Just like sequencer havng seq_item_export.
For Put/Get ports:
Initiator/Producer:
port.put(tr);
Target/Consumer: (Note the Input in task)
task pet(input simple_trans t);
//...
endtask
In put port, initiator is the producer which puts a transaction for the consumer. Initiator/Producer blocks till the put task is unblocked by Target/Consumer.
Initiator/Consumer:
port.get(tr);
Target/Producer:(Note the Output in task)
task get(output simple_trans t);
//...
endtask
While in get port, the initiator is the consumer. A consumer requests/asks for transaction and producer provides it. Initiator/Consumer blocks till the get task is unblocked by Target/Producer.
The put/get ports are typically used to have operational behavior of a system. These ports are used for one-to-one communication.
Analysis ports are generally used to broadcast the transaction. The write method is always non blocking. There may be zero or more connections to analysis ports. Again the rules for initiator and target remains the same.
Initiator:
port.write(tr);
Target:(Note the function, not task)
function void write(simple_trans tr);
//...
endfunction
All the ports requires implementation of methods in user's classes. The uvm_*_imp is used for the same. While buffering of data can be done through FIFOs.
For analysis ports, uvm_analysis_fifo is used, since these FIFO must have the ability to further broadcast the transaction. The default size of analysis FIFO is unbounded.
While uvm_tlm_fifo is used when put/get ports are used, that is, for one-to-one communication. The default size of analysis FIFO is 1, which can be changed to unbounded.
Again, FIFOs always puts/gets the data upon request from a component, henceforth there is an export type of connection at both the ends.
For further information, refer to UVM User Guide.
We have been trying to make use of the RabbitMQ Service Bus (v3.3.4) but the central bus keeps crashing. At the moment we are not using any clustering and its hosted on Windows Server 2008 R2. We'd like to isolate the root cause but the below error is the only one we can find. Can anyone shed some light on what; if anything; we can do to find the root cause of this?
Note: There are roughly 20 consumers with roughly the same number of Topic subscriptions. Also, all the clients are .NET 4.5 using the 3.3.4 Rabbit client libraries.
Version=1
EventType=APPCRASH
EventTime=130658038736577295
ReportType=2
Consent=1
ReportIdentifier=7f93ccd8-9cbe-11e4-ae00-000c29c08139
IntegratorReportIdentifier=7f93ccd7-9cbe-11e4-ae00-000c29c08139
Response.type=4
Sig[0].Name=Application Name
Sig[0].Value=erl.exe
Sig[1].Name=Application Version
Sig[1].Value=0.0.0.0
Sig[2].Name=Application Timestamp
Sig[2].Value=5343035d
Sig[3].Name=Fault Module Name
Sig[3].Value=MSVCR100.dll
Sig[4].Name=Fault Module Version
Sig[4].Value=10.0.30319.1
Sig[5].Name=Fault Module Timestamp
Sig[5].Value=4ba220dc
Sig[6].Name=Exception Code
Sig[6].Value=40000015
Sig[7].Name=Exception Offset
Sig[7].Value=00000000000760d9
DynamicSig[1].Name=OS Version
DynamicSig[1].Value=6.1.7600.2.0.0.272.7
DynamicSig[2].Name=Locale ID
DynamicSig[2].Value=1033
DynamicSig[22].Name=Additional Information 1
DynamicSig[22].Value=8d79
DynamicSig[23].Name=Additional Information 2
DynamicSig[23].Value=8d79a00078e92d9c3d5d79d4324254fe
DynamicSig[24].Name=Additional Information 3
DynamicSig[24].Value=9af5
DynamicSig[25].Name=Additional Information 4
DynamicSig[25].Value=9af5b20633c279dbf44b04a614c6a1f6
UI[2]=C:\Program Files\erl6.0\erts-6.0\bin\erl.exe
UI[5]=Check online for a solution (recommended)
UI[6]=Check for a solution later (recommended)
UI[7]=Close
UI[8]=erl.exe stopped working and was closed
UI[9]=A problem caused the application to stop working correctly. Windows will notify you if a solution is available.
UI[10]=&Close
LoadedModule[0]=C:\Program Files\erl6.0\erts-6.0\bin\erl.exe
LoadedModule[1]=C:\Windows\SYSTEM32\ntdll.dll
LoadedModule[2]=C:\Windows\system32\kernel32.dll
LoadedModule[3]=C:\Windows\system32\KERNELBASE.dll
LoadedModule[4]=C:\Windows\system32\MSVCR100.dll
LoadedModule[5]=C:\Program Files\erl6.0\erts-6.0\bin\erlexec.dll
LoadedModule[6]=C:\Windows\system32\USER32.dll
LoadedModule[7]=C:\Windows\system32\GDI32.dll
LoadedModule[8]=C:\Windows\system32\LPK.dll
LoadedModule[9]=C:\Windows\system32\USP10.dll
LoadedModule[10]=C:\Windows\system32\msvcrt.dll
LoadedModule[11]=C:\Windows\system32\IMM32.DLL
LoadedModule[12]=C:\Windows\system32\MSCTF.dll
LoadedModule[13]=C:\Windows\system32\apphelp.dll
LoadedModule[14]=C:\Program Files\erl6.0\erts-6.0\bin\beam.dll
LoadedModule[15]=C:\Windows\system32\ADVAPI32.dll
LoadedModule[16]=C:\Windows\SYSTEM32\sechost.dll
LoadedModule[17]=C:\Windows\system32\RPCRT4.dll
LoadedModule[18]=C:\Windows\WinSxS\amd64_microsoft.windows.common-controls_6595b64144ccf1df_6.0.7600.16661_none_fa62ad231704eab7\COMCTL32.dll
LoadedModule[19]=C:\Windows\system32\SHLWAPI.dll
LoadedModule[20]=C:\Windows\system32\COMDLG32.dll
LoadedModule[21]=C:\Windows\system32\SHELL32.dll
LoadedModule[22]=C:\Windows\system32\WS2_32.dll
LoadedModule[23]=C:\Windows\system32\NSI.dll
LoadedModule[24]=C:\Windows\system32\IPHLPAPI.DLL
LoadedModule[25]=C:\Windows\system32\WINNSI.DLL
LoadedModule[26]=C:\Windows\system32\mswsock.dll
LoadedModule[27]=C:\Windows\System32\wshtcpip.dll
LoadedModule[28]=C:\Windows\system32\NLAapi.dll
LoadedModule[29]=C:\Windows\system32\DNSAPI.dll
LoadedModule[30]=C:\Windows\System32\winrnr.dll
LoadedModule[31]=C:\Windows\system32\napinsp.dll
LoadedModule[32]=C:\Windows\System32\wship6.dll
FriendlyEventName=Stopped working
ConsentKey=APPCRASH
AppName=erl.exe
AppPath=C:\Program Files\erl6.0\erts-6.0\bin\erl.exe
I'd like to run a command that will give me the status of a specific windows service. Using sc query, I was able to get this information, see below.
C:\Windows\System32>sc query "IBM Cognos"
SERVICE_NAME: IBM Cognos
TYPE : 10 WIN32_OWN_PROCESS
STATE : 1 STOPPED
WIN32_EXIT_CODE : 1077 (0x435)
SERVICE_EXIT_CODE : 0 (0x0)
CHECKPOINT : 0x0
WAIT_HINT : 0x0
The only bit of information that I really need to access is the "STATE". Can I filter the output so I am only seeing the STATE or "1 STOPPED"? I was hoping I could do something like:
sc query[STATE] "IBM Cognos"
My ultimate goal is to run a .bat file that will output the status of a service to a file. I can then read that file from another program and use that value to determine whether I should display a green icon indicating "started" or a red icon indicating "stopped" to the user in the UI.
Thanks in advance for your help,
Jeff
How about:
sc query "IBM Cognos" | find "STATE"
Should return something like:
STATE : 1 STOPPED
I have an application distributed over 2 nodes. When I halt() the first node the failover works perfectly, but ( sometimes ? ) when I restart the first node the takeover fails and the application crashes since start_link returns already started.
SUPERVISOR REPORT <0.60.0> 2009-05-20 12:12:01
===============================================================================
Reporting supervisor {local,twitter_server_supervisor}
Child process
errorContext start_error
reason {already_started,<2415.62.0>}
pid undefined
name tag1
start_function {twitter_server,start_link,[]}
restart_type permanent
shutdown 10000
child_type worker
ok
My app
start(_Type, Args)->
twitter_server_supervisor:start_link( Args ).
stop( _State )->
ok.
My supervisor :
start_link( Args ) ->
supervisor:start_link( {local,?MODULE}, ?MODULE, Args ).
Both nodes are using the same sys.config file.
What am I not understanding about this process that the above should not work ?
It seems like your problem stem from twitter server supervisor trying to start one of its children. Since the error report complains about the child with start_function
{twitter_server,start_link,[]}
And since you are not showing that code, I can only guess that it is trying to register a name for itself, but there is already a process registered with that name.
Even more guessing, the reason shows a Pid, the Pid that has the name that we tried to grab for ourself:
{already_started,<2415.62.0>}
The Pid there has a non-zero initial integer, if it was zero it means it is a local process. From which I deduce that you are trying to register a global name, and you are connected to another node where there is already a process globally registered by that name.