Skip to main content
Topic: First Impressions (Read 149 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

First Impressions

Thanks to Dudemanguy for packaging S6 for Artix. I hope the following comments will be of use, both to him and anybody else who might be interested.

Installation.

I decided to try converting my OpenRC Artix install to S6 (using a copy in a separate partition, of course).

All went fairly smoothly to start with - removed OpenRC, installed S6 and added a number of service packages: lightdm-s6, dbus-s6, cups-d6 and so forth.

However, things started to get decidedly odd when I added a number of self-written service files, and so had to run 's6-rc-compile' and 's6-rc-update'. And even worse when I subsequently added a futher S6 package or two from the repos.

After a lot of trial and error, investigation, and reading skarnet.org's documentation, I realised that the following conditions must be met -

1. /etc/s6/rc/ contains a link 'compiled' pointing to the current database, but 's6-rc-update' doesn't update this link to point to the latest version produced by the previous 's6-rc-compiled'. You have to do this yourself.

2. 's6-rc-update' deletes your 'default' bundle completely. So you MUST rerun 's6-rc-bundle add default .....' before any reboot.

3. If you run pacman to add/delete an S6 package, the post-transaction hook (in /usr/share/libalpm/hooks/s6-rc-db-update.hook and /usr/share/libalpm/scripts/s6-rc-db-update-hook) does the following -

    a. Runs 's6-rc-compile', 's6-rc-update', an edits the 'compiled' link to point to the latest database. All good so far.

    b. Deletes any old databases in /etc/s6/rc/. Not so good, as it deletes based purely on the filename ('compiled-nnnnnnnnnn' where 'nnnnnnnnnn' is the output of 'date +%s' at the time of running the hook), rather than the actual timestamp of the file.

    c. Outputs a message asking that you redo your bundle.

    So you MUST use 'date +%s' when naming your self-compiled databases. If not, you could end up (as I did) with the 'compiled' link pointing to a non-existant database, with the one just created by the hook having been deleted.

Suggestions.

1. For users: read all the relevant documentation on the skarnet.org website BEFORE starting. Perhaps print it out, and highlight any important bits?  Also keep a note of your 'default' bundle's services.
Note: some of the skarnet documentation differs from the Artix package.

2. For Dudemanguy: amend the post-transaction hook to do the database deletions based on the timestamps, not filenames. Perhaps keep 2 or 3 old copies as well as the latest? Also amend the final message to to make it clear that one MUST redo the bundle.

Further notes.

1. The 'hostname' service doesn't seem to work - the hostname is set to 'artixlinux' rather than that specified in /etc/hostname.

2. If running 'dnsmasq', you'll find hundreds of Dbus error messages in the console log. These can be eliminated by editing /usr/share/dbus-1/system.d/dnsmasq.conf to have an extra 'allow' policy for user 'dnsmasq' (don't delete the 'root' one).

Package requests.

The following would be useful, if possible to do -
fuse-s6
netmount-s6
nftables-s6 (ideally with a 'down' as well as 'up')

Apologies for this rather long post, and for any mistakes/inconsistencies you might find.

Re: First Impressions

Reply #1
First of all, thanks for all your feedback!

2. For Dudemanguy: amend the post-transaction hook to do the database deletions based on the timestamps, not filenames. Perhaps keep 2 or 3 old copies as well as the latest? Also amend the final message to to make it clear that one MUST redo the bundle.

Good idea. I'll do this. The reason I used date was so I could generate a unique filename. When it came to deleting databases, I just wrote the script to consider the filename based on the time. But you're right, this is bad if a user goes around creating their own databases with their own names. Any suggestions on amending that message? The intention there was to make it clear that you had to redo all your service bundles, but apparently that's not clear enough. Another possibility is that I could attempt to write logic into the hook that automatically redos any bundles. It's probably not too difficult.

I could modify the database deleting behavior. Strictly speaking, I don't even have to delete them at all. The only reason was to not bloat the HDD with a ton of databases, but it's not unreasonable to leave database removal completely to the user.

And yeah, s6 is kind of complicated and a bit different. Ideally, if users just stick to what's packaged, they shouldn't have to read too much documentation, but if you're going to go around and write your own scripts, then you definitely need to be aware of what you're doing. The defaults are a little different on Artix for mostly convenience reasons (having everything lumped in /etc/s6 makes more sense).

And yes, I can look into doing those s6 packages plus fixing the hostname thing too.

 

Re: First Impressions

Reply #2
Thanks for the reply.

Any suggestions on amending that message?

Perhaps something like 'Don't forget that you must redo yours bundles before rebooting' ?

Another possibility is that I could attempt to write logic into the hook that automatically redos any bundles. It's probably not too difficult.

One other possibility that you've probably considered and rejected: ask the user to create a bundle-type service in /etc/s6/sv, with the 'contents' file having a list of the services in the bundle. This would remove the necessity of having to redo the bundles after the pacman update, but would require the user to update the 'contents' prior to running the pacman. Probably more trouble than its worth, as the user would have to know the name of the service in advance (it's not always the same as the package name).

but it's not unreasonable to leave database removal completely to the user.

Yes, possibly the best option: your documentation would have to remind the user to be careful and not delete the latest DB, though.

And yes, I can look into doing those s6 packages plus fixing the hostname thing too.

Thanks.