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

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

[abhocetabhac]

[-- Attachment #1: Type: text/plain, Size: 1795 bytes --]

New issue by abhocetabhac on void-packages repository

https://github.com/void-linux/void-packages/issues/54043

Description:
### 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

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

[dkwo]

[-- Attachment #1: Type: text/plain, Size: 335 bytes --]

New comment by dkwo on void-packages repository

https://github.com/void-linux/void-packages/issues/54043#issuecomment-2607760518

Comment:
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`.

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

[vincele]

[-- Attachment #1: Type: text/plain, Size: 223 bytes --]

New comment by vincele on void-packages repository

https://github.com/void-linux/void-packages/issues/54043#issuecomment-2845117258

Comment:
@dkwo why not just create the directory if not present ?
like in the PR above ?

Re: [ISSUE] [CLOSED] Service socklog-unix locks users out of the system if /var/log/socklog does not exist

[ahesford]

[-- Attachment #1: Type: text/plain, Size: 1798 bytes --]

Closed issue by abhocetabhac on void-packages repository

https://github.com/void-linux/void-packages/issues/54043

Description:
### 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

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

[ahesford]

[-- Attachment #1: Type: text/plain, Size: 1128 bytes --]

New comment by ahesford on void-packages repository

https://github.com/void-linux/void-packages/issues/54043#issuecomment-2849171643

Comment:
This is an imaginary issue.

In general, any service can have an arbitrary list of seemingly trivial prerequisites. It is not the job to ensure that all are met. Ultimately, the user is responsible for understanding and satisfying these prerequisites. This is especially true when the user breaks customary expectations like the availability of persistent storage for logs. If you're going to mount something ephemeral over directory structures created by the system, you should take steps to ensure that the hierarchy below is recreated at the time of mount, whether or not consumers of that directory deign to make a good-faith effort to repopulate the hierarchy on demand.

We will certainly consider PRs that increase user convenience by creating an expected directory on demand or even allowing the user to configure the location of expected directories. However, these proposals must stand on their own utility. The existence of footguns in Void is not a problem *ipso facto*. 

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

[abhocetabhac]

[-- Attachment #1: Type: text/plain, Size: 1076 bytes --]

New comment by abhocetabhac on void-packages repository

https://github.com/void-linux/void-packages/issues/54043#issuecomment-2849210573

Comment:
I strongly disagree. A logging service that can lock out the root user simply because a directory is missing is not an "imaginary issue" — it’s a serious and untenable failure mode. If the required conditions for the service to start are not met, it should, at a minimum, report the error (no pun intended) and exit gracefully, not silently hang and render the system inaccessible.

Blaming users for mounting /var/log on tmpfs is not a reasonable position. That’s a common and valid configuration in many Unix-like systems, including Void. Services should be resilient to such setups and recover or fail cleanly when prerequisites are missing. Expecting all users to predict and manually patch around this kind of failure undermines the reliability of the system.

The fact that this situation can prevent root logins entirely elevates it beyond a mere inconvenience — it’s a critical reliability and usability flaw.

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

[ahesford]

[-- Attachment #1: Type: text/plain, Size: 1143 bytes --]

New comment by ahesford on void-packages repository

https://github.com/void-linux/void-packages/issues/54043#issuecomment-2849171643

Comment:
This is an imaginary issue.

In general, any service can have an arbitrary list of seemingly trivial prerequisites. It is not the job of the service to ensure that all are met. Ultimately, the user is responsible for understanding and satisfying these prerequisites. This is especially true when the user breaks customary expectations like the availability of persistent storage for logs. If you're going to mount something ephemeral over directory structures created by the system, you should take steps to ensure that the hierarchy below is recreated at the time of mount, whether or not consumers of that directory deign to make a good-faith effort to repopulate the hierarchy on demand.

We will certainly consider PRs that increase user convenience by creating an expected directory on demand or even allowing the user to configure the location of expected directories. However, these proposals must stand on their own utility. The existence of footguns in Void is not a problem *ipso facto*.