Tobias Mueller d4886a54a9 volatile-macs: define the service self-sufficiently ... This makes it hopefully a bit easier to see what we're doing because you don't need to chase the files down. We don't re-use that functionality anywhere. Neither would we. A more important change is not restarting the gl-tertf service. First of all, there seems to be no process attached to gl-tertf. It is the "Bandwidth Monitor" and part of the kmod-gl-sdk4-tertf package, so it's kernel module. It does not appear to be holding the clients.db. There is, however, gl_clients which also makes sense, naming wise. That service defines that /usr/bin/gl_clients_update ought to be run. And stracing it shows that it does indeed touch the database: open("/etc/oui-tertf/client.db", O_RDWR|O_CREAT|O_LARGEFILE|O_NOFOLLOW|O_CLOEXEC, 0644) = 7 It also appears to be re-creating the file when it's missing. Anyway, we have the service stopped during installation so that we can safely delete the file without the process complaining. We also install our volatile mac service s.t. it runs ahead of the gl-client service so that the clientdb gets saved in volatile memory.		2023-10-18 14:27:55 +02:00
..
config	Initial commit	2022-10-21 10:14:38 +02:00
gl-switch.d	switch: do not run the lock contention check in the background	2023-10-17 15:49:25 +02:00
init.d	volatile-macs: define the service self-sufficiently	2023-10-18 14:27:55 +02:00