|
On 02/01/2019 07:31, Michael Chapman
wrote:
A socket can trigger a service with a different name using Service=On Tue, 1 Jan 2019, Olaf van der Spek wrote:Hi, AFAIK socket units require a separate file, which seems more complex then it has to be. 1. Could sockets be specified directly in the .service file?If anything, I should think it would work the other way around: a .socket without any activatable .service is relatively useless. But I'm not proposing that this actually be implemented. moreover a service can be triggered by multiple sockets. It's a bit complicated to use (check Socket= in [Service]) but it can be handy if you want your web server to be started both by 80 and 8080 WantedBy is valid for all units, not just services and can have lots of proper values, not just2. If not, could the .service file gain a default / implicit dependency on the .socket file?There are a some reasons for not having a .service dependent upon its .socket. Many services can be started directly and will work correctly even when not passed any sockets from systemd.3. AFAIK Install.WantedBy doesn't have a default. Could it get a proper default? default.target. Lots of on demand daemons do not have a WantedBy at all. they have Also=<a trigger unit> That doesn't make much sense. Take your example:xhp.service: [Unit] Requires=xhp.socket [Install] WantedBy=default.target xhp.socket: [Socket] ListenStream=/run/xhp.socketThis would start xhp.service at daemon startup (i.e. boot, for the system daemon) whether or not the service is actually required. One of the reasons for using socket activation is to _not_ start services when they're not required. _______________________________________________ systemd-devel mailing list systemd-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/systemd-devel --
|
_______________________________________________ systemd-devel mailing list systemd-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/systemd-devel
