Service socklog-unix locks users out of the system if /var/log/socklog does not exist

[abhocetabhac]

Is this a new report?

Yes

System Info

Void 6.12.10_1 x86_64-musl

Package(s) Affected

socklog-void-20200115_2

Does a report exist for this bug with the project's home (upstream) and/or another distro?

No response

Expected behaviour

If the directories /var/log/socklog and /var/log/socklog/* do not exist, they should be automatically recreated by the shell script /etc/sv/socklog-unix/run before starting the socklog executable.

Actual behaviour

If the directories /var/log/socklog and /var/log/socklog/* do not exist when the socklog-unix service starts, it leads to unexpected behavior where all login attempts, including sudo and su, stall indefinitely. This effectively locks users out of the system, rendering it inaccessible for any user interaction. The socklog-unix service seems to depend on the existence of its log directories for normal operation. Without them, processes like login, which need to log activities, hang waiting for the log to be written. This isn't just a minor inconvenience but a critical system access issue, as no user can log in to fix the problem without rebooting into single-user mode or using a live USB to manually disable the service.

Additionally, 'xbps-reconfigure -f socklog-void' fails to recreate the subdirectories of /var/log/socklog. The package must be removed and reinstalled. The socklog-conf executable also seems to fail.

This issue prohibits the use of socklog on systems that, for example, mount a tmpfs on /var/log, like home PCs.

Steps to reproduce

1. sudo rm -r /var/log/socklog
2. sudo ln -sf /etc/sv/socklog-unix $MNT/etc/runit/runsvdir/default/socklog-unix
3. su

[dkwo]

It is xbps-install -f socklog-void that you should run, and it should recreate the directory.
I agree we could add a check somewhere in the service for the existence of dir /var/log/socklog.