Buildroot, Systemd, and Getty
I just spent a few hours trying to get systemd to spawn a getty on the vt console for a Linux image that I was building with Buildroot. It turns out that it helps to read the right documentation, which in this case was a blog about systemd console handling.
The money quote for me was:
In systemd, two template units are responsible for bringing up a login prompt on text consoles:
Setting the HTTP User Agent in Go
Here’s the smallest amount of code I could come up with to set the
user agent when making a HTTP request in Go:
type UserAgent string
func (u UserAgent) RoundTrip(r *http.Request) (*http.Response, error) {
r.Header.Set("User-Agent", string(u))
return http.DefaultTransport.RoundTrip(r)
}
http.DefaultClient.Transport = UserAgent("my-great-program")
Note that this isn’t really legal, since the
RoundTripper
is not supposed to modify the request.
Ccache and Bazel
Bazel defaults to building code in a sandbox that remounts most of the filesystem read-only. This means that if you are using ccache (Fedora, for example, will enable it by creating appropriate symlinks when you install the package) the compile job will fail because it can’t write to the cache directory.
The straightforward fix to this is to create a bazelrc file which specifies the Bazel sandbox_writable_path flag to make the cache directory writeable.
Using alternatives(8) to enable lld
In this post, I remember how to use the alternatives(8) mechanism to make clang’s lld linker the default.
First, tell alternatives that lld is available and set it at a high priority:
$ sudo alternatives --install /usr/bin/ld ld /usr/bin/lld 80 $ sudo alternatives --auto ld Then, just verify that it worked:
$ alternatives --display ld ld - status is auto. link currently points to /usr/bin/lld /usr/bin/ld.bfd - priority 50 /usr/bin/ld.gold - priority 30 /usr/bin/lld - priority 80 Current `best' version is /usr/bin/lld.
Mesos config for cquery
The canonical way to feed your project to cquery is to generate a compile_commands.json file, possibly using cmake. Every time I switch my Mesos work to the cmake build, I live to regret it, either because the component I’m working on isn’t implemented in the cmake build or I end up wanting to install the build (and that isn’t implemented in cmake).
So here’s a .cquery file that makes cquery work pretty well with Mesos:
Using cquery from vim with cscope-lsp
A while ago I tried cquery with Vim, but was a bit unsatisfied with the integration. I could probably have altered my key bindings to perform LSP searches instead of cscope searches, but I also really quite like the integrated tags stack you get with the built-in Vim cscope support.
So I thought that it couldn’t be too hard to implement the cscope line protocol with a cquery backend, and it turns out that it wasn’t.
Debugging libstdc++ strings
Writing this down quickly before I forget.
When debugging a std::string from GNU libstdc++, the debugger typically won’t show you the actual representation.
First, you need to turn off the pretty printer (assuming that it worked in the first place):
(gdb) p reregisterSlaveMessage.resource_version_uuid_.ptr_ $13 = (std::string *) 0x7f4d98d5e970 (gdb) p *reregisterSlaveMessage.resource_version_uuid_.ptr_ $14 = "\022\020K|\n\225\064\246CE\222\350\275\315t", <incomplete sequence> (gdb) disable pretty-printer 2 printers disabled 0 of 2 printers enabled (gdb) p *reregisterSlaveMessage.resource_version_uuid_.ptr_ $15 = { static npos = <optimized out>, _M_dataplus = { <:allocator>> = { <:new_allocator>> = {<no data fields>}, <no data fields>}, members of std::basic_string<char std::char_traits>, std::allocator<char> >::_Alloc_hider: _M_p = 0x7f4d98d67068 "\022\020K|\n\225\064\246CE\222\350\275\315t", <incomplete sequence> } } Next, you need to know that the internal structure of std::string is prepended to the actual string data, so you need to cast and subtract from the data pointer to find the length and refcount.
Native Prometheus Support in Mesos
I wrote a design document
here
retrospectively discussing and justifying my patch series that implements
native Mesos support for a Prometheus metrics endpoint.
PAM support in the Mesos containerizer
Recently, it occurred to me that running a containerized task is concentually very similar to having a remote session on an anonymous compute agent. The traditional way for operators to influence (i.e. configure, control, log) the environment of a remote user session is by the use of PAM modules. One of the applications that I had in mind was the use of the pam_loginuid module to set the linux audit ID so that containers audit events can be attributed to the task user rather than to the container orchestrator.
Tracing rmdir system calls with SystemTap
I wanted to know who was removing the Mesos memory cgroups hierarchy and why, so I turned to SystemTap. Here’s my one-liner:
sudo stap \ -d /usr/lib/systemd/libsystemd-shared-233.so \ -d /usr/lib64/libc-2.25.so \ -d /usr/lib/systemd/systemd \ -e 'probe kernel.function("sys_rmdir") { printf("%s(%s): %s\n", execname(), pp(), user_string($pathname)); print_ubacktrace(); }' Note that you have to feed in the binaries you expect to see in order to get user stack traces.
The corresponding systemd stack trace was: