IRC channel logs

<azeem>ok, so if I initialize and start a new instance as postgres user I can send it SIGHUP just fine, it must have something to do with the init scripts/service then

<sobkas>shell init script for postgress is still maintained?

<azeem>I don't know

<azeem>it's probably started via the Debian pg_ctlcluster wrapper

<sobkas>because it smells like bitrot

<azeem>but yeah

<azeem>postgres@debian:~$ /etc/init.d/postgresql status

<azeem>17/main (port 5432): online

<azeem>postgres@debian:~$ LANG=C /etc/init.d/postgresql reload

<azeem>Reloading PostgreSQL 17 database server: mainpg_ctl: could not send reload signal (PID: 14366): Operation not permitted ... failed! failed!

<azeem>it is running pg_ctlcluster behind the scenes

<azeem>but it is the same if I run pg_ctl directly:

<azeem>postgres@debian:~$ LANG=C /usr/lib/postgresql/17/bin/pg_ctl -D /etc/postgresql/17/main reload

<azeem>pg_ctl: could not send reload signal (PID: 14366): Operation not permitted

<sobkas>ok xfce4-session xfdesktop4 needs in build dep libgtk-layer-shell-dev [!hurd-any], it allows a working xfce4 desktop

<azeem>hrm, it might have to do with pg_ctlcluster having been invoked as root and then changing uid to postgres or something?

<azeem>yeah, if I stop the instance, and then start it via pg_ctlcluster as postgres, I can send it SIGHUP just fine

<azeem>is that a known limitation of sending signals on the Hurd? I.e., a user can not send signals to processes that run under their uid, but which were started from another uid and then changed to theirs?

<damo22>azeem: so when it fails on a pid, check the owner of the pid

<damo22>maybe the process needs to be taught how to properly de-elevate privileges?

<azeem>what do you mean with owner of the pid?

<damo22>eg ps -ef|grep bash

<damo22>the first column is the owner?

<azeem>right

<azeem>postgres certainly is the owner

<damo22>ok then maybe there is some kind of missing call to swap owners

<damo22>im not sure

<azeem>postgres@debian:~$ ps -ef | egrep '(USER|14971 1)' | grep -v grep USER PID PPID TTY TIME COMMAND

<azeem>postgres 14971 1 - 0:00.06 /usr/lib/postgresql/17/bin/postgres -D /var/lib/postgresql/17/main -c config_file=/etc/postgresql/17/main/postgresql.conf

<azeem>postgres@debian:~$ LANG=C kill -s HUP 14971

<azeem>-bash: kill: (14971) - Operation not permitted

<damo22>yeah that is weird

<azeem>damo22: pg_ctlcluster is a perl script, and it changes owners like this: https://salsa.debian.org/postgresql/postgresql-common/-/blob/master/PgCommon.pm?ref_type=heads#L1273

<damo22>i thought a C program needs to make a call itself to change owner

<damo22>unless the script invokes su

<damo22>before running the program

<damo22>maybe take a look at the source code for /sbin/smp

<damo22>is the postgres thing a suid binary?

<azeem>no, I can reproduce it with this small perl script: https://paste.debian.net/hidden/80290321

<azeem>if I run that with sudo, I can't HUP it as uid 101 (postgres)

<damo22>i dont know perl but that doesnt look like it does anything to user id

<azert>sobkas: I think that signalfd and timerfd should be straightforward to implement

<azeem>damo22: I see the script as user postgres when I execute it with sudo

<azeem>postgres@debian:~$ ps -ef | grep ^postgres.*/test-uid-HUP.pl | grep -v grep

<azeem>postgres 15473 15472 p3 0:00.00 /bin/perl ./test-uid-HUP.pl

<azeem>postgres@debian:~$ LANG=C kill -s HUP 15473

<azeem>-bash: kill: (15473) - Operation not permitted

<azert>still lot of work

<azeem>this works on Linux

<damo22>azeem:

<damo22>root 17539 17533 p6 0:00.00 sudo ./perltest.pl

<damo22>demo 17540 17539 p6 0:00.00 /bin/perl ./perltest.pl

<damo22>so the instance of perl gets a new pid

<damo22>the original command pid is still owned by root

<damo22>demo@zamhurd64:~$ kill -9 17540

<damo22>-bash: kill: (17540) - Operation not permitted

<damo22>and interestingly i cant kill the child one

<azeem>yeah

<azeem>maybe some oddity in perl

<damo22>maybe its a bug in perl

<azeem>well, the Hurd port of it, it works ok in Linux for me

<damo22>yeah

<damo22>maybe it spawns a thread? im not sure

<damo22>it looks like a separate process to me

<azeem>if I do the same in plain C, the processes look the same

<azeem> root 15677 3688 p1 0:00.03 sudo ./test-uid-HUP

<azeem> root 15684 15677 p3 0:00.00 sudo ./test-uid-HUP

<azeem>postgres 15685 15684 p3 0:00.00 ./test-uid-HUP

<azeem>(but HUP works there)

<azeem>I don't see a difference looking at e.g. /proc/<pid>/stat

<azeem>with rpctrace I see with C:

<azeem> 7<--42(pid15932)->auth_makeauth ( 101 {101 101 1000} 0 {0 0}) = 0 57<--52(pid15932)

<azeem>(101 being the postgres uid)

<azeem>and with Perl:

<azeem> 43<--67(pid15934)->auth_makeauth ( 101 {101 0 1000} 0 {101 0}) = 0 38<--36(pid15934)

<azeem>actually Perl runs auth_makeauth three times:

<azeem> 7<--42(pid15934)->auth_makeauth ( 0 {0 0 1000} 0 {101 0}) = 0 60<--54(pid15934)

<azeem> 60<--54(pid15934)->auth_makeauth ( 0 {101 0 1000} 0 {101 0}) = 0 43<--67(pid15934)

<azeem> 43<--67(pid15934)->auth_makeauth ( 101 {101 0 1000} 0 {101 0}) = 0 38<--36(pid15934)

<azeem>ok, I straced the perl program in Linux, and it calls thw following sequence of syscalls: setregid(101, -1), etreuid(101, -1), setresuid(-1, 101, -1)

<azeem>if I run those in C on the Hurd, I get the same EPERM issue on SIGHUP (but not in Linux), the auth_makeauth calls are:

<azeem> 8<--39(pid16773)->auth_makeauth ( 0 {0 0 1000} 0 {101 0}) = 0 52<--47(pid16773)

<azeem> 52<--47(pid16773)->auth_makeauth ( 0 {101 0 1000} 0 {101 0}) = 0 40<--62(pid16773)

<azeem> 40<--62(pid16773)->auth_makeauth ( 101 {101 0 1000} 0 {101 0}) = 0 61<--58(pid16773)

<nexussfan>Was there ever any plans to port Linuxulator to HURD?

<azeem>In https://cgit.git.savannah.gnu.org/cgit/hurd/gnumach.git/tree/kern/mach_factor.c#n50 the loadavg is defined as 5s/30s/1min, whereas on Linux it is assumed as 1min/5min/15min and this is also mentioned in https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/mach/getloadavg.c;hb=HEAD

<azeem>where is the conversion happening, or are the numbers on the Hurd really 5s/30s/1min?

<azert>I think a better strategy for Linux binary compatibility in the Hurd isn’t achieved at the level of system calls, but at the dynamic linker level

<azert>so that any glibc based program that doesn’t uses syscall directly or Linux specific apis will work on the Hurd out of the box, while the others would just fail

<azert>if a program uses those apis, it’s unreasonable to expect it to work fine on the Hurd

<azert>By the way, tangential to that, binary compatibility is an atrocity between different Debian versions

<azert>like I cannot believe that a software that uses libwebkitgtk2 on bookworm is broken on trixie in a very bad way

<azert>but that’s the case

<azert>so i would say we just say “fuck it” if anyone asks

<azert>Linux itself is supposed to support multiple library versions. But it doesn’t. And breaks other people code very hard in not doing it. Nobody says a word about this but it’s the reason Linux fails big on the desktop

<azert>in a way this is an obvious outcome of the fact that nobody wants to support other people’s software for free

<Gooberpatrol66>nexussfan: netbsd has linux emulation so potentially it can be ported via rump https://www.netbsd.org/docs/guide/en/chap-linux.html

<Arsen>[20:15:58] <azert> like I cannot believe that a software that uses libwebkitgtk2 on bookworm is broken on trixie in a very bad way

<Arsen>that's the fault of that god forsaken lib

<Arsen>I have like three versions of it installed on Gentoo due to that

<Gooberpatrol66>compiling webkitgtk 3 times "this little maneuver is gonna cost us 50 years"

<Arsen>you get it ;)

<sobkas>I was thinking about gnumach, and that maybe hurd could stop leaking kernel interfaces under it, not a port to different kernel something easier, better port to exisiting kernel

<jab>sobkas: porting to a different kernel has been tried in the past. It's non-trivial. It may be better to write a custom kernel.

<sobkas>Using custom kernel means someone needs to maintain that kernel, are there enough developers in hurd to do that?

<sobkas>Also I said don't port to another kernel, make existing port better, for example don't leak kernel underneath hurd to userspace

<damo22>what do you mean?

<jab>sobkas: I misunderstood what you meant. There is a GNU Mach clean up GSoC project idea.

<damo22>the existing interfaces are needed to manage memory, IPC, IRQs etc

<sobkas>Make for example libc use hurd not mach under it

<damo22>where can the message queue live?

<damo22>in glibc??

<damo22>something has to provide inter process communication

<damo22>thats what mach does

<sobkas>Existing interfaces could be used by hurd and hurd could provide it's own abstraction on top

<damo22>that is what i did for libirqhelp

<damo22>now nobody needs to write kernel rpcs for interacting with irqs, they just call this userspace lib

<damo22>but the lib calls the kernel rpcs

<damo22>is that what you mean?

<sobkas>More like writing translator that would do the same, and have lib use it, so aging mach could be hidden behind and properly optimised in abstraction layer

<damo22>irqs need low level hardware access and integrated with timer from kernel, its better if that lives in the kernel

<damo22>some things cannot easily migrate out of the kernel

<damo22>otherwise you need a lot of arch specific code in hurd

<damo22>and put up with delays

<damo22>currently, hurd doesnt care too much what ISA it runs on, gnumach takes care of the machine abstraction

<sobkas>Not migrating, having abstraction layer in hurd, good abstraction layer can speed things up, for example limiting number of msgs from/to kernel

<damo22>ok

<azert>sobkas: I agree with you that the way to go is to reduce gnumach size more and more

<azert>that’s what’s happening with userspace drivers

<azert>but as damo22 said, you still eed

<azert>to

<damo22>we are almost at the point where we can remove linux/ from gnumach

<azert>keep things like irq controllers in the kernel

<damo22>that wasnt an easy task

<azert>I was thinking that the arm64 port would have been a major cleanup

<azert>like really implement the bare bones in gnumach

<azert>why gnumach needs a keyboard driver???

<azert>but irq chips needs to be implemented there

<damo22>well try debugging the kernel with no keyboard

<azert>damo22: I would leave the uart

<damo22>:D

<azert>also debugging could be moved to an hypervisor sort of layer

<damo22>hmm irq receive could provide high resolution timestamp

<damo22>so drivers can know when irq arrived

<azert>better if irq receive would task switch to the driver without delays

<azert>is this what happens?

<damo22>yea it calls the handler

<damo22>i think there is a polling loop waiting for them

<damo22>but audio driver needs timing info

<damo22>to know when irq arrived

<azert>cannot it just take the time when it arrive to himself?

<azert>I don’t think gnumach implememts

<damo22>it can, but it would be better if it was accurate

<azert>real time guarantees

IRC channel logs

2026-02-08.log