blob: aaea86bd7c1a74bf3c0f96642b1e98424259e98a (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
|
## Name
SystemServer - one server to rule them all
## Description
SystemServer is the first userspace process to be started by the kernel on boot.
Its main responsibility is spawning all the other servers and other programs
that need to be autostarted (referred to as **services**).
A service can be configured to be *kept alive*, in which case SystemServer will
respawn it if it exits or crashes. A service may also be configured as *lazy*,
in which case SystemServer won't spawn it immediately, but only once a client
connects to its socket (see **Socket takeover** below).
## Socket takeover
SystemServer can be configured to set up a socket on behalf of a service
(typically, an *IPC portal* socket inside `/tmp/portal/`). SystemServer sets up
the configured sockets before spawning any services, preventing any races
between socket creation and the client trying to connect to those sockets.
When a service is spawned, SystemServer passes it an open file descriptor to the
configured socket as fd 3, and sets `SOCKET_TAKEOVER=1` in the environment to
inform the service that socket takeover is happening. SystemServer calls
[`listen`(2)](../man2/listen.md) on the file descriptor, so the service doesn't
need to do it again. The file descriptor does not have the `FD_CLOEXEC` flag set
on it.
The service is advised to set this flag using [`fcntl`(2)](../man2/fcntl.md) and
unset `SOCKET_TAKEOVER` from the environment in order not to confuse its
children.
LibCore provides `Core::LocalServer::take_over_from_system_server()` method that
performs the service side of the socket takeover automatically.
If a service is configured as *lazy*, SystemServer will actually listen on the
socket it sets up for the service, and only spawn the service once a client
tries to connect to the socket. The service should then start up and accept the
connection. This all happens transparently to the client. If a lazy service is
configured to be *kept alive*, it can even exit after some period of inactivity;
in this case SystemServer will respawn it again once there is a new connection
to its socket.
SystemServer can also be configured to accept connections on the socket and
spawn separate instances of the service for each accepted connection, passing
the accepted socket to the service process.
## See also
* [`SystemServer`(5)](../man5/SystemServer.md)
|
