Hacker News Reader

Comment by _d7dt | Hacker News Reader

I'm just curious, how would you suggest they debug and maintain support for that hardware, without even owning that particular device? It seems like anything they do would just be a wild guess as to whether it actually works or not. In my experience with this specialized datacenter hardware, if people want any of this stuff fixed (in userspace or in the kernel) it usually falls on the hardware vendor to hire some developers to fix it and upstream it, or at the very least donate some hardware to the upstream project so they can test properly.

View on HN

If they felt they needed information from, say, the Linux scsi maintainers then they could have gone out and asked for it. If they thought that in order for udev to do a proper job with these devices they needed the sg3-utils maintainers to write something new, they could have gone and asked for that. As it was they just stuck a "needs-new-home" label on the bug and ignored it.

I think useful action would have been more likely if udev had still been maintained by a team who believed they'd taken on the responsibility to make /dev/disk/by-path work, rather than maintained as a small part of a project whose maintainers are mostly interested in other things.

(Also, IIRC from what I had to do to work around it, they could have fixed that bug by reverting the change that introduced it. It wasn't a case of existing udev code not working with new hardware; it was caused by someone making changes without understanding the consequences.)

That's what I mean though, all of that seems to be just wild guessing as to what will actually work and sending random emails out to random people who may or may not be able to fix it (Disclaimer: I don't know anything about this specific bug or the specific hardware). Wouldn't someone who actually owns the device and knows who to contact on the kernel side be a better person to lead the effort on that?

This was a bug in udev.

The right people to lead the effort on fixing bugs in udev are the udev maintainers.

If people did not wish to have the responsibility for leading the effort to fix bugs in udev, they had the option of not taking over the maintenance of udev.

I agree with ohazi, above, that the world would be a better place if the systemd people had availed themselves of that option.

(To be fair, it looks like this issue was fixed a few months later by someone who knew what they were doing. So the main lesson here may be something more like "@poettering should not be triaging udev bugs".)

I see people saying this kind of thing often in open source and I think you are missing the point here: who is going to fix this bug? You can say systemd developers shouldn't triage it, and then you're left with nobody to triage the bug at all. So what will you do? The point is, they don't own the hardware, they can't fix the bug. You have to find somebody who actually does own the hardware who knows what is going on, which seems to be exactly what happened. But if you get unlucky and if zero of those people are contributing to udev or any of its forks, then the bug probably won't ever get fixed.

For what it's worth, I didn't mean that the systemd people shouldn't triage the bug.

I meant that I suspect @poettering was mistaken when he said the current maintainers didn't collectively have "the expertise and understanding to maintain this properly."

As far as I can make out, there was nothing particularly hardware-specific about the bug. The bug was that udev was assuming that there could be no more than one disk per SATA host node, which turns out not to be the case.

`udevadm info` output would have been enough to see what was going on, which I'm sure the reporter would have happily supplied.

From what you were saying earlier, from the perspective of the bug triager, it sounds like there were multiple areas that maybe this could have been fixed in, not necessarily udev. So still that comes back to: the correct people to triage that bug really would have been the distro maintainers, who have total visibility over the whole system and who are better equipped to pinpoint where the bug should be fixed. And then from there they can pass it off to a systemd person or an OEM person, or both, or whatever (Again disclaimer, I don't know anything about this particular SATA hardware or whether this is normal behavior for a host node, this is just my experience from trying to triage this type of bug).

I think their point is: with smaller project scope, this bug wouldn’t have existed in the first place.

That is throwing the baby out with the bathwater though, people who want large scale projects will continue to make projects with large scopes.

And they will continue to be bitten by problems specific to large-scope projects. Wanting something, no matter how much, does not let them escape engineering reality.

I think they are aware of what they signed up for. Linux has continued to grow year after year, the reality for them is that they can afford it.

Apparently not. If they had not signed up for it, in this case they would not have ended up triaging a bug they did not have the skills or hardware to tackle.

Just to be clear: the alternative there is that nobody looks at the bug at all because nobody but the bug reporter has the hardware. I don't think that's what you want, I assume you would just prefer the bug to be fixed.

No, the alternative is that, with no clear owner of the bug, the ownership problem gets dealt with early, rather than having the bug go stale in a can't-fix-won't-fix state for months because the wrong people claimed ownership of the subsystem.

>the wrong people claimed ownership of the subsystem

That's... not what's happening at all? The issue is there _wasn't_ any of the right people around to claim ownership of the bug. It's not like someone in the know can't just look at the systemd bug tracker, it's all public. Like, I get what your complaint is, but at the end of the day, do you really care who's name is on the commit that fixes the bug? I usually don't, and most maintainers I know probably don't either -- they're usually happy to delegate to someone who's more knowledgeable in the problem area. If you have some other solution you'd like to suggest here then I'd love to hear it, let's move beyond the criticism and start thinking about solutions. And I don't even mean this as a solution in systemd, I mean this as a "helps anything that interacts with hardware and has bugs that could potentially be caused by hardware" solution.

This wasn't a hardware bug and it didn't materialize only when some particular hardware was plugged in. Were they just supposed to open a phone book, pick a random hard drive manufacturer, and say "hey this is your problem now"?

No, it seems the specific hardware causing the issue was mentioned in the bug report.

systems/udev was spearheaded by employees getting paid to write it, not enthusiastic gnuers doing it for love.

My biggest gripe is that the logs are in a binary format.

You use a tool like cat, vim , emacs, or tail to see logs. You can't physically read the file off the disk, how is this different than using journalctl ?

# journalctl -u ssh

I think the issue is not that it's binary, but that it's a custom half-assed format. It's actually pretty slow because there is not enough indexing, this is why `systemctl status` can takes seconds to show the last 10 log lines[1]. Even worse, systemd can detect corruption but can't repair the logs[2], in practice a power failure can mean months of logs thrown away. Thankfully it can skip over corruption, so logging continues to work.

I would have no problem if systemd used a database like sqlite, lmdb or anything else with some valid tooling, indexing, caching and proper recovery solutions.

[1]: https://github.com/systemd/systemd/issues/2460

[2]: https://unix.stackexchange.com/questions/86206

I looked into this a while ago -- a traditional transactional CRUD database is totally unnecessary here, these are not files that you want to be editable by random tools. The journald log files have the important property that they are append-only by a single-writer. I agree there are some outstanding issues but those issues should just be fixed, instead of throwing it all out and moving to an even more complicated database layer that brings with it all its own additional problems. I think it would be perfectly feasible for someone to improve the indexing to show the latest 10 lines, or to write a fsck-type tool to repair damaged logs.

> instead of throwing it all out and moving to an even more complicated database layer that brings with it all its own additional problems.

Would SQLite be any more complicated than what they have now? Or OpenLDAP's Lightning Memory-Mapped Database (LMDB)? OpenLDAP/Symas' Howard Chu on the latter:

* https://www.linkedin.com/pulse/20140924071300-170035-why-you...

Conventional logs are files, the fundamental unifying abstraction of Unix, and so you can read them with any tool, even a tool that was written before your logging system and that your logging system's author didn't know about. Having to take them just as piped input is a much more limited interface that doesn't allow you to do all the things you can do with a real file.

> so you can read them with any tool

what tool can't you read them with? Why is the fs the fundamental unifying abstraction, as opposed to pipes?

> doesn't allow you to do all the things you can do with a real file

like what?

You can't do random access through a pipe, so you can't binary search for it, or if you have some kind of probabilistic skip-sampling tool that won't work. Pipes don't have names, so anything that expects to work with them won't work. You can't re-read the same file. I don't know all the things you might want to do, but that's kind of my point - most things work with and expect files, and so if you want to be able to count on being able to use other unknown tools, a file is what you need.

Pipes are files. From the point of view of the consuming process, you're just reading from a file descriptor. Files are more fundamental than pipes.

If lmm shared this opinion, then there should be no problem, as systemd logs can be piped.

All pipes are files. Not all files are pipes.

So, back to the original question: what's the problem here? what is disallowed?

Also: If all pipes are files, but not all files are pipes, it would seems to me that files are more restrictive. That, and the extra steps you need to take to avoid needless IO.

I recommend https://www.amazon.co.uk/dp/013937681X/ref=cm_sw_r_cp_apa_gl... as an introduction to the fundamental concepts of the Unix filesystem. Certainly a better education than I could give here.

The original post was:

  that doesn't allow you to do all the things you can do with a real file

I'm not interested in what the differences between a pipe and a file are (I know) - I'm interested in why OP thinks they are relevant in this specific context/case; particularly in context of my statement:

  seems to me that files are more restrictive

Is, for example, a sticky bit relevant to systemd log files?

But allows you to do things like properly filter based on multiple properties, and you can still use it to output text logs as well.

There are plenty of unix tools for filtering files based on all manner of things. That's the unix way of doing things, and for many users the ability to mix and match unrelated tools is where a lot of the value of linux-like systems comes from.

I don’t find grepping text logs for a service file name with many false positives better in any way than just filtering on an actual column of a quasi-db.

Also, you can pipe the output of journalctl to do whatever you want with it with those unix tools.

Which I recall being touted as one of the major advantages of systemd - specifically that binary log files would make for much easier log aggregation as it would be more efficient to send over the wire. Fast forward to today and the best way of shipping logs is to force journald to output to, uh, text, then wring it through, yes thats right, syslog, to then be sent to a central server...

At the risk of uttering a "you're holding it wrong" defense, it feels to me the issue isn't with logging format, but the stubbornness of *nix admins used to working with text. For better or worse, software moves in the direction of things large amounts of developers like the most, whether it makes sense or not.

Amarok 2 moved in the direction that the developers wanted, but the users hated it. Proves your point though!

Reply on news.ycombinator.com