Warning: there may be occasional oddness due to css and blog edits. **KNOWN ISSUE: possible hidden text**

Monday, February 8, 2021

Time to retire, HAL

  Remove hal

Hal has been introduced as part of the Gnome2 desktop and used in many
desktop application as an abstraction on the hardware layer, it has been quickly
deprecated, but alternatives took time to land in freebsd.
In most cases alternatives are now in place or upstreams dropped entirely
support for HAL.

As a result it is time to retire HAL

We might not all have used sysutils/hal or even known that it was mostly silently working in the background as any good daemon process should.  Today marks the final nail in its coffin, as it has been deprecated for quite some time and alternatives rolled out and have now been in place for ages.  If for nostalgia or familiarity or uncertainty any of us may still have or chose to have installed it after it was already set on its journey to eventual FreeBSD expiration, there will be a little cleanup to do on our own systems.  Surely we can all safely remove sysutils/hal if it remains, and that is a very simple operation.

pkg remove hal

The next two adjustments are likely less familiar to most users.  We need to remove haldaemon as both a user and a group.  Since I knew how to edit the password file with vipw (which incorporates use of vi), I used that to remove the haldaemon line.  It turns out that there is another way that possibly ought to have been more obvious, but how often does an admin who uses a pc alone with no other human users on their system ever add or remove them?  The command is rmuser but since my passwd no longer includes haldaemon, I am not sure what it will do but I suspect it will give an error.

rmuser: user (haldaemon) does not exist in the password database.

I have two choices, remove the group as a seperate operation as I planned before discovering rmuser or I could re-create the haldaemon user, then use rmuser which should then work.  I can show how both methods look, but we can remove the group now and then re-create both user and group before using rmuser to see how that looks.

It turns out that editing the group file to revise or remove a group is a fairly simple operation, we can use vigr (which also incorporates use of vi), but lets create a haldaemon account and group to show how rmuser works.

When sysutils/hal was installed, it automatically created the user and group haldaemon but did not also create a home directory.  We can simulate this by using adduser in a similar fashion, answering its prompts the same as below or by using

pw useradd haldaemon -u 560 -g 560 -d /nonexistent -s /sbin/nologin -c "HAL Daemon User"

since I did not remove the haldaemon group.

rmuser haldaemon
Matching password entry:

haldaemon:*:560:560::0:0:HAL Daemon User:/nonexistent:/sbin/nologin

Is this the entry you wish to remove?  y
Remove user's home directory (/nonexistent)?  y
Removing user (haldaemon):
 mailspool home passwd.

Checking the content of /etc/group using vigr proves that haldaemon group is no longer present there.  The above output also mentions the other locations where haldaemon if present would be removed: mailspool, home, and passwd. The next time a similar daemon, which is presently devd, or any other daemon or user might need to be removed, the same steps would be used.  Further information about account modification is available in the FreeBSD handbook.

Since we have modified /etc/passwd there is another thing we must do in order to keep our system reliable. We need to synchronize those changes with /etc/master.passwd by using the command below (entire path provided for precision but /usr/sbin/ can be omitted), more detail can be found by man 8 pwd_mkdb which includes one option (-C) to simply verify no errors were made with any edit.

/usr/sbin/pwd_mkdb -p /etc/master.passwd

One more detail that will be discovered with a reboot once all of the above is accomplished, that is, if your /boot/loader.conf (or possibly /etc/rc.conf) still has a line to start the hal daemon process.  Edit the appropriate file to remove such a line as below and the forgotten step will not haunt you in the future, but if you received an error at boot, that it couldn't load hal or a similar error, you'd know how to fix it I hope but here I describe how.

hald_enable="YES"

No comments:

Post a Comment

Thank you for your interest!

Frequently viewed this week