On 2022-06-02, Mike Fischer <fischer+o...@lavielle.com> wrote: > I think the issue is more general. It applies whenever multiple > instances of any service are needed. > > I have a similar issue with php_fpm which I am using in multiple PHP > versions and with different settings (chroot(2) for httpd(8) or without > chroot(2) for Apache httpd).
With php-fpm it's a bit awkward to handle, because it doesn't include all the flags in the process name, but just the config filename, so the rc.d script would need to parse the flags itself, it's possible but it makes things more complex/fragile. However there is no problem running instances of different versions of php-fpm, and the usual way to handle different settings within a version is to use different config blocks with a single main process, so there doesn't seem to be much advantage to running separate main processes with the same PHP version - e.g. $ cat /etc/php-fpm.conf [global] error_log = syslog syslog.facility = daemon log_level = notice [www] user = www group = www listen = /var/www/run/php-fpm.sock listen.owner = www listen.group = www listen.mode = 0660 pm = ondemand pm.max_children = 20 pm.process_idle_timeout = 30s chroot = /var/www [librenms] user = _librenms group = _librenms listen = /var/www/run/php-fpm-lnms.sock listen.owner = www listen.group = www listen.mode = 0660 pm = ondemand pm.max_children = 30 pm.process_idle_timeout = 30s env[TMP] = /var/www/librenms/tmp env[TMPDIR] = /var/www/librenms/tmp ; no chroot for librenms (You can also use "include" files if you want to split up the config rather than having one big file for complex setups). ...so I'd prefer to keep php-fpm like it is, unless I'm missing some big benefit of running multiple main processes of the same version. (Big benefit of running a single version is that you don't need to restart each daemon separately after updates). > I some cases the fix may be a more specific pexp. However this > depends, as you have noted, on what parameters the executable is called > with and whether they are sufficient to differentiate between the > running service instances. > > In general running multiple instances of the same service does not > seem to be supported out of the box by OpenBSD and specifically by the > rc(8) infrastructure. It can be made to work in some cases but it feels > kind of like a hack. I think the general case is that this *does* work, but there are some cases where software resets the process name in an annoying way that prevents it. I admit copying or symlinking the rc.d files is a bit hackish, especially for daemons from base (because you need to start the copoes from pkg_scripts) but OTOH it's simple and works well enough. >> These changes are only needed for when someone needs to run more than >> one instance of pflogd, in which case they will have to copy the >> default /etc/rc.d/pflogd and/or modify it anyways (e.g. for the interface >> name in rc_pre). > > Right! So the choices are: > 1) Leave /etc/rc.d/<service> as is, and only run modified duplicates. > 2) Modify /etc/rc.d/<service> to ensure a unique pexp when dealing > with multiple instances, but you still need to create modified > duplicates for the additional instances. > > My choice would be (1). It does not change the things installed by > the base system or from packages. Whenever something is updated, manual > checks and potentially adjustments may be required anyway. Seems a bit > cleaner that way. Less dependencies on the defaults. I haven't looked closely at tbe rc.d/pflogd change yet but will do so later. There's another case, where somebody runs two copies of pflogd, one from the default rc.d script, one standalone by running pflogd directly. So, it probably would be helpful if the dedault rc.d script was more targetted.
