On Wed, Oct 02, 2024 at 01:45:15PM +0000, Zbigniew Jędrzejewski-Szmek wrote: > On Tue, Oct 01, 2024 at 08:42:56PM +0200, Aleksa Sarai wrote: > > On 2024-10-01, Tycho Andersen <tycho@tycho.pizza> wrote: > > > From: Tycho Andersen <tandersen@xxxxxxxxxxx> > > > > > > Zbigniew mentioned at Linux Plumber's that systemd is interested in > > > switching to execveat() for service execution, but can't, because the > > > contents of /proc/pid/comm are the file descriptor which was used, > > > instead of the path to the binary. This makes the output of tools like > > > top and ps useless, especially in a world where most fds are opened > > > CLOEXEC so the number is truly meaningless. > > > > > > Change exec path to fix up /proc/pid/comm in the case where we have > > > allocated one of these synthetic paths in bprm_init(). This way the actual > > > exec machinery is unchanged, but cosmetically the comm looks reasonable to > > > admins investigating things. > > > > While I still think the argv[0] solution was semantically nicer, it > > seems this is enough to fix the systemd problem for most cases and so we > > can revisit the argv[0] discussion in another 10 years. :D > ... > Unfortunately, I don't think that the approach with > f_path.dentry->d_name.name can be used :( hmm. Somehow earlier I had managed to convince myself that this gives the right answer for symlinks too (instead of the original kbasename(__d_path(file->f_path, root, buf, buflen)), but now upon retesting it doesn't. So I agree, seems like the argv[0] hack is needed unfortunately. Tycho
