bl33pbl0p
bl33pbl0p
It would also be nice to have a release soon, preferably after this gets merged. =)
Sorry, I kept missing this all this time. Is this close to what you wanted (I'm not really great at meson)? @keszybz
There was recently a paper by the seL4 people on exposing scheduling context as capabilities, putting this here if people want to look into it to get some ideas on...
Slightly offtopic but with the potential of simplifying the implementation, recently device namespaces support made it into the kernel (so a privileged process with CAP_SYS_ADMIN can tag uevents and send...
Just leaving a comment here, I saw a unit also missing _SYSTEMD_INVOCATION_ID=, which makes perfect sense, it seems it reads it from the what the link points to in /run/systemd/units...
I was also diving in the code used for LogExtraField=, and exploring if it was possible to use the same mechanism to attach the unit name to messages (because we...
@poettering @lucaswerkmeister I was thinking of a plausible solution for this. Would replacing the socket with a file on a fuse filesystem the journal exposes be reasonable? The rationale is...
I saw this comment: > @keszybz the primary reason i know why this would be a good idea is echo foo > /dev/stderr. That pseudo-device is a symlink to /proc/self/fd/2...
This is only for the socket we connect every service's StandardOutput and StandardError to (i.e. replace the socket with a file on the fuse filesystem for every service or something...