Skip to content

Instantly share code, notes, and snippets.

@rossabaker
Last active September 8, 2025 02:12
Show Gist options
  • Select an option

  • Save rossabaker/f6e5e89fd7423e1c0730fcd950c0cd33 to your computer and use it in GitHub Desktop.

Select an option

Save rossabaker/f6e5e89fd7423e1c0730fcd950c0cd33 to your computer and use it in GitHub Desktop.
migrated to paste.rossabaker.com
@lobre
Copy link

lobre commented Jan 30, 2020

Hi @rossabaker,
I have the same error on my machine. Did you manage to fix this?
Thanks

@rossabaker
Copy link
Author

By switching to NixOS.

If I remember right, Ubuntu and Debian run a pam.d with an extension that other distros (including nix) don't. I think you could also fix this by running i3lock from your district's package manager instead of nix. Most nixpkgs run great on Ubuntu, and most security-related ones don't

@lobre
Copy link

lobre commented Jan 30, 2020

Thanks for the quick answer.
I guess I have pretty much the same behavior. I am trying to run the nix version of i3lock on a non-NixOS operating system.
But I am not sure to understand exactly the problem. The package seems to generate only the etc/pam.d/i3lock.

/nix/store/9jk2dxkcygi3xgwahzmh0bi0yn1v009n-i3lock-color-2.12.c/
├── bin
│   └── i3lock-color
├── etc
│   └── pam.d
│       └── i3lock
└── share
    └── man
        └── man1
            └── i3lock-color.1.gz

And this i3lock configuration file only does a auth include login. So I guess it is trying to include the /etc/pam.d/login of the host operating system in an "impure" way. And effectively, a strace of the process shows that in action.

5025  openat(AT_FDCWD, "/etc/pam.d/login", O_RDONLY) = 5

But still not exactly sure to understand why we have this error.

@rossabaker
Copy link
Author

I think nixpkgs' i3lock refers to a PAM library from nixpkgs, and as you see from strace, it still loads from /etc and chokes on that non-standard Debian syntax. I made some progress by replacing the @include statements from /etc with standard calls, but it went deep, and I decided it wasn't maintainable in the long run.

@lobre
Copy link

lobre commented Aug 24, 2020

BTW, one solution to implement a fallback to the i3lock from the current OS:

https://git.0xee.eu/0xee/nix-home/commit/95e4900f31b4c3eadc49f7252e3cf17235e787bb

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment