halt.8 is installed to the man1 folder, reboot not being built

[ahyattdev]

It is also a symbolic link to reboot.8.

[bugaevc]

Speaking of which, will you please look into making reboot actually talk to launchd to shut down the container the way it's supposed to? Last time I checked, the code is there, but we're not using it for some reason.

[ahyattdev]

Turns out that halt.8 is installed by the command line tools to man1 for some reason. Installer's fault? Not sure.

@bugaevc sure I will look into it

[ahyattdev]

@bugaevc here is what I found:

reboot interacts with launchd through the function reboot3. Interestingly, the reboot source includes the header reboot2.h but calls reboot3. On macOS, however, both reboot2 and reboot3 are exported by libxpc.dylib. I went ahead and put a stub for reboot3 in libxpc. I'm not sure what the difference between the functions reboot2 and reboot3 are. The code for getting launchd to restart should go in that newly created stub. It looks like there is an implementation for reboot2 in our launchd but there is no equivalent exported function on macOS. Maybe Apple moved it to libxpc?

[ahyattdev]

Upon calling reboot2 in reboot3 this is the output:

Darling [/home/andrewhyatt/darling/build]$ sudo reboot
libxpc reboot3 called with howto: 0
sys_proc_info(): Unsupported callnum: 7
                                       sys_proc_info(): Unsupported callnum: 7
                                                                              sys_proc_info(): Unsupported callnum: 7
                                                                                                                     sys_proc_info(): Unsupported callnum: 7
          Darling [/home/andrewhyatt/darling/build]$ sys_proc_info(): Unsupported callnum: 1

Darling then exists and calling darling shell again says it's bootstrapping with launchd, so at least launchd exits...

[yjqg6666]

When run launchctl shutdown in Darling will also get the same error 8 times.

sys_proc_info(): Unsupported callnum: 7

[HinTak]

Yes, I see the unsupported callnum too... doing that also seems to occasionally recursively wipe my /run/ (which unfortunately have external drives under /run/media connected...). See #848 .

[bugaevc]

Look, I've said it before and I'll say it again. I'm sorry that your files got deleted, that's a sad event that should not have happened 😢. But you shouldn't be blaming that on Darling.

There's no reason whatsoever to believe launchd shutdown somehow causes recursive wiping of your /run. Killing children and some logging is all it does.

It is a little bit more likely that this could be caused by either launchd startup, which does some directory wiping here, or by darling.c startup code here — at least those pieces of code are doing something close to removing a directory called /var/run. But the logic there seems to be correct, so neither shouldn touch /var/run on the host.

That, and I've been running darling.c & launchd so many times (and launchctl shutdown a few times, too), and it never had any effect on my /var/run. I think I'd notice if it was wiping it. I just tried a few cycles of darling shell, launchctl shutdown, and while, sure, there's a bunch of Unsupported callnums, it eventually shuts down, and nothing on my host gets wiped, neither on startup, nor on shutdown. I have also verified with strace that the only files removed are inside the prefix.

I'm not saying there cannot be a subtle bug that somehow causes it to misbehave on your system — there could very well be, Darling is unstable experimental software after all. But I don't think there's enough (or any) evidence for you to repeatedly blame Darling for your files disappearing.

[HinTak]

If launchd refuses to die after being given a shutdown, its attempt to restart itself, would run the start-up code, and causes the wipe.