Do we have such thing as /var/lib?

Today, I was trying to track a bug I ran into at Google Compute Engine. There was a moment when I ended up in a directory called /var/lib/google.

I felt strange. I didn’t know why. It was like when you visit a guru who puts you into regressive hypnosis to remember your previous life. Then you wake up, and you feel crap because you can’t remember what you did there, but you know the trip was horrible.

On GCE, there is only 'google' in /var/lib. Since I know that hiding and praying doesn’t always help, I logged in my CI server a VM-guest server to check their content.

Code:
$ ls -l /var/lib/
total 2
drwxr-xr-x  2 root  wheel  3 Apr 18  2017 dbus
drwx------  3 root  wheel  3 Apr 13  2017 polkit-1
drwxr-xr-x  2 root  wheel  2 Jan  6  2017 xkb

Maybe I misunderstood something in the last few years. Please tell me that tomorrow, when I wake up, my servers won’t be running systemd.
 
The directory /var/lib is not common on FreeBSD. See hier(7). It's commonly used on Linux though.
 
Which port? Maybe the maintainer figured it would be easier to keep the same directory structure.
 
Which port?

I don’t know. I wrote it in my OP what files and directories are there. A guess dbus might be related to dbus, but I don’t know who and why put something there under google, even though that’s why I noticed that directory in the first place.

I was working on this bug:


Maybe the maintainer figured it would be easier to keep the same directory structure.

Yeah. That’s why I wrote I hope we won’t have systemd soon for a similar reason.
 
Run pkg info -l <packagename> to see which files are contained in a package. You can also work in reverse using pkg which /some/file/path to see which package created or installed that file.
 
Run pkg info -l <packagename> to see which files are contained in a package. You can also work in reverse using pkg which /some/file/path to see which package created or installed that file.

It won’t work because what /var/lib is on Linux, it’s /var/db on FreeBSD. The vast majority of the files are not created there when you install a package. The installed software create files in /var/db when they run. And these files remain there when you remove the package because they don’t belong to the package. I think 'db' refers to database.

I know why they are there. It was either laziness or a mistake when the package was ported from Linux. I don’t mind too much what dbus does (it’s a meh). I’m trying to fix an issue with Google Compute Engine daemons, and I never thought to look for files there. And they shouldn’t be there.
 
This is the second time I've seen that this morning. What is "CI"?

SirDice already answered what it is. I add only a note.

A CI server may have the layout, configuration, packages that are typical for a production server, and the same time, it may have desktop software too. For example, when you test a web application, you want to do automated testing with a browser. That means Xorg, Firefox, maybe Chrome, even if you never see a graphical interface on it. My CI servers use a framebuffer for the browser. In the end, it’s more like a desktop, that’s why there is dbus and such on it.
 
I thought it was clear that a part of my OP was to complain about it, another part of it was to make it sure that /var/lib shouldn’t be there (so I can complain from the heart).

Lately, I spent a lot of time on issues due to hardcoded paths (all from Linux), and this one was the least harmful amongst them. I ran into a few not only in FreeBSD ports but in Ruby gems (libraries) as well. And usually, the code that has hardcoded Linux paths is the same code that also doesn’t check the exit status of the sendmail executable regardless of whether the executable exists at the hardcoded path in the first place.

These things come together, more often than not.

My therapist is both smart and understanding, but when it’s the Linuxisms, I don’t feel to complain about it to her.
 
drhowarddrfine

You probably want to have a look on THIS particular one. :)
I just didn't make the connection between continuous integration and CI server. When scanning the morning sites I go through while drinking my coffee, I so often see hobbyists talk about how they had to "drop down to the CL", meaning the command line, as if using the command line, aka terminal, was a unique thing to do cause it gets in the way of their game play.
 
I just didn't make the connection between continuous integration and CI server. When scanning the morning sites I go through while drinking my coffee, I so often see hobbyists talk about how they had to "drop down to the CL", meaning the command line, as if using the command line, aka terminal, was a unique thing to do cause it gets in the way of their game play.

The connection was that I would expect such anomalies to happen less likely in server software, and more likely in desktop softwave (KDE, dbus, etc). In the end, the assumption was correct. I could check it only on the CI server that has desktop software because for desktop, I use Mac.
 
The connection was that I would expect such anomalies to happen less likely in server software, and more likely in desktop softwave (KDE, dbus, etc). In the end, the assumption was correct. I could check it only on the CI server that has desktop software

Can confirm this. On the desktop I have these directories also. I would assume it belongs to some of the many things firefox (and similar big pieces) call as prereqs.
 
On a server I installed in 2016 and I never used it for CI, there is an empty dbus directory there. Most likely it was due to ImageMagick that used to depend on Xorg (even the -nox11 version had some dependencies).

On my newer servers that are running the same sites, there is only google there.
 
Back
Top