Skip to main content
Topic: s6-rc-compile complains about missing /etc/s6/sv/{event,supervise}/type (Read 194 times) previous topic - next topic
0 Members and 2 Guests are viewing this topic.

s6-rc-compile complains about missing /etc/s6/sv/{event,supervise}/type

I tried to compile a new rc via s6-rc-compile (or rather wanted sh -x /usr/share/libalpm/scripts/s6-rc-db-update-hook to do this for me), but it complains:
Code: [Select]
[email protected] # s6-rc-compile $(mktemp -d) /etc/s6/sv
s6-rc-compile: fatal: unable to read /etc/s6/sv/event/type: No such file or directory

The upstream manual unmistakably demands
For every service

A regular file named type, that contains only the text oneshot, longrun or bundle, and a terminating newline.

Now the directories /etc/s6/sv/event/ and /etc/s6/sv/supervise/ don't have type files, and this defeats s6-rc-compile, which is a bummer.

What is wrong here?


Re: s6-rc-compile complains about missing /etc/s6/sv/{event,supervise}/type

Reply #1
What are you trying to accomplish here exactly? Every directory in the source (/etc/s6/sv) must follow the source format. So yeah if they don't have the appropriate type file, s6-rc-compile will fail. I don't know why you have directories named /etc/s6/sv/event and /etc/s6/sv/supervise in there but they didn't come from any s6 script or s6 package.

Re: s6-rc-compile complains about missing /etc/s6/sv/{event,supervise}/type

Reply #2
I'm following your advice at,1108.msg9419.html#msg9419 to make NFS _netdev mounts wait on connman at boot-up. It is a quite young, largely vanilla Artix-s6 with a few GUI packages. pacman -Qo doesn't blame any packages to own those directories.

I just revised my shell history and found that I played around with s6-supervise, which creates directories named that way. Directly in the sv tree and not in a service directory.

I removed the directories and s6-rc-compile went through. Thanks anyway, issue solved. It's a bit misleading that s6-supervise doesn't remove its helper directory even if called wrongly, but that's a cosmetic issue, close to RTFM.