znc better forks before ParseConfig #189

New Issue

2026-10-05T04:03:19+02:00

adam commented

2026-10-05 04:03:19 +02:00

ParseConfig loads modules, and some modules including mine make new threads in OnLoad.
Because of the new threads, znc can't fork to background.

Since I couldn't launch a new thread in OnLoad, the API of my module had to become much more complex.

If znc forks before ParseConfig loads modules, there is no such problem.

I think when znc is run in daemon mode, it should fork before doing anything else or very early.

--- Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/98493-znc-better-forks-before-parseconfig?utm_campaign=plugin&utm_content=tracker%2F1759&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F1759&utm_medium=issues&utm_source=github).

ParseConfig loads modules, and some modules including mine make new threads in OnLoad. Because of the new threads, znc can't fork to background. Since I couldn't launch a new thread in OnLoad, the API of my module had to become much more complex. If znc forks before ParseConfig loads modules, there is no such problem. I think when znc is run in daemon mode, it should fork before doing anything else or very early. ## <bountysource-plugin> --- Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/98493-znc-better-forks-before-parseconfig?utm_campaign=plugin&utm_content=tracker%2F1759&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F1759&utm_medium=issues&utm_source=github). </bountysource-plugin>

adam commented

2026-10-05 04:03:20 +02:00

+1

+1

adam commented

2026-10-05 04:03:21 +02:00

If ZNC was to fork first, then modules wouldn't be able to abort the startup and show the user any error. Such as the away module with missing encryption passwords.

If ZNC was to fork first, then modules wouldn't be able to abort the startup and show the user any error. Such as the away module with missing encryption passwords.

adam commented

2026-10-05 04:03:21 +02:00

I think, logic of OnBoot() should be refined, as it's done especially for the case of ZNC startup.

I think, logic of `OnBoot()` should be refined, as it's done especially for the case of ZNC startup.

adam commented

2026-10-05 04:03:22 +02:00

Wouldn't it be enough to move the block https://github.com/znc/znc/blob/master/src/main.cpp#L269-274 down after https://github.com/znc/znc/blob/master/src/main.cpp#L331?

(I have the same problem that I can't run my znc in background)

Wouldn't it be enough to move the block https://github.com/znc/znc/blob/master/src/main.cpp#L269-274 down after https://github.com/znc/znc/blob/master/src/main.cpp#L331? (I have the same problem that I can't run my znc in background)

adam commented

2026-10-05 04:03:23 +02:00

@Kriechi Try that and test what happens when you have an error in the config (e.g. just add Foo = Bar). The output on the console will be mangled, because the shell prints the prompt while znc is still starting up and only afterwards does it print its error messages.

So this would need a way for the parent process to wait until startup is done. E.g. we could create a pipe, give it to the socket manager and close it in the "after write" mode. That way, the socket manager will automatically close that pipe when it start running aka "when startup is done". The parent process can then wait for EOF on that pipe.

If anyone wants to actually implement this, feel free.

Oh and while you are at it: I just noticed that my above example doesn't work, since we redirect stdout and stderr to /dev/null while forking. So forking now becomes a two-step process. First we have to actually fork and only later can the redirecting and setsid() be done.

So nope, just moving that code around is not enough.

@Kriechi Try that and test what happens when you have an error in the config (e.g. just add `Foo = Bar`). The output on the console will be mangled, because the shell prints the prompt while znc is still starting up and only afterwards does it print its error messages. So this would need a way for the parent process to wait until startup is done. E.g. we could create a pipe, give it to the socket manager and close it in the "after write" mode. That way, the socket manager will automatically close that pipe when it start running aka "when startup is done". The parent process can then wait for EOF on that pipe. If anyone wants to actually implement this, feel free. Oh and while you are at it: I just noticed that my above example doesn't work, since we redirect stdout and stderr to /dev/null while forking. So forking now becomes a two-step process. First we have to actually fork and only later can the redirecting and `setsid()` be done. So nope, just moving that code around is not enough.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: adam/znc#189