CNC Draw Low FPS Games

Will games set to CNC Draw run better and load faster after starting any game the fps drops even in 3D and the image in the game itself freezes, jumps in some games and some games do not work at all after pressing the game icon twice only a black screen flashes and nothing happens
https://github.com/user-attachments/assets/1e89ec7c-af6c-4676-a4d9-eb29ede5a083

Not sure what you're talking about. Is this about winlator?
Anyways, cnc-ddraw can't be used for 3D games. It's only for old 2D games (circa 1996-2006)

@FunkyFr3sh look video

That is a 3D game and it looks like it was released in 2004. So it could be Direct3D9 and might work with DXVK. If it's Direct3D8 then you might need to use WineD3D,

@FunkyFr3sh I've tried everything and it's still the same

I can't really help you with that one. Some games just don't work in wine, so it might not be possible to run it.

@FunkyFr3sh it's a pity and I thought I would play and here's a button maybe winlator will launch all games on pc in the future


UI Updates

Changed the website's color scheme. Added in more icons to make it seem more homey. Changed the permissions text to talk to the user instead of acting as if it were the user. Fixed a good amount of CSS and HTML that was out of place which messed up the html workflow.

Dude, it's sick! Gotta love the OCC colors. Deploying to PROD in 3....2....1.....

It's live @westl


Crash Could not find class 'android.media.projection.MediaProjectionManagerTargetApi(21) Lower than Android5.0

public class TestModule extends ReactContextBaseJavaModule{
super(reactContext);
MediaProjectionManager mMediaProjectionManager = (MediaProjectionManager) getReactApplicationContext().getSystemService(Context.MEDIA_PROJECTION_SERVICE);
}
}

Hey, thanks for reporting this issue!
It looks like your description is missing some necessary information, or the list of reproduction steps is not complete. Can you please add all the details specified in the template? This is necessary for people to be able to understand and reproduce the issue being reported.
I am going to close this, but feel free to open a new issue with the additional information provided. Thanks!


“Download Kubernetes” section has no download link

https://github.com/kubernetes/website/issues/21063
/language zh

/close


help ,thanks

I try to use my data to train, but there is a ValueError:
Cannot feed value of shape (45, 7, 7, 25) for Tensor 'Placeholder:0', which has shape '(?, 7, 7, 6)'
I want to know how to solve,thanks

You haven't specify batch size. 45 represent Batch size defined in config.py file


Unexpected brackets are not colored in Light High Contrast theme

Does this issue occur when all extensions are disabled?: Yes

VS Code Version: 1.92.0
Commit: b1c0a14de1414fcdaa400695b4db1c0799bc3124
Date: 2024-07-31T23:26:45.634Z
Electron: 30.1.2
ElectronBuildId: 9870757
Chromium: 124.0.6367.243
Node.js: 20.14.0
V8: <IP_ADDRESS>-electron.0
OS: Linux x64 6.9.3-76060903-generic

Steps to Reproduce:

Switch theme to Light High Contrast
Open a Javascript file
Type []]
The final bracket ] is black, not red as in other themes

I believe this may be the core cause:
https://github.com/microsoft/vscode/blob/7c2a097c6a482d70dfb8756ff9f8015357b8a2ed/src/vs/editor/common/core/editorColorRegistry.ts#L83
The value for hcLight here is just an empty string

@MichaelMakesGames Thanks for investigating, looks like this color got forgotten when creating the Light HC theme.
@daviddossett I took the same color as used in the overview ruler


[Feature Request] Add setting to hide and show "free slots".

Currently, free slots display as this in the bags:

The problem with this is that aesthetically it can be bothersome, and some users use things like ElvUI datatext to show their bag spaces.
There should be a few options as a multi-choice toggle added that let the user decide where bag spaces are, eg:

Hidden (completely hidden)
Reagent Hidden (only show normal bag slots)
Combined (Make the bag slot show all spaces combined including reagent as one bag)
Replace Header (Replace the "backpack" text with bag space text.
Next to Gold (Add text right aligned next to gold, sort of like how Adibags does it.

Can simplify it by only posing simple options on this firsthand, like just a simple "hidden" and "shown" setting for now.
I would also suggest in the default, current bag view, to make it so the slots that show as "free slots" have a neat icon that differentiate bag and reagent bag space, instead of looking like empty spaces. It's a little aesthetic design choice, even something as simple as a slightly different color for each of them would be a difference. They otherwise look the same, even with the border changes that are very hard to see.

These features will not be implemented. BetterBags' goal is not to be a bag that fits every possible person's personal preference. Most of these requests go against the design philosophy of BetterBags.
Eventually, there will be accommodations for themes (such as detecting ElvUI and applying ElvUI skins), but in general, options are kept clean and minimal as far as bag layout goes.
In the future, I may reconsider some of this, but that's well over a year away, if ever.
Thanks!

Sounds good. I would just recommend having a hide/show for the free slots, then.


Add c++ and python local deploy example

Issue:
Currently there is no an example to show how to deploy VTA with c++ and no example for python local deployment.
Solution:
This patch is the example to show how to deploy vta with c++ and python in local.

Very exciting development @huajsj ! I'm looking forward to the C++ example!

@tmoreau89 , thanks for the kindly follow up, the code& test done, if you have time, could you help to have a review?  Thanks.

@tmoreau89 , all review comments get addressed, please kindly check.

@tmoreau89 , could you help to review this patch again? Thanks
Regards
Hua

Thanks so much @huajsj the PR has been approved and merged.


New Feature: Propagate Exception type to recovery methods

Hello,
At this moment with mutiny while handling a failure event for a checked exception its not possible know the actual type because the recovery methods work with Throwable, so a casting is required to be able to access custom types.
I wold like to purpose a modification, if its possible, to propagate the actual type of the exception to the event handlers to do not have to rely on casting to access custom properties, or to have type-safety while handling the exceptions. This could be handy while dealing with scenarios where you have a hierarchy of Exceptions or other types.
Thanks.

I've just been hit by this, so here's an example:
    @Channel("warehouse")
    MutinyEmitter<Order> kafkaEmitter;

    private Uni<Void> sendToKafka(Order order) {
        kafkaEmitter.send(order)
            .onFailure(Exception.class)
// ERROR: because e is of type Throwable, even though in my case it must be a sutype of Exception
             .transform(e -> new Exceptions.KafkaException(e));
    }

    public static class KafkaException extends RuntimeException {

        public KafkaException(Exception cause) {
            super(cause);
        }
    }

It would be nice to investigate if we can make this better.

I had an idea to do it by adding a type parameter to the OnFailure groups (Uni and Multi) and OnItemOrFailure (Uni only). As it is a breaking change, I had to postpone it.
I will chat with @jponge to see if it's acceptable.

I had tried that as well a while back, but it was quite intrusive and breaking. Let's revisit.


this is an error when delpoyed beego project on centos7

[ORM]2018/08/20 16:44:25 register db Ping default, Binary was compiled with 'CGO_ENABLED=0', go-sqlite3 requires cgo to work. This is a stub
must have one register DataBase alias named default

#!/bin/bash

# Set CGO_ENABLED environment variable
export CGO_ENABLED=1

# Compile Go script
go build -o output_binary_name source_file.go

# Replace output_binary_name with the desired name for the output binary file
# Replace source_file.go with the name of your Go source file

# Run the compiled binary
./output_binary_name

# Remember to replace output_binary_name with the actual binary name if you changed it


direct support for letsencrypt certificate rather than znc.pem

Having to regenerate znc.pem (http://wiki.znc.in/Signed_SSL_certificate#LetsEncrypt) each time you renew a letsencrypt certificate rotates is annoying. It would be great if znc supported reading the letsencrypt certificate directly.

---
Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/31421197-direct-support-for-letsencrypt-certificate-rather-than-znc-pem?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).

i think ive seen people on the LetsEncrypt github talk about adding alternate output methods for things such as lighttpd,znc,etc. this might be more of a letsencrypt issue than a znc one.
maybe you need to utilise some of the scripts that are out there or write some bash to add generating the znc.pem to your certificate renewal process. and the znc.pem can be anywhere, SSLCertFile in znc.conf just needs  to point to it

Even if LetsEncrypt supported ZNC directly, it would be useless because of #1215 and ZNC not supporting running as root or even dropping out of root.

Sure, but these all sound like workarounds. It would be nice if znc could support them directly without needing scripts to create znc.pem.

And I just remembered this is already done or is https://github.com/znc/znc/pull/1192 not what you are asking?

Ah, that does look like what I'm after, thanks!


WebDriverException error

Is there an existing issue for this?

[X] I have searched the existing issues

I'm submitting a ...

[X] bug report
[ ] feature request
[ ] support request --> Contact me over mail for support https://github.com/MShawon

Description
what is the solution of WebDriverException error,

Environment
- OS : windows 10
- Python : 9.9.4
- Script version : latest

config.json
{
    "http_api": {
        "enabled": true,
        "host": "<IP_ADDRESS>",
        "port": 5000
    },
    "database": true,
    "views": 500,
    "minimum": 85.0,
    "maximum": 95.0,
    "proxy": {
        "category": "r",
        "proxy_type": "http",
        "filename": "p1",
        "authentication": false,
        "proxy_api": false,
        "refresh": 0.0
    },
    "background": false,
    "bandwidth": false,
    "playback_speed": 1,
    "max_threads": 5,
    "min_threads": 2
}

Same here using latest / Win serv 2016

I'm having the same problem, anything I can do to fix it?

OS : windows 10
Python : 3.8.10
Script version : latest

Chrome version: 107.0.5304.122 64 bits

It's because your config.json isn't correct
@sdaqq1 in config.json change category to f from r
@El-Idiota @kobisystem send ur config.json

@MShawon, My Config (Os: win server 2016 / Script version: latest / 200 http proxy) :
{
"http_api": {
"enabled": true,
"host": "<IP_ADDRESS>",
"port": 5000
},
"database": true,
"views": 100,
"minimum": 68.0,
"maximum": 95.0,
"proxy": {
"category": "p",
"proxy_type": "http",
"filename": "2022.txt",
"authentication": false,
"proxy_api": false,
"refresh": 0.0
},
"background": false,
"bandwidth": true,
"playback_speed": 1,
"max_threads": 5,
"min_threads": 4
}

@El-Idiota  How come with proxy category p authentication is false? did you change it? your proxies have username and password?

yeah, private proxy list, with server IP authentication, so no username and password.

Getting the same error on Debian
Config as follows:
{
"http_api": {
"enabled": true,
"host": "<IP_ADDRESS>",
"port": 5000
},
"database": true,
"views": 1000,
"minimum": 85.0,
"maximum": 95.0,
"proxy": {
"category": "f",
"proxy_type": false,
"filename": "GoodProxy.txt",
"authentication": false,
"proxy_api": false,
"refresh": 0.0
},
"background": false,
"bandwidth": false,
"playback_speed": 1,
"max_threads": 10,
"min_threads": 5
}

@4ssil  "proxy_type": false, ???!!!
meine config
"proxy_type": "http",
"filename": "http://localhost/proxy/1.txt",

I had the same issue and found that adding options.add_argument("--headless=chrome") to the get_driver function within the basics.py file worked for me...I'll submit a PR

nvm, thats not a good fix since we dont want to run in headless mode

Hey, is there word on this issue, I'm getting a similar error: Line : 677 | WebDriverException
Here's my config:
{
    "http_api": {
        "enabled": false,
        "host": "<IP_ADDRESS>",
        "port": 5000
    },
    "database": true,
    "views": 10000,
    "minimum": 20.0,
    "maximum": 65.0,
    "proxy": {
        "category": "p",
        "proxy_type": "http",
        "filename": "proxy_list.txt",
        "authentication": true,
        "proxy_api": false,
        "refresh": 0.0
    },
    "background": false,
    "bandwidth": false,
    "playback_speed": 1,
    "max_threads": 15,
    "min_threads": 15
}

Looks like this is the real error for me:
Message: unknown error: Chrome failed to start: exited abnormally.
  (unknown error: DevToolsActivePort file doesn't exist)
  (The process started from chrome location /usr/bin/google-chrome is no longer running, so ChromeDriver is assuming that Chrome has crashed.)

Going to investigate and let folks know how it goes.

Okay , so I figured it out. I'm running on an aws ec2 instance linux, which doesn't have display hardware and you can't run premium proxies on headless, which makes sense.
So basically I followed these instructions:

https://stackoverflow.com/questions/50642308/webdriverexception-unknown-error-devtoolsactiveport-file-doesnt-exist-while-t

https://stackoverflow.com/questions/8805032/xvfb-run-error-in-ubuntu-11-04

I get the same error in Ubuntu
[18-Jan-2023 02:14:30] | 75.0%  | Worker 1 | Line : 676 | WebDriverException |


Add support for OpenAPI v3

I was not able to find a similar issue requesting this, so consider it requested :)

hey @josephgardner! we totally agree. we are working on OAS 3 support for the whole Stoplight platform in Q2. we are working hard to release the next version of Stoplight, which is a major platform update, and then this will be the next thing we turn our focus to.

Hey there @tbarn, any update on this? It's Q3, and it's almost a year since OpenAPI v3 came out. :)

@philsturgeon I was mostly away from my laptop this week, so I am just getting back to this. Let's talk about what it would take to upgrade it - part of it requires an update to one of the Golang libraries we are using.

@tbarn no worries! Which library specifically, and what does it need to have done? Point me at some stuff and if I can handle the Go I'll do it, otherwise I'll try and find some people that can. We've got a bunch of go developers here at WeWork recently, and they'd be happy to get mock servers.

@philsturgeon prism uses go-openapi/spec to load in oas files, it looks like someone has started working on it, but I am sure he would love the help. Here is the issue https://github.com/go-openapi/spec/issues/21

Awesome news that a new v3 parser is in the works over there. I've subscribed to the issue, and once the dust has settled on that issue and an implementation has been chosen/merged/etc., I'll point some of the Go people at it to see if they can help.

Any updates on supporting OAS3 anytime soon?

Why not use https://github.com/getkin/kin-openapi ?

Hi, any update for OpenAPI v3 support in stoplight.io?

There's been a lot of progress on it with other improvements. You can see the work in the develop branch. We are aiming for an early release in 2019.

Yes, mocking, test requests can go through it, contract testing, etc. We'll be rolling out OAS3 support feature by feature, versus doing it all at once. Near-term, we are focused on getting it into the code editor and having validation/linting for OAS3 files, which is pretty much done but not released. Then things like visual editing, mocking, contract testing, etc will come.
TL;DR Prism standalone will have support first, then it will get added to the larger Stoplight platform.

hey, a quick update about the progress would be awesome 🤗 Don't wanna start with OAS2 if prism is going to support OAS3 any time soon 🤗

@daKmoR  Current Status: All over it like chips on gravy.

The team has been working incredibly hard on the fantastic new version of Prism (which is a total rewrite from v2), and we'll be poking a few brave beta testers to give it a spin shortly. We need to sort out some installation docs and other things to make sure the beta testers aren't going in completely blind.

uh awesome sign me up for chips and the beta :)
I will make sure to bring my own torch just in case :p

Great! Me too interested to the beta, thx

Hi guys !
So do I. I can't wait to test this !

Thanks! I have you down for the Prism Beta group :) Be on the lookout! :)
On Sun, Mar 10, 2019 at 5:46 AM Nicolas TISSERAND<EMAIL_ADDRESS>wrote:

Hi guys !
So do I. I can't wait to test this !
—
You are receiving this because you are subscribe to this thread.
Reply to this email directly, view it on GitHub
https://github.com/stoplightio/prism/issues/130#issuecomment-471276581,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AK6b0JDUtcTiign2EKv2yDOULmP1p_zCks5vVOKVgaJpZM4R9IyZ
.

Bet'a me too, thank you!

Me too, please ❤

Making good progress over here! We just updated to the latest version of Graphite (#191) which means we now support OpenAPI v2.0 in both JSON and YAML, and we support $ref. Before this was merged it was just JSON and no ref support. 😅
OpenAPI v3.0 support to Graphite is a priority in the next sprint, so then Prism will get v3 support from that. Progress! :D

Please add me to the beta group too, thanks!

I would love to be in the beta group if possible, thank you!

Hi, Gopher here - any of the Go parts open sourced and needing help? Also happy to help test this in beta.

@gnanderson thank you so much for offering, but v3 is entirely TypeScript! As a gopher myself I´ve found working in TypeScript to be pretty familiar, especially as somebody else went to all the trouble of setting it up. 😅
Check out the develop branch and the open issues if you are interested in contributing.

If there are any extra spots left in the beta group, I would like one please :)

@daKmoR Current Status: All over it like chips on gravy.

The team has been working incredibly hard on the fantastic new version of Prism (which is a total rewrite from v2), and we'll be poking a few brave beta testers to give it a spin shortly. We need to sort out some installation docs and other things to make sure the beta testers aren't going in completely blind.

Hi @daKmoR we are making a decision on what system to use this week but a requirement of our company is to use OpenAPI 3. Would you be able to send me an invite to the beta group?
Thnx!

🥁 🥁 🥁 🥁
Done!
🎺 🎺 🎺 🎺
Keep an eye on #266 for updates on alpha. As always people are welcome to much around with the develop branch but no promises on stability, don't put that code in prod, etc. 👍


Add option to have json output for the keptn cli get command

Is your feature request related to a problem? Please describe.
I would like to have ability to use the keptn get command output in scripts.  Right now the output is 'human readable'.
jahnadmin@jahn-keptn-070-2:~$ keptn get service
NAME			PROJECT		STAGE		CREATION DATE
simplenodeservice	demo		dev		2020-07-30T14:59:19Z

Describe the solution you'd like
Like we can do with kubectl, just add option like -o json to have the results be in json format.  For example:
{
	"projects": [{
		"projectname": "demo",
		"stages": [{
			"stagename": "dev",
			"services": [{
				"service": "abc",
				"service": "xyz"
			}]
		}]
	}]
}

Describe alternatives you've considered
None
Additional context
Also see the feedback to the improving the output naming in this issue.  https://github.com/keptn/keptn/issues/2152.

Hi @robertjahn
actually this feature is supported. (Please see: https://keptn.sh/docs/0.7.x/reference/cli/commands/keptn_get_service/#options)
Just add the --output=json|yaml flag (short form: -o) to your command.

Very good, I see it now in the CLI help running keptn get service --help.  I had just done keptn get  --help.  I will close this issue.


Todyr: error in drop_na() description

In the tidyr cheatsheet, the section "Handle Missing Values" lists a function s() instead of drop_na() while the example code does show drop_na() correctly

Addressed in #330


🐞 : Issue in border radius of Button , Background Color of Card.

Issue in border radius of Button , Background Color of Card.
I want to add border radius in slide more button through which user experience is good.
When we hover on projects Card text is not  user friendly visible alongwith color is not good on hovering.

Rupesh Varshney
GSSOC-ext 24 Contributor
pls add label gssoc-ext, hacktoberfest-accepted

Can you assign this issue to me?

@iamrahulmahato sir assign me so that I can work on that

@iamrahulmahato Sir can i start work?
Pls Reply ASAP so that i start work asap


TV Show content_ratings

Maybe I am missing something, but I think we are missing /tv/{id}/content_ratings.
I ultimately want the tv shows rating (ex. TV-MA)
Do we need another MovieMethod?
Thank you for your work!

This is something that seems relativly new. It's going to be an additional method that needs to be added to the tv show this. Shouldn't be too much work, I'll see if I can make some time for it tomorrow or in the weekend.

added the new call and a few others to the wrapper

Thank you very much!


MQ Consumer in Light4j Client

Hi NetworkNt Team,
Is there any standard light4j module which can be used to consume messages from MQ.
Thanks
Sathish

This has been done and the repo is not open-sourced due to the dependency is licensed MQ client jar. If anyone wants to connect to MQ from light-4j services, let us know. Thanks.


wiki page for turning on debug and providing logs

We should write a wiki page to refer people to so we don't have to type it out every time we need to ask for debug logs

Now he wants the wiki 😂. Yeah we probably should.
On Fri, 2 Apr 2021, 2:06 pm Brian Hayden, @.***> wrote:

We should write a wiki page to refer people to so we don't have to type it
out every time we need to ask for debug logs
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/Misunderstood-Wookiee/Mules-and-Warehouses-Extended/issues/114,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AFH3SZ6TVJKDCJXEH3LSNBDTGUYCXANCNFSM42IFC44Q
.

I have some mods to update for 5.0 after which I don't see why I can't write some tutorials for this and various ways to go about doing this.

I dug around in the code a little to find out why my mules weren't playing nice and have some updates to the wiki that I would like to post.

Sounds great! I haven't played X4 in a really long time

I need access to the wiki then. Forking the project does not fork the wiki, and while there are workarounds, it is easier just to give write access to the wiki directly.

I need access to the wiki then. Forking the project does not fork the wiki, and while there are workarounds, it is easier just to give write access to the wiki directly.

I need access to the wiki then. Forking the project does not fork the wiki, and while there are workarounds, it is easier just to give write access to the wiki directly.

See if this works for you I have unrestricted the Wiki


Firestore: Fix global refs exhaustion issue in Android

This is the second part of a proper fix for the global refs exhaustion issue tracked by https://github.com/firebase/firebase-unity-sdk/issues/569, and reported in https://github.com/firebase/quickstart-unity/issues/1303 and https://github.com/firebase/quickstart-unity/issues/1193#issuecomment-1242203289 (Googlers see b/251869890 for more details). Part 1, a partial mitigation, was https://github.com/firebase/firebase-cpp-sdk/pull/1111.
This PR supersedes, and builds upon the work done by @cherylEnkidu in, https://github.com/firebase/firebase-cpp-sdk/pull/1176.
TODO(dconeybe)

Profile HashMap vs. LongObjectHashMap on an old KitKat device
Add tests that verify the size of the ObjectArena
Finish unit tests for ArenaRef
Merge changes not specific to ArenaRef in separate PRs

The Android tests are failing due to incomplete unit tests that have been hardcoded to fail. They can be ignored.

I've kicked off a build of the Unity SDK for customers to test out to see if it fixes their crashes: https://github.com/firebase/firebase-unity-sdk/actions/runs/4999199986

Moved to https://github.com/firebase/firebase-cpp-sdk/pull/1364


Dark mode bug for Drop Down & Filter combos

-->
I'm submitting a...

[x] Bug report
[ ] Feature request
[ ] Documentation issue or request

Current behavior
When using dark mode the combo Drop box & Filter is shown in light mode
Expected behavior
Should be shown in dark mode
Minimal reproduction of the problem with instructions

What is the motivation / use case for changing the behavior?

Looks like this is not an iX component. It looks more like ng-select (https://github.com/ng-select/ng-select)


Highlight selected layer

Adds a toggle button to the right of the layer list which will highlight the current layer in the tilemap. This mirrors the behavior of the built-in tilemap system.

This is not a perfect solution. Internally in Godot, there's a nice TileMap::set_selected_layer() function which the built-in system uses. Unfortunately, this function isn't exposed to the user.
Instead, this PR modifies the layer modulate properties directly. It properly resets the modulates when disabled or when navigating away from the TileMap, but it may have other unintended behavior (for instance, testing the project while the toggle is enabled will cause layers to be darkened/faded in-game, closing the project will keep the modified modulates, manual layer modulate changes won't be kept unless untoggled first, etc.).
So I'm not sure that this PR should be merged in its current state.
I find it useful for my own sake, but I also know to make sure to disable the toggle when appropriate. I'm not sure how to better implement this without that internal function exposed (maybe there's a way to call it that I don't know about). But I'm submitting this in case you or anyone else has any input.

Oh snap, I was just working on this exact thing, but with a different approach. I was searching into the godot built-in UI to find the layer and highlight buttons. Then, I can make buttons that stay synced with those, as a roundabout way of accessing the internal functions. It will also keep the layer settings consistent with the tilemap tab.

The built-in TileMap editor instantiates its layers and highlight button here:
https://github.com/godotengine/godot/blob/83cc5d4914a6bff76069ac19191192337e4df3de/editor/plugins/tiles/tile_map_editor.cpp#L4041-L4054
Which gets read here:
https://github.com/godotengine/godot/blob/83cc5d4914a6bff76069ac19191192337e4df3de/editor/plugins/tiles/tile_map_editor.cpp#L3715
And the styles are applied here:
https://github.com/godotengine/godot/blob/83cc5d4914a6bff76069ac19191192337e4df3de/scene/2d/tile_map.cpp#L1198-L1208

Yup. The only obstacle is that the tile map editor repeatedly makes a is_visible_in_tree check, and disables all selection highlighting when it isn't visible. If I can find a way to trick it into thinking it is visible, then it should work... but it's a bit tricky/hacky.

Ooh I see, you mean interacting with the existing UI directly. That's an interesting idea.
Yeah that might be the way to go for now, if there's a stable way around that issue.

After a lot of experimenting, there doesn't appear to be a clean way of doing this. The options are:

Find an unknown way of making the tile map editor believe it is visible (e.g. by making it visible, but messing with the sizing, or proxying it through a subviewport somehow), and using or proxying its own controls.

Mimicking the behaviour as you have done, which causes a lot of issues with the editor retaining editor-only settings as permanent. Perhaps these issues can be worked around, but it's a really tricky situation with many edge cases.

Writing a GDExtension that allows access to the specific internal function, and then loading that. I don't like the idea of preparing and providing builds for every platform, though. On the plus side, it would also give an opportunity to make a compiled version of BetterTerrain.gd which would be significantly faster.

Propose that this functionality is exposed by the Godot devs. This won't happen, though, because it's not a good idea, and there is no drive to improve the state of the autotiling system in Godot 4.

Restructure the better terrain dock so that it presents as an alternate tab inside the TileMap tab, thus allowing the existing controls to function as presented. This might honestly be the best bet.

I also have been playing around with the 1st option you listed, and I got it to a state that's pretty good, take a look:
https://github.com/torcado194/better-terrain/tree/layer-highlight-hack-test

This is just a proof of concept of keeping the TileMapEditor visible, it doesn't link the layer switching or anything, that can be added latter.
What I'm doing is finding the TileMapEditor and reparenting it to BetterTerrain's dock when the dock becomes visible, and moving it back when it loses visibility. (And also grabbing its panel button, etc. for fixing visibility and tab navigation edge cases)
Other than the ones I've fixed, I haven't found any edge case issues with this so far.
The TileMapEditor is being placed in a panel in the dock, and the panel can be moved off-screen easily (e.g. off to the left). it's there for now just to show what's going on.
There may be much better ways of grabbing the TileMapEditor panel, etc. I'm interested in seeing your methods. Either way, feel free to mess around with that

Awesome, looks great! Yeah, find_children is a much better method, really highlighting my lack of Godot experience haha.
Small edge case on your branch I had to handle on mine, clicking a currently visible Terrain tab to close it will reveal a small Tilemap dock, when the bottom panel should be closed entirely. Here's a fix for that:
https://github.com/Portponky/better-terrain/compare/layer-highlight-hijack...torcado194:better-terrain:layer-highlight-hijack
Other than that I can't find any issues from testing!

Hmm, that helps but there are definitely more edge cases, especially when switching between different tilemap nodes.
I have another idea to simplify the whole process. I made a container based on VBoxContainer, which assumes control of the tile map editor whenever it becomes visible. This then replaces the tilemap dock, so there is no need to attempt to reparent or reorder docks. The proxy moves the dock around seamlessly.
This method does work, and is a lot less code, but it spits out a Godot error into the Output tab constantly. Now, if I can clean it up so the error stops happening...

Switching between tilemap nodes causes the bottom panel dock to switch back between TileSet and TileMap in either version of BetterTerrain, regardless of this change, so maybe I'm misunderstanding.

The switching between TileSet and TileMap happens in Godot 4 without any plugin, it's a Godot bug(?) or weird behaviour. This means there are multiple hidden states the tile system can be in. This is why there are edge cases that are hard to reproduce: it's not just clicking from one dock to another (or one tilemap node to another), but also the hidden state of the built-in tile editors.

Right, I guess my point is that's not an issue with the current solution to this problem (and that the small change I proposed is a fix to an issue with that solution to this problem). I got the impression you were exploring alternative solutions because of that edge case that is totally separate to these changes.
Regardless, I think that solution is totally fine. I haven't encountered any (internal) issues and it feels exactly as I'd expect the feature to work.

I've thought about this for a while as I've been away for a few days. Ultimately, I am not particularly happy with a solution that involves hacking the editor apart. In my testing, it can lead to UI problems and even crashes, especially when doing stuff with multiple tilemaps or other plugins. I'm just testing it on linux in a very controlled way, when it's out there in the wild, it will potentially be run on a lot of different systems with much more complex scenes and a whole ecosystem of other plugins and addons. Stability is of high priority. So, for now, I'll hold off on this PR.
However, I really want this feature, as it's a very important usability tool.
My next step will be to open a proposal for Godot to expose the functionality to use this feature for editor tools. I'm not exactly sure how that would be achieved, but it's very disappointing there is functionality built into the nodes that we can't access. I know that at least two other people developing tilemap plugins have found this to be troublesome.

That's understandable, I think asking Godot to expose the functionality is the ideal solution. For now, I'll probably have one of these two solutions running anyway locally. I think (for the sake of stability) the original solution in this PR may be better than none at all in the meantime, but that's up to you.

Closing, now implemented in 4.3 after properties were exposed in engine.


WebGUI: can't bind to socket: <IP_ADDRESS>:443: Address already in use

Important notices
Before you add a new report, we ask you kindly to acknowledge the following:

[X] I have read the contributing guide lines at https://github.com/opnsense/core/blob/master/CONTRIBUTING.md
[X] I am convinced that my issue is new after having checked both open and closed issues at https://github.com/opnsense/core/issues?q=is%3Aissue

Describe the bug
After some time running opnsense I'll get a "503 - service unavailable" error when trying to access the WebGUI. Opnsense itself seems to still do its job, however the WebGUI is gone.
Killing lighttpd and restarting services via console solves it (as mentioned here: https://forum.opnsense.org/index.php?topic=32540.0)
I noticed this after the last upgrade.
To Reproduce
Steps to reproduce the behavior:

Run below mentioned version
Wait a few days
Try to access WbGUI
See error

Expected behavior
Would expect regular WebGUI operation and login window.
Describe alternatives you considered
Relevant log files
As in Forum post mentioned, I found the below part in the logs as well. Could not spot any other error related to webgui.
2023-02-20T07:20:07	Error	opnsense	/usr/local/etc/rc.restart_webgui: The command '/usr/local/sbin/lighttpd -f /var/etc/lighty-webConfigurator.conf' returned exit code '255', the output was '2023-02-20 07:20:07: (network.c.537) can't bind to socket: <IP_ADDRESS>:443: Address already in use'
Environment
OPNsense 23.1.1_2-amd64
FreeBSD 13.1-RELEASE-p6
OpenSSL 1.1.1t 7 Feb 2023
AMD GX-412TC SOC

HAProxy or Nginx perhaps? I don’t think that happens in a default install.
Cheers,
Franco

Interfaces : Diagnostics : Netstat, go for Ports or Protocol and search for 443

sockstat -l | grep :443
will give (ipv6 removed)
root     lighttpd   29089 6  tcp4   <IP_ADDRESS>:443         *:*
root     lighttpd   29089 7  tcp6   ::1:443               *:*
root     lighttpd   29089 8  tcp4   <IP_ADDRESS>:443       *:*
root     lighttpd   29089 9  tcp6   <xxx>:443 *:*

However this probably only makes sense, after lighttpd actually can't restart?

Does acme client also handle the web GUI certificate? Or if there is still a process it probably hangs doing "something' although it seems new to me. Selecting specific interfaces also doesn't help in general, but is probably not causing it.
Cheers,
Franco

It seems to use lighttpd
https://github.com/opnsense/plugins/blob/df1b28335d17f4fd2b4060b3b8df731bd2c567ca/security/acme-client/src/etc/rc.d/acme_http_challenge#L27
Best check the proceslist first
ps fax | grep lighttpd

Best regards,
Ad

..but acme lighty instance not using standard port by default and not using SSL
could it be just gui reload on 'newwanip' and lighty just did not terminated gracefully?
then there should be some errors in the Web GUI log before the mentioned general log error

I am not sure if it is acme. I checked the logs. The lighttpd error from above occours at 5am daily and 7am on Mondays.

5am is my pppoe daily reset for DSL
7am is my weekly firmware update check

acme on the other hand is at midnight daily.
Around that lighttpd error at 5am there is multiple other errors, but hard to figure what is relevant.
siproxd (expected as network is reconnecting):
2023-02-20T05:00:01+01:00 opnsense.<xxx>.de siproxd 92666 - [meta sequenceId="1"] sock.c:445 ERROR:sendto() [<xxx>:5060 size=1082] call failed: Network is unreachable
prefixes.sh:
2023-02-20T05:00:12+01:00 opnsense.<xxx>.de opnsense 24088 - [meta sequenceId="44"] /usr/local/etc/rc.newwanipv6: The command '/usr/sbin/daemon -f -p '/var/run/dhcpleases6.pid' '/usr/local/opnsense/scripts/dhcp/prefixes.sh'' returned exit code '3', the output was 'daemon: process already running, pid: 17697'
radvd:
2023-02-20T05:00:12+01:00 opnsense.<xxx>.de opnsense 75150 - [meta sequenceId="45"] /usr/local/etc/rc.newwanipv6: The command '/usr/local/sbin/radvd -p /var/run/radvd.pid -C /var/etc/radvd.conf -m syslog' returned exit code '255', the output was ''
ntpd:
2023-02-20T05:00:30+01:00 opnsense.<xxx>.de opnsense 75150 - [meta sequenceId="151"] /usr/local/etc/rc.newwanipv6: The command '/usr/local/sbin/ntpd -g -c '/var/etc/ntpd.conf'' returned exit code '1', the output was ''
mount:
2023-02-20T05:00:31+01:00 opnsense.<xxx>.de opnsense 75150 - [meta sequenceId="156"] /usr/local/etc/rc.newwanipv6: The command '/sbin/mount -t devfs devfs '/var/unbound/dev'' returned exit code '1', the output was 'mount: devfs: Device busy'
2023-02-20T05:00:31+01:00 opnsense.<xxx>.de opnsense 40336 - [meta sequenceId="157"] /usr/local/etc/rc.newwanipv6: The command '/sbin/mount -r -t nullfs '/usr/local/lib/python3.9' '/var/unbound/usr/local/lib/python3.9'' returned exit code '1', the output was 'mount_nullfs: /var/unbound/usr/local/lib/python3.9: Device busy'
then there is lighttpd:
2023-02-20T05:00:36+01:00 opnsense.<xxx>.de opnsense 40336 - [meta sequenceId="174"] /usr/local/etc/rc.newwanipv6: The command '/usr/local/sbin/lighttpd -f /var/etc/lighty-webConfigurator.conf' returned exit code '255', the output was '2023-02-20 05:00:36: (network.c.537) can't bind to socket: <IP_ADDRESS>:443: Address already in use'
at 7am, there is only the lighttpd error.
I can also provide a full log, if that helps you.

@chris42 sorry, just to clarify, so you can reproduce this issue on every "Periodic interface reset" cron job?

Yes and no. I can reproduce the lighttpd error in every "Periodic interface reset" cron job and the "Automatic firmware update" one. However it does not lead to the "503 - service unavailable" error right away. It seems that it takes a while until lighttpd is broken.

@chris42 thanks! one more question: is  Web Server Log enabled? (System: Settings: Logging)
would be interesting to see the lighty logs.
imho can't bind to socket error itself cannot cause an 503 response. it feels like something is killing fastcgi while lighty is running .. I haven’t figured out how this is possible yet, but I managed to reproduce it once using the "Automatic firmware update" job: instead of "server stopped" and "server started" messages, lighty throws (gw_backend.c.369) child signalled: 1 then tries to reestablish fastcgi connection ((gw_backend.c.274) establishing connection failed: socket: unix:/tmp/php-fastcgi.socket-0: Connection refused) and finaly gives 503 responses in gui

D'OH sorry for not thinking of lighttpd logs as well.
So here is what I have in there:
At 5am (pppoe reset), I normally get "server stopped", "server started". However on Monday this week I get:
2023-02-20T05:00:36+01:00 opnsense.<redacted> lighttpd 58826 - [meta sequenceId="1"] (gw_backend.c.369) child signalled: 1
2023-02-20T05:00:36+01:00 opnsense.<redacted> lighttpd 58826 - [meta sequenceId="2"] (gw_backend.c.369) child signalled: 1

Then coinciding with the last time I saw the 503 error I have the following on Tuesday in the log:
2023-02-21T18:08:29+01:00 opnsense.<redacted> lighttpd 58826 - [meta sequenceId="1"] (gw_backend.c.274) establishing connection failed: socket: unix:/tmp/php-fastcgi.socket-1: Connection refused
2023-02-21T18:08:29+01:00 opnsense.<redacted> lighttpd 58826 - [meta sequenceId="2"] (gw_backend.c.274) establishing connection failed: socket: unix:/tmp/php-fastcgi.socket-0: Connection refused
2023-02-21T18:08:29+01:00 opnsense.<redacted> lighttpd 58826 - [meta sequenceId="3"] (gw_backend.c.960) all handlers for /index.php? on .php are down.
2023-02-21T18:08:31+01:00 opnsense.<redacted> lighttpd 58826 - [meta sequenceId="4"] (gw_backend.c.351) gw-server re-enabled: unix:/tmp/php-fastcgi.socket-1  0 /tmp/php-fastcgi.socket
2023-02-21T18:08:31+01:00 opnsense.<redacted> lighttpd 58826 - [meta sequenceId="5"] (gw_backend.c.351) gw-server re-enabled: unix:/tmp/php-fastcgi.socket-0  0 /tmp/php-fastcgi.socket
2023-02-21T18:29:23+01:00 opnsense.<redacted> lighttpd 58826 - [meta sequenceId="1"] (gw_backend.c.274) establishing connection failed: socket: unix:/tmp/php-fastcgi.socket-1: Connection refused
2023-02-21T18:29:23+01:00 opnsense.<redacted> lighttpd 58826 - [meta sequenceId="2"] (gw_backend.c.274) establishing connection failed: socket: unix:/tmp/php-fastcgi.socket-0: Connection refused
2023-02-21T18:29:23+01:00 opnsense.<redacted> lighttpd 58826 - [meta sequenceId="3"] (gw_backend.c.960) all handlers for /index.php? on .php are down.
2023-02-21T18:29:26+01:00 opnsense.<redacted> lighttpd 58826 - [meta sequenceId="4"] (gw_backend.c.351) gw-server re-enabled: unix:/tmp/php-fastcgi.socket-1  0 /tmp/php-fastcgi.socket
2023-02-21T18:29:26+01:00 opnsense.<redacted> lighttpd 58826 - [meta sequenceId="5"] (gw_backend.c.351) gw-server re-enabled: unix:/tmp/php-fastcgi.socket-0  0 /tmp/php-fastcgi.socket
2023-02-21T18:32:37+01:00 opnsense.<redacted> lighttpd 70749 - [meta sequenceId="1"] (server.c.2078) server stopped by UID = 0 PID = 12116
2023-02-21T18:32:37+01:00 opnsense.<redacted> lighttpd 58826 - [meta sequenceId="2"] (server.c.2078) server stopped by UID = 0 PID = 12116
2023-02-21T18:32:37+01:00 opnsense.<redacted> lighttpd 58826 - [meta sequenceId="3"] (server.c.441) unlink failed for: /var/run/lighty-webConfigurator.pid: No such file or directory
2023-02-21T18:33:18+01:00 opnsense.<redacted> lighttpd 48897 - [meta sequenceId="4"] (server.c.1704) server started (lighttpd/1.4.68)
2023-02-21T18:33:18+01:00 opnsense.<redacted> lighttpd 48897 - [meta sequenceId="5"] (gw_backend.c.510) connect /tmp/php-fastcgi.socket-0: Connection refused
2023-02-21T18:33:18+01:00 opnsense.<redacted> lighttpd 48897 - [meta sequenceId="6"] (gw_backend.c.510) connect /tmp/php-fastcgi.socket-1: Connection refused
2023-02-21T18:33:27+01:00 opnsense.<redacted> lighttpd 44790 - [meta sequenceId="7"] (server.c.1704) server started (lighttpd/1.4.68)
2023-02-21T18:33:27+01:00 opnsense.<redacted> lighttpd 44790 - [meta sequenceId="8"] (mod_deflate.c.733) DEPRECATED: compress.filetype replaced with deflate.mimetypes
2023-02-21T18:33:27+01:00 opnsense.<redacted> lighttpd 44790 - [meta sequenceId="9"] (mod_deflate.c.796) DEPRECATED: compress.cache-dir replaced with deflate.cache-dir
2023-02-21T18:33:27+01:00 opnsense.<redacted> lighttpd 44790 - [meta sequenceId="10"] (configfile.c.1289) WARNING: unknown config-key: server.dir-listing (ignored)
2023-02-21T18:33:44+01:00 opnsense.<redacted> lighttpd 48897 - [meta sequenceId="11"] (server.c.2078) server stopped by UID = 0 PID = 30177
2023-02-21T18:33:47+01:00 opnsense.<redacted> lighttpd 57316 - [meta sequenceId="12"] (server.c.1704) server started (lighttpd/1.4.68)
2023-02-21T18:33:47+01:00 opnsense.<redacted> lighttpd 57316 - [meta sequenceId="13"] (gw_backend.c.369) child signalled: 1
2023-02-21T18:33:47+01:00 opnsense.<redacted> lighttpd 57316 - [meta sequenceId="14"] (gw_backend.c.510) connect /tmp/php-fastcgi.socket-1: Connection refused
2023-02-21T18:33:47+01:00 opnsense.<redacted> lighttpd 57316 - [meta sequenceId="15"] (gw_backend.c.369) child signalled: 1
2023-02-21T18:33:47+01:00 opnsense.<redacted> lighttpd 57316 - [meta sequenceId="16"] (gw_backend.c.510) connect /tmp/php-fastcgi.socket-0: Connection refused
2023-02-21T18:33:48+01:00 opnsense.<redacted> lighttpd 57316 - [meta sequenceId="17"] (server.c.2078) server stopped by UID = 0 PID = 77623
2023-02-21T18:33:48+01:00 opnsense.<redacted> lighttpd 57316 - [meta sequenceId="18"] (server.c.441) unlink failed for: /var/run/lighty-webConfigurator.pid: No such file or directory
2023-02-21T18:33:48+01:00 opnsense.<redacted> lighttpd 9787 - [meta sequenceId="19"] (server.c.1704) server started (lighttpd/1.4.68)
2023-02-21T18:34:03+01:00 opnsense.<redacted> lighttpd 9787 - [meta sequenceId="20"] (server.c.2078) server stopped by UID = 0 PID = 41182
2023-02-21T18:34:04+01:00 opnsense.<redacted> lighttpd 51570 - [meta sequenceId="21"] (server.c.1704) server started (lighttpd/1.4.68)
2023-02-21T18:34:18+01:00 opnsense.<redacted> lighttpd 51570 - [meta sequenceId="22"] (server.c.2078) server stopped by UID = 0 PID = 88442
2023-02-21T18:34:18+01:00 opnsense.<redacted> lighttpd 29089 - [meta sequenceId="23"] (server.c.1704) server started (lighttpd/1.4.68)

FYI: The 18:08 should be me trying to access opnsense. Following a "killall lighttpd" from the console and then restarted all services to fix the 503 error. The two log pieces are everything that is there for 20.-21.02.

Ok, this is getting weirder by the minute.
Today I get the following in the logs:
2023-02-24T05:00:40+01:00 opnsense.<redacted> lighttpd 28235 - [meta sequenceId="1"] (server.c.2078) server stopped by UID = 0 PID = 83947
2023-02-24T05:00:41+01:00 opnsense.<redacted> lighttpd 42478 - [meta sequenceId="2"] (server.c.1704) server started (lighttpd/1.4.68)
2023-02-24T05:01:05+01:00 opnsense.<redacted> lighttpd 42478 - [meta sequenceId="3"] (server.c.2078) server stopped by UID = 0 PID = 76194
2023-02-24T05:01:06+01:00 opnsense.<redacted> lighttpd 87916 - [meta sequenceId="4"] (server.c.1704) server started (lighttpd/1.4.68)
2023-02-24T05:01:06+01:00 opnsense.<redacted> lighttpd 87916 - [meta sequenceId="5"] (gw_backend.c.369) child signalled: 1
2023-02-24T05:01:06+01:00 opnsense.<redacted> lighttpd 87916 - [meta sequenceId="6"] (gw_backend.c.369) child signalled: 1
2023-02-24T05:01:06+01:00 opnsense.<redacted> lighttpd 87916 - [meta sequenceId="7"] (gw_backend.c.510) connect /tmp/php-fastcgi.socket-1: Connection refused

Being on the WebGUI, it shows me there, that the WebGUI is not running?

sorry, i dont have a suitable stand handy for "Periodic interface reset" test with pppoe interface. Whether correctly I understand that this job will  trigger newwanip (and so GUI reload) twice?
in this case, I can assume that two webgui restarts can occur with such a small delay that the webgui_configure_do will overlap and at the moment when lighty restarts the second time, the following happens: the script kills the php-cgi
https://github.com/opnsense/core/blob/09f40f0e335abec865c708046db134d4dcacc8a6/src/etc/inc/plugins.inc.d/webgui.inc#L139
of the lighty that just started and cannot start a new instance (can't bind to socket)
(I managed to reproduce this (not on a first try) by calling the configctl webgui restart almost simultaneously from two parallel ssh sessions)

@chris42
can you try with
opnsense-patch -a kulikov-a d2c26a3
please? (https://github.com/kulikov-a/core/commit/d2c26a3f30a4c5901513363156833eec2a9e477e)
slightly changes the actions order, removes one action and adds debugging info to the general log. perhaps this will help in cases of restarting the gui with a short interval

Thanks a lot! Did a reboot before applying, so any silly state is hopefully cleared up. Applied the patch (I guess reboot won't be necessary to activate)
We probably will see tomorrow or on Monday how it works.

When the problem occurs, who owns the sockets in /tmp and who has them open?   lsof, fuser, filel might help.  Do the socket files exist in /tmp?  Is lighttpd.conf configured to create those sockets?  Or is PHP-FPM used?  (PHP-FPM is recommended to manage PHP services.)
If lighttpd.conf is configured with "bin-path" to create the socket and run the backend, and if something else deletes the socket in /tmp, then lighttpd is managing a backend PHP process which is alive (has not exited) and listening on a socket that has been unlinked from the filesystem.  New connections from lighttpd to the socket filesystem path will fail.  If the backend PHP process exits, lighttpd will re-create the socket and restart the backend, but as long as the backend started by lighttpd is alive, that does not happen.
If something else is auto-cleaning /tmp, I recommend moving the sockets to a different, protected path, such as /run/lighttpd/...

So far webGUI is still alive and kicking. lighttpd logs are clean with only server stopping/starting messages.
Within system logs I found the following on yesterday's reconnect:
2023-02-26T05:00:16+01:00 opnsense.<redacted> opnsense 65690 - [meta sequenceId="52"] /usr/local/etc/rc.newwanip: webgui_id_63fad950a227e: start webgui_configure_do
2023-02-26T05:00:38+01:00 opnsense.<redacted> opnsense 96761 - [meta sequenceId="136"] /usr/local/etc/rc.newwanipv6: webgui_id_63fad96634fba: start webgui_configure_do
2023-02-26T05:00:39+01:00 opnsense.<redacted> opnsense 24122 - [meta sequenceId="146"] /usr/local/etc/rc.newwanipv6: webgui_id_63fad967269eb: start webgui_configure_do
2023-02-26T05:00:44+01:00 opnsense.<redacted> opnsense 96761 - [meta sequenceId="160"] /usr/local/etc/rc.newwanipv6: webgui_id_63fad96c315ea: start webgui_configure_do
2023-02-26T05:00:44+01:00 opnsense.<redacted> opnsense 96761 - [meta sequenceId="161"] /usr/local/etc/rc.newwanipv6: webgui_id_63fad96c315ea: starting generate_config
2023-02-26T05:00:44+01:00 opnsense.<redacted> opnsense 96761 - [meta sequenceId="162"] /usr/local/etc/rc.newwanipv6: webgui_id_63fad96c315ea: reload gui templates
2023-02-26T05:00:44+01:00 opnsense.<redacted> opnsense 96761 - [meta sequenceId="163"] /usr/local/etc/rc.newwanipv6: webgui_id_63fad96c315ea: php-cgi HUP skipped. realy need it? (lighty spawns FastCGI) (besides, it only kills one instance (and may kill captive portal?)?
2023-02-26T05:00:44+01:00 opnsense.<redacted> opnsense 96761 - [meta sequenceId="164"] /usr/local/etc/rc.newwanipv6: webgui_id_63fad96c315ea: config ready. TERM lighty
2023-02-26T05:00:44+01:00 opnsense.<redacted> opnsense 96761 - [meta sequenceId="165"] /usr/local/etc/rc.newwanipv6: webgui_id_63fad96c315ea: start lighty (lighty will remove pid file of working instance if start fail because of 'can't bind'. thats not funny)

On today's reconnect (5am) and firmware check (7am) I get the following:
2023-02-27T05:00:20+01:00 opnsense.<redacted> opnsense 625 - [meta sequenceId="178"] /usr/local/etc/rc.newwanip: webgui_id_63fc2ad400c28: start webgui_configure_do
2023-02-27T05:00:37+01:00 opnsense.<redacted> opnsense 27197 - [meta sequenceId="209"] /usr/local/etc/rc.newwanipv6: webgui_id_63fc2ae55aa63: start webgui_configure_do
2023-02-27T05:00:37+01:00 opnsense.<redacted> opnsense 6073 - [meta sequenceId="219"] /usr/local/etc/rc.newwanipv6: webgui_id_63fc2ae5bfe1c: start webgui_configure_do
2023-02-27T05:00:50+01:00 opnsense.<redacted> opnsense 27197 - [meta sequenceId="240"] /usr/local/etc/rc.newwanipv6: webgui_id_63fc2af2439f4: start webgui_configure_do
2023-02-27T05:00:50+01:00 opnsense.<redacted> opnsense 27197 - [meta sequenceId="242"] /usr/local/etc/rc.newwanipv6: webgui_id_63fc2af2439f4: starting generate_config
2023-02-27T05:00:50+01:00 opnsense.<redacted> opnsense 27197 - [meta sequenceId="243"] /usr/local/etc/rc.newwanipv6: webgui_id_63fc2af2439f4: reload gui templates
2023-02-27T05:00:50+01:00 opnsense.<redacted> opnsense 6073 - [meta sequenceId="245"] /usr/local/etc/rc.newwanipv6: webgui_id_63fc2af25c4a9: start webgui_configure_do
2023-02-27T05:00:50+01:00 opnsense.<redacted> opnsense 6073 - [meta sequenceId="246"] /usr/local/etc/rc.newwanipv6: webgui_id_63fc2af25c4a9: starting generate_config
2023-02-27T05:00:50+01:00 opnsense.<redacted> opnsense 6073 - [meta sequenceId="247"] /usr/local/etc/rc.newwanipv6: webgui_id_63fc2af25c4a9: reload gui templates
2023-02-27T05:00:50+01:00 opnsense.<redacted> opnsense 6073 - [meta sequenceId="248"] /usr/local/etc/rc.newwanipv6: webgui_id_63fc2af25c4a9: php-cgi HUP skipped. realy need it? (lighty spawns FastCGI) (besides, it only kills one instance (and may kill captive portal?)?
2023-02-27T05:00:50+01:00 opnsense.<redacted> opnsense 6073 - [meta sequenceId="249"] /usr/local/etc/rc.newwanipv6: webgui_id_63fc2af25c4a9: config ready. TERM lighty
2023-02-27T05:00:51+01:00 opnsense.<redacted> opnsense 6073 - [meta sequenceId="250"] /usr/local/etc/rc.newwanipv6: webgui_id_63fc2af25c4a9: start lighty (lighty will remove pid file of working instance if start fail because of 'can't bind'. thats not funny)
2023-02-27T05:00:51+01:00 opnsense.<redacted> opnsense 27197 - [meta sequenceId="252"] /usr/local/etc/rc.newwanipv6: webgui_id_63fc2af2439f4: php-cgi HUP skipped. realy need it? (lighty spawns FastCGI) (besides, it only kills one instance (and may kill captive portal?)?
2023-02-27T05:00:51+01:00 opnsense.<redacted> opnsense 27197 - [meta sequenceId="253"] /usr/local/etc/rc.newwanipv6: webgui_id_63fc2af2439f4: config ready. TERM lighty
2023-02-27T05:00:51+01:00 opnsense.<redacted> opnsense 27197 - [meta sequenceId="260"] /usr/local/etc/rc.newwanipv6: webgui_id_63fc2af2439f4: start lighty (lighty will remove pid file of working instance if start fail because of 'can't bind'. thats not funny)
2023-02-27T05:00:55+01:00 opnsense.<redacted> opnsense 55596 - [meta sequenceId="274"] /usr/local/etc/rc.newwanipv6: webgui_id_63fc2af7a123b: start webgui_configure_do
2023-02-27T05:01:09+01:00 opnsense.<redacted> opnsense 55596 - [meta sequenceId="288"] /usr/local/etc/rc.newwanipv6: webgui_id_63fc2b05b1080: start webgui_configure_do
2023-02-27T05:01:09+01:00 opnsense.<redacted> opnsense 55596 - [meta sequenceId="289"] /usr/local/etc/rc.newwanipv6: webgui_id_63fc2b05b1080: starting generate_config
2023-02-27T05:01:09+01:00 opnsense.<redacted> opnsense 55596 - [meta sequenceId="290"] /usr/local/etc/rc.newwanipv6: webgui_id_63fc2b05b1080: reload gui templates
2023-02-27T05:01:10+01:00 opnsense.<redacted> opnsense 55596 - [meta sequenceId="291"] /usr/local/etc/rc.newwanipv6: webgui_id_63fc2b05b1080: php-cgi HUP skipped. realy need it? (lighty spawns FastCGI) (besides, it only kills one instance (and may kill captive portal?)?
2023-02-27T05:01:10+01:00 opnsense.<redacted> opnsense 55596 - [meta sequenceId="292"] /usr/local/etc/rc.newwanipv6: webgui_id_63fc2b05b1080: config ready. TERM lighty
2023-02-27T05:01:10+01:00 opnsense.<redacted> opnsense 55596 - [meta sequenceId="293"] /usr/local/etc/rc.newwanipv6: webgui_id_63fc2b05b1080: start lighty (lighty will remove pid file of working instance if start fail because of 'can't bind'. thats not funny)
2023-02-27T05:01:19+01:00 opnsense.<redacted> opnsense 6073 - [meta sequenceId="322"] /usr/local/etc/rc.newwanipv6: webgui_id_63fc2b0fcdc3b: start webgui_configure_do
2023-02-27T05:01:19+01:00 opnsense.<redacted> opnsense 27197 - [meta sequenceId="325"] /usr/local/etc/rc.newwanipv6: webgui_id_63fc2b0fe1e93: start webgui_configure_do
2023-02-27T05:01:19+01:00 opnsense.<redacted> opnsense 73445 - [meta sequenceId="326"] /usr/local/etc/rc.newwanipv6: webgui_id_63fc2b0fe2abc: start webgui_configure_do
2023-02-27T05:01:24+01:00 opnsense.<redacted> opnsense 73445 - [meta sequenceId="340"] /usr/local/etc/rc.newwanipv6: webgui_id_63fc2b14e553b: start webgui_configure_do
2023-02-27T05:01:24+01:00 opnsense.<redacted> opnsense 73445 - [meta sequenceId="341"] /usr/local/etc/rc.newwanipv6: webgui_id_63fc2b14e553b: starting generate_config
2023-02-27T05:01:24+01:00 opnsense.<redacted> opnsense 73445 - [meta sequenceId="342"] /usr/local/etc/rc.newwanipv6: webgui_id_63fc2b14e553b: reload gui templates
2023-02-27T05:01:25+01:00 opnsense.<redacted> opnsense 73445 - [meta sequenceId="343"] /usr/local/etc/rc.newwanipv6: webgui_id_63fc2b14e553b: php-cgi HUP skipped. realy need it? (lighty spawns FastCGI) (besides, it only kills one instance (and may kill captive portal?)?
2023-02-27T05:01:25+01:00 opnsense.<redacted> opnsense 73445 - [meta sequenceId="344"] /usr/local/etc/rc.newwanipv6: webgui_id_63fc2b14e553b: config ready. TERM lighty
2023-02-27T05:01:25+01:00 opnsense.<redacted> opnsense 73445 - [meta sequenceId="345"] /usr/local/etc/rc.newwanipv6: webgui_id_63fc2b14e553b: start lighty (lighty will remove pid file of working instance if start fail because of 'can't bind'. thats not funny)
2023-02-27T05:01:38+01:00 opnsense.<redacted> opnsense 73445 - [meta sequenceId="359"] /usr/local/etc/rc.newwanipv6: webgui_id_63fc2b2241aec: start webgui_configure_do
2023-02-27T07:06:15+01:00 opnsense.<redacted> opnsense 44368 - [meta sequenceId="1"] /usr/local/etc/rc.restart_webgui: webgui_id_63fc4857e4d35: start webgui_configure_do
2023-02-27T07:06:15+01:00 opnsense.<redacted> opnsense 44368 - [meta sequenceId="2"] /usr/local/etc/rc.restart_webgui: webgui_id_63fc4857e4d35: starting generate_config
2023-02-27T07:06:15+01:00 opnsense.<redacted> opnsense 44368 - [meta sequenceId="3"] /usr/local/etc/rc.restart_webgui: webgui_id_63fc4857e4d35: reload gui templates
2023-02-27T07:06:16+01:00 opnsense.<redacted> opnsense 44368 - [meta sequenceId="4"] /usr/local/etc/rc.restart_webgui: webgui_id_63fc4857e4d35: php-cgi HUP skipped. realy need it? (lighty spawns FastCGI) (besides, it only kills one instance (and may kill captive portal?)?
2023-02-27T07:06:16+01:00 opnsense.<redacted> opnsense 44368 - [meta sequenceId="5"] /usr/local/etc/rc.restart_webgui: webgui_id_63fc4857e4d35: config ready. TERM lighty
2023-02-27T07:06:16+01:00 opnsense.<redacted> opnsense 44368 - [meta sequenceId="6"] /usr/local/etc/rc.restart_webgui: webgui_id_63fc4857e4d35: start lighty (lighty will remove pid file of working instance if start fail because of 'can't bind'. thats not funny)

Does that help?

@chris42 yes, thanks! may I help (resembles a race condition)
Only there is a feeling that the data is sorted by the Message column. I will try to change the  sorting to 'by time and sequence ID' and then it will become clearer (i hope)

config ready. TERM lighty
start lighty (lighty will remove pid file of working instance if start fail because of 'can't bind'. thats not funny)

I'm a little bit confused.  There should be no "working instance" if lighttpd is being started.  If there is, then whatever privileged process tried to start lighttpd failed to first check if lighttpd was already running, or failed to shut lighttpd down and wait for lighttpd to exit, and for the lighttpd instance shutting down to remove its pid file.
After changing lighttpd configuration, it is recommended that the config be tested before lighttpd is restarted:
lighttpd -f /etc/lighttpd/lighttpd.conf -tt
No output and exit value of 0 is success.
Then, instead of sending lighttpd SIGTERM, sending SIGUSR1 will result in a graceful restart of lighttpd, reloading the config.
However, if the lighttpd executable has changed (e.g. package upgrade), then a stop and start of lighttpd is needed.  SIGINT will stop lighttpd gracefully, handling existing connections for a few more seconds (configurable).  SIGTERM will stop lighttpd very quickly, without continuing to handle connections in progress.
Now, I don't know the specifics of the webgui behavior.  If a SIGTERM is sent to lighttpd, does the webgui do it, or does the webgui ask the init script to restart lighttpd?  The init script should be used.  If the webgui is sending the signal, there is a possibility that someone is attempting to start lighttpd before the older process has exited, and so the failure to bind might occur.
I don't have a machine in front of me, so this is all theoretical scenarios, depending on what the webgui is actually doing.

Let's try 3610606 with SIGINT then. It could be a race, but the start/stop is sequential so it's unlikely an issue with the general flow.
# opnsense-patch 3610606

Cheers,
Franco

Looking in https://github.com/opnsense/core/commit/36106069ad9fe0933d29bff557f4b2dbbc0d7ac9, there is definitely a race after sending SIGTERM (now SIGINT) and exec'ing lighttpd because there is nothing that checks that lighttpd has exited before trying to start lighttpd back up.
While changing the signal to SIGINT is more friendly to existing web requests in progress, lighttpd will by default wait for 8 seconds for those in-progress connections to finish before lighttpd closes those connections.  The time to wait is configurable, but just about any value will result in the lighttpd bind failure at startup since the older lighttpd will still be running (unless there are no open connections and the older lighttpd manages to kill the backend PHP, wait for it to exit, and then lighttpd exit before webgui.inc tries to start up a new instance of lighttpd).
Is there a service which restarts lighttpd if lighttpd exits?  Can the webgui ask that service to restart lighttpd?
If not, can the webgui wait until the lighttpd pid file is removed or kill -0 $pid on the lighttpd pid is invalid?

The third parameter is true which means it monitors PID file to wait for exit.

FYI: these are now the defaults in lighttpd since lighttpd 1.4.68, so this can be omitted.
            /* harden TLS for PCI conformance */
            $lighty_config .= <<<EOD
ssl.openssl.ssl-conf-cmd = (
    "MinProtocol" => "TLSv1.2",
    "Options" => "-ServerPreference",
    "CipherString" => "EECDH+AESGCM:AES256+EECDH:CHACHA20:!SHA1:!SHA256:!SHA384"
)

EOD;

and I question the correctness of $lighty_config .= "    \"MinProtocol\" => \"TLSv1\"";  on line 404 in the else block below that.  TLSv1 is deprecated and its use strongly discouraged on any modern system.  Omit specifying "MinProtocol" to get the default TLS MinProtocol in lighttpd, which is currently "TLSv1.2".

As @fichtner notes, killbypid() waits for the process to exit.  Given that, there should not be a race condition where lighttpd is still running when that continues executing webgui.inc.  (And yet, here we are discussing in this issue why lighttpd might fail to start with bind address already in use.)
There is a different race condition in src/etc/inc/util.inc in killbypid()
    while (isvalidpid($pidfile)) {
        usleep(200 * 1000);
    }

That loops and every 200ms reads the pidfile.  In the meantime, something else might delete the pidfile and something else might recreate the pidfile, and the loop would be none-the-wiser.  The pidfile should be read and saved.   Then the loop can operate on the numeric pid value.  The pidfile should be read into memory before sending lighttpd SIGINT, and the signal should be sent to the pid, not to the pkill -F if $waitforit is set.

Yep, let me fix that tomorrow. Not sure if related as this was the case for years, but we will see. Thanks!

I see the race in:
2023-02-27T05:00:50+01:00 opnsense.<redacted> opnsense 27197 - [meta sequenceId="240"] /usr/local/etc/rc.newwanipv6: webgui_id_63fc2af2439f4: start webgui_configure_do
2023-02-27T05:00:50+01:00 opnsense.<redacted> opnsense 27197 - [meta sequenceId="242"] /usr/local/etc/rc.newwanipv6: webgui_id_63fc2af2439f4: starting generate_config
2023-02-27T05:00:50+01:00 opnsense.<redacted> opnsense 27197 - [meta sequenceId="243"] /usr/local/etc/rc.newwanipv6: webgui_id_63fc2af2439f4: reload gui templates
2023-02-27T05:00:50+01:00 opnsense.<redacted> opnsense 6073 - [meta sequenceId="245"] /usr/local/etc/rc.newwanipv6: webgui_id_63fc2af25c4a9: start webgui_configure_do
2023-02-27T05:00:50+01:00 opnsense.<redacted> opnsense 6073 - [meta sequenceId="246"] /usr/local/etc/rc.newwanipv6: webgui_id_63fc2af25c4a9: starting generate_config
2023-02-27T05:00:50+01:00 opnsense.<redacted> opnsense 6073 - [meta sequenceId="247"] /usr/local/etc/rc.newwanipv6: webgui_id_63fc2af25c4a9: reload gui templates
2023-02-27T05:00:50+01:00 opnsense.<redacted> opnsense 6073 - [meta sequenceId="248"] /usr/local/etc/rc.newwanipv6: webgui_id_63fc2af25c4a9: php-cgi HUP skipped. realy need it? (lighty spawns FastCGI) (besides, it only kills one instance (and may kill captive portal?)?
2023-02-27T05:00:50+01:00 opnsense.<redacted> opnsense 6073 - [meta sequenceId="249"] /usr/local/etc/rc.newwanipv6: webgui_id_63fc2af25c4a9: config ready. TERM lighty
2023-02-27T05:00:51+01:00 opnsense.<redacted> opnsense 6073 - [meta sequenceId="250"] /usr/local/etc/rc.newwanipv6: webgui_id_63fc2af25c4a9: start lighty (lighty will remove pid file of working instance if start fail because of 'can't bind'. thats not funny)
2023-02-27T05:00:51+01:00 opnsense.<redacted> opnsense 27197 - [meta sequenceId="252"] /usr/local/etc/rc.newwanipv6: webgui_id_63fc2af2439f4: php-cgi HUP skipped. realy need it? (lighty spawns FastCGI) (besides, it only kills one instance (and may kill captive portal?)?
2023-02-27T05:00:51+01:00 opnsense.<redacted> opnsense 27197 - [meta sequenceId="253"] /usr/local/etc/rc.newwanipv6: webgui_id_63fc2af2439f4: config ready. TERM lighty
2023-02-27T05:00:51+01:00 opnsense.<redacted> opnsense 27197 - [meta sequenceId="260"] /usr/local/etc/rc.newwanipv6: webgui_id_63fc2af2439f4: start lighty (lighty will remove pid file of working instance if start fail because of 'can't bind'. thats not funny)

it is possible that when the one instance is executed, between the lighty kill attempt and start the other instance is starting the lighty. and one of the instances will killbyname('php-cgi', 'HUP'); while the lighty is running. which leads gradually to an all handlers for /index.php? on .php are down.
so I moved killbypid closer to lighty start.
since the lighty config contains "bin-path" and lighty runs the backend, it seemed to me that line killbyname('php-cgi', 'HUP'); is atavistic (and causes the loss of sockets) and I commented it out.
and there is another issue:
lighty config contains a server.pid-file.
if we run /usr/local/sbin/lighttpd -f /var/etc/lighty-webConfigurator.conf. then run the /usr/local/sbin/lighttpd -f /var/etc/lighty-webConfigurator.conf again, it will return Address already in use and delete the pid file (a bit unexpected for me. i saw that server.c deletes pid in any case except graceful restart but i thought that i just missed 'pid already exists' somewhere). which further makes it impossible to stop the lighty and the next gui restart attempts will not stop lighty but will continue to kill sockets.

@kulikov-a I agree that if lighttpd is managing the PHP, then the webgui should let lighttpd manage the PHP.  Alternatively, if lighttpd is not managing the PHP, then the PHP should be managed by PHP-FPM.  In either case, the PHP processes should not be killed directly by the webgui.
If lighttpd.conf is configured to use a pidfile, then administrative processes should respect the pidfile.  As long as the pidfile exists, the admin processes should presume that lighttpd is running, and they can read the pidfile and check that the pid is alive.  If not alive, they can start lighttpd.
When lighttpd is started, and lighttpd not testing or printing the config, and when a pidfile is configured, lighttpd opens the pidfile.  If the pidfile already exists, then the pidfile is opened and truncated.
Lots of paranoid code could be written to read the pidfile if it exists and then perform an OS-specific inquiry to check if the pid is alive and retrieve and evaluate the command line associated with the pid, see if it is lighttpd and then either exit or send a signal to the existing lighttpd process.  None of this is currently done, and would be a bit of a pain to do properly for the many platforms on which lighttpd can run.
Many systems have some sort of supervisor start lighttpd, and restart lighttpd if lighttpd exits.  systemd, sysvinit, daemontools, inetd, xinetd, etc.  These start the lighttpd process and as parent process, can detect if/when the process exits.  Even /etc/init.d/lighttpd scripts generally have a mechanism to check if lighttpd is running before attempting to start lighttpd.  Instead of lighttpd trying to duplicate such logic for different platforms, lighttpd recommends using the one of the existing options available on a given platform.
What starts lighttpd at system startup?  Can webgui leverage that mechanism to start/stop/restart lighttpd?
If webgui is going to start/stop/restart lighttpd, then I suggest that a lockfile be added so that multiple running instances of the script do not attempt to start lighttpd.  @kulikov-a I think what you documented above is multiple scripts entering webgui_configure_do.  There could be a lockfile to detect and prevent that from happening.

So from the previous log the following sticks out:
opnsense 27197 /usr/local/etc/rc.newwanipv6
opnsense 6073 /usr/local/etc/rc.newwanipv6
Basically it means the IPv6 will dispatch multiple reloads on the same interface at the same time and that's where a lock might make sense. But to be honest this is also a downside of having selected listening interfaces which equals the proverbial foot-shooting because now you have to deal with restarting the service because an IP address might have changed. The recommended way is still not not select any listening interfaces.
A reload capability might fix this, but as Glenn said the binary needs to be checked to see if a restart is needed. Something similar had to be done to syslog-ng in the past.
Cheers,
Franco

@fichtner
sorry for the noise. i still not get it: do we realy need killbyname('php-cgi', 'HUP');?
and if we let lighty to do it gracefully, may be it worth to do it with USR1 (graceful restart). like https://github.com/kulikov-a/core/commit/daf238c65ed13b303d2d59726c8ab3118859c351
and in that case there is should be no risk of start with existing pid?

https://github.com/kulikov-a/core/commit/daf238c65ed13b303d2d59726c8ab3118859c351 misses more glue for binary changes as mentioned. php-cgi was required at one time to reload PHP modules on binary updates. Not sure if still needed but it was pretty important to have it especially on php major version transitions.

The porting to PHP may have gone wrong with the changed behaviour of only using the latest PID, but I wouldn't be surprised this is still required. 4e2b0079df6d430f

Oh! Thanks! I understand why now, now I'm trying to understand the logic)
if the backend is started and controlled by lighty ("bin-path"), and when lighty is gracefully restarted, I see that the pids of the php-cgi instances changed, does this mean that they are effectively SIGHUP-ed by lighty ?

When the GUI is running performing an update it ends up tripping over missing PHP files/modules after upgrade. The GUI is restarted after all has been reinstalled. This might have been more of a problem in the past with different flow through package update but you can still get update-related errors while the upgrade is performing depending on what has been changed. I'd have to check the refactor for it to make more sense but no time today.

@fichtner thanks!
(if this is still the case, another question arises ;) whether it is worth to let the lighty manage backend and then try to interfere with it. looks like lighty should handle outside backend well?)

I’m not sure. We want to wait for GUI restart which could go wrong and not have errors due to changed PHP modules and code. How would lighttpd handle this for us?

lighttpd graceful restart (SIGUSR1) is safe to send to lighttpd multiple times.
lighttpd handles SIGUSR1 by giving up to 8 seconds (configurable) for existing connections to complete, and then closing connections.  As part of a graceful restart, lighttpd sends all backends (which had been started by lighttpd) a SIGINT, so this should take care of restarting all PHP processes which were started by lighttpd.
lighttpd graceful restart is recommended for configuration changes, including system IP changes, though should not be necessary for system IP changes if lighttpd is listening only on a wildcard address.

lighttpd needs to be fully stopped and restarted when the lighttpd binary package is updated.

If you need to restart PHP systems and only want to restart PHP, then I recommend running PHP processes via PHP-FPM so that PHP-FPM can be signalled to restart all PHP.

@gstrauss @fichtner Thanks!!
clarified a lot!
so it can handle lighty binary change like syslog-ng do and handle the rest with the SIGUSR1?
like https://github.com/kulikov-a/core/commit/29ea626b3559860150dd39b9ea06f3f4abcf62a3 ?

@kulikov-a that looks like an improvement in most cases.  However, in the case where the lighttpd binary package did change, you patch (like the existing code) does not have protection from races if multiple IP changes call webgui_configure_do in a short timeframe.

@gstrauss yep, thanks! gracefull shutdown lefts time for this.
although the coincidence is not very likely (rapid gui restart calls on interface reset in combination with a lighty update),
https://github.com/kulikov-a/core/commit/bc41fe2859db5b57c0d1d4bbdb144bf7fb1c318d produces

the race is visible, but the script seems to handle it

@kulikov-a your new patch is not atomic and is not race-free.
A simple way to minimize (but not eliminate) the race:
        $last_version = @file_get_contents('/var/run/lighty_gui.version');
        $this_version = shell_safe('/usr/local/sbin/lighttpd -v | sha256');
        file_put_contents('/var/run/lighty_gui.version', $this_version);

Updating '/var/run/lighty_gui.version' right after reading it is still a race, but is much smaller than the race in your patch.  Updating '/var/run/lighty_gui.version' right after reading it means that another call to webgui_configure_do will likely read the updated file, and will send a SIGUSR1 since it will not detect a version change.
While not race-free, this might be "good enough" for an immediate improvement to the existing code, along with sending SIGUSR1 to lighttpd for all other config changes.
(Aside: since you are comparing strings for exact match, I do not see why | sha256 is necessary)

@gstrauss Thanks for the explanation! I agree that I overdid it with the loop..)
Unfortunately, your method doesn't work either - with a gracefull shutdown, the second thread manages to "plain start" lighty (server.c removes the pid-file too early?) and the start of lighty in the first thread (after the SIGINT) gets "can't bind to socket".
does https://github.com/kulikov-a/core/commit/192468960c45cd844290fbcf08929dd98192016c technique prevent the race?
I think yes:

Yes, you have added a lock file.  That is a recommended solution.  Alternatively, if you want to lock a file in the filesystem that you know exists, you could use "/var/etc/lighty-webConfigurator.conf".  Then, you might not need '/var/run/lighty_gui.version' at all.
If "/var/run/lighty-webConfigurator.pid" exists and is older than "/usr/local/sbin/lighttpd", then you should send the lighttpd pid SIGINT instead of SIGUSR1.
Also, if performance were important, I recommend looking into why webgui_configure_do is being called multiple times.  Why not wait for the network to be fully configured (or reconfigured) and then (re)start services that depend on the network?

We cannot trust time in the system, especially with Hypervisors and NTP turning the clock back and forth worst case.

I'm wondering if we put back the deleted PID file when the PID is still valid we end up with a failed attempt but not an unrecoverable condition anymore.

 I'm not sure what sort of severity to apply here since.

I'm not sure what sort of severity to apply here since operational impact is minimal.

hm..apart from the fact that the lighty does not actually reload? )

Speaking in terms of operability and configurability of the system the impact is very low. Plus it's still avoidable by switching off the specific listening interfaces which is the root of most evil these days. :)

yep, i'm just afraid that when there is a really necessary webgui restart call (cert change, settings changing), it will not work.
but at least the gui remains operational and opnsense can be restarted via gui )

Untested: take a lock on the config file to serialize access to (re)start lighttpd.  PHP doc notes on some platforms that flock() is per-process.  If your PHP code is multi-threaded, then you might have to use fcntl() instead of flock().
fclose() or going out of scope should release the file lock, but I do them explicitly below.  Optimization: could read '/var/run/lighty-webConfigurator.pid' once and reuse the pid rather than repeatedly reading the file.  Not done here: modifying killbypid() to read the pid file once to avoid races.  (No race with ourselves here since we are holding a lock, but there would be race if another process ignored taking the lock before signalling lighttpd.)
--- a/src/etc/inc/plugins.inc.d/webgui.inc
+++ b/src/etc/inc/plugins.inc.d/webgui.inc
@@ -132,11 +132,33 @@ function webgui_configure_do($verbose = false, $interface = '')
         @touch('/var/run/development');
     }

-    /*
-     * Force reloading all php-cgi children to
-     * avoid hiccups with moved include files.
-     */
-    killbyname('php-cgi', 'HUP');
+    /* (re)start the frontend when the generation has completed
+     * Take a file lock to ensure other threads do not try to restart lighttpd
+     * at the same time. */
+
+    $lv_p = fopen('/var/etc/lighty-webConfigurator.conf', 'r');
+    if (!flock($lv_p, LOCK_EX)) { # blocks until file locked; failure unexpected
+        fclose($lv_p);
+        return;
+    }
+
+    $gui_pid = '/var/run/lighty-webConfigurator.pid';
+    if (isvalidpid($gui_pid)) {
+        if (filemtime($gui_pid) >= filemtime('/usr/local/sbin/lighttpd')) {
+            killbypid($gui_pid, 'USR1', false);
+            service_log("triggered lighttpd graceful restart.\n", $verbose);
+            flock($lv_p, LOCK_UN);
+            fclose($lv_p);
+            return;
+        } else {
+            /* lighttpd updated. need to stop.
+             * adjust lighty-webConfigurator.conf to change default shutdown
+             * timeout if the default (waiting up to 8 seconds) is too much.
+             * server.feature-flags += ("server.graceful-shutdown-timeout" => 8)
+             */
+            killbypid($gui_pid, 'INT', true);
+        }
+    }

     /* start lighttpd */
     if (!count($listeners) || mwexec('/usr/local/sbin/lighttpd -f /var/etc/lighty-webConfigurator.conf')) {
@@ -144,6 +166,9 @@ function webgui_configure_do($verbose = false, $interface = '')
     } else {
         service_log("done.\n", $verbose);
     }
+
+    flock($lv_p, LOCK_UN);
+    fclose($lv_p);
 }

 function webgui_create_selfsigned($verbose = false)

We cannot trust time in the system, especially with Hypervisors and NTP turning the clock back and forth worst case.

Then you might want to replace the filemtime() in my patch with @kulikov-a's solution to save and compare with previous running version.

thanks! looks much sharper imho. tested with https://github.com/kulikov-a/core/commit/e37573239efe0caf616a4efa8b03de28b88a615c
new killbypid() version is a bit noisy on rapid rrd_configure() calls (The command '/bin/kill -'TERM' '89221'' returned exit code '1', the output was 'kill: 89221: No such process' if updaterrd.sh.pid was killed by parallel thread. i think pkill just handled it differently)
but webgui_configure_do works smooth!

The log noise is not the source of the problem.  On the contrary, the log noise is helping to highlight an actual problem.  The source of the problem appears that the process management is poor.  Additional lock file(s) are likely indicated to serialize the process management of start/restart, similar to what has been done above for lighttpd.
Regarding your latest test patch kulikov-a@3375732 you need to
$this_version = shell_safe('/usr/local/sbin/lighttpd -v | sha256');
before if (isvalidpid($gui_pid)) {
and need to always
file_put_contents('/var/run/lighty_gui.version', $this_version);
further down, when (re)starting lighttpd, and before releasing the lock.

To be frank, why not lock the PID file during a startup? It really doesn't matter where the lock is eventually as long as it's being suggested.

The pid file might not exist if lighttpd is not running, or the machine has been rebooted.
If you meant locking the config file, then that could be done.
However, all of this is a workaround since the scripts do not appear to perform process management at a higher level.  As a workaround, it is preferable to be isolated to one location in the code, if possible, rather than spread around.

@gstrauss
agree. I wanted to save a little, but this may lead to an unnecessary INT stop later, thanks

and need to always
hm. why not to just  file_put_contents before isvalidpid also ?
@fichtner what if PID-file not there at this moment (what's wrong with conf-lock?)? how lighty will react if we created it insted

I don't see how RC systems in BSD deal with this more gracefully, but maybe I haven't looked closely enough.
flock(8) can create a file on demand

how lighty will react if we created it insted

lighttpd would fail if lighttpd did not have read/write permission.
As long as lighttpd has read/write permission, lighttpd would truncate the pidfile and would proceed as usual.

226c133 works for me. I can still produce 500 errors sporadically but at least the PID file is not being messed with by any other instance starting so the situation is recoverable.

@fichtner that might be an improvement, but I think what @kulikov-a is working on is better to eliminate the race and to use lighttpd graceful restart, which is better all around.

sorry, with flock -ne: how can we predict which thread config lighty will run with?

@gstrauss can the remove_pid_file call at be shifted lower as possible?https://github.com/lighttpd/lighttpd1.4/blob/e0817646d6c0d279aafa2ec5f70fdcf3afd6dd44/src/server.c#L2091
may be this could help killbypid to correctly determine the lighty state and increase the chances that the threads will not mix

@gstrauss i just think that if (correct me if im wrong) pid-file deleted before graceful-shutdown-timeout wait this increases the likelihood of thread mixing since we use killbypid
@fichtner sorry to bother ) . just trying to understand: if a lock() is used in filter_configure_sync() and works perfect in https://github.com/kulikov-a/core/commit/b802b41e8bf4b182990198c56bb630f21ebdd977, why are you against using a lock for concurrency management in this case?

@Melantrix It's highly likely solved if you keep the OPNsense defaults, System->Settings->Administration/"Listen Interfaces" : "All (Recommended)"

@Melantrix It's highly likely solved if you keep the OPNsense defaults, System->Settings->Administration/"Listen Interfaces" : "All (Recommended)"

Okay but I don't want to listen on all interfaces. I have disabled my untrusted networks I'm that list because, well, they are untrusted. I understand I can block the traffic with firewall rules which i have. But why listen on untrusted interfaces when they are untrusted?
Is there anything else to fix this?

Bind to loopback with a port forward? (and make sure you don't lock yourself out while doing so) Most issues are related to people using some sort of non static interface to bind to (which theoretically can't work). Offering a selection was likely one of the worst choices we made in the past years (after a user pushed for it and we warned from the beginning this is risky when surroundings change frequently).....

@AdSchellevis Thanks for responding this quicly!
a non static interface would be?
I have them only enabled on my trusted vlans that are on my LAN interface  but disabled on e.g. my WAN interface or Guest network. i don't understand what the problem of this could be too be honest.
What causes this issue exactly? If i understand the thread correctly, there are two processes fichting over port 443 on an interface to listen on? How is that connected to which interface the gui listens too? As far as i know there is no other web gui installed on the firewall that should also listen on a port?
(i'm just trying to understand the issue, so i can do a proper risk assesment on which path to take to fix this).
Maybe i'm just thinking about this in the wrong way..?

To the OPNsense members subscribed: having systems-level functionality managed by PHP written by non-systems-developers is not a good look for OPNsense.
I contributed code with a working solution above.  If time jumping backwards were a concern, my proposed solution is not wrong, but could be improved to handle that case, which is what @kulikov-a added.  However, there is nobody on the OPNsense team who has posted here committing either to reviewing those proposed solutions, or suggesting other next steps.

@Melantrix

a non static interface would be?

yes indeed, that's the most common cause of issues.

I have them only enabled on my trusted vlans that are on my LAN interface but disabled on e.g. my WAN interface or Guest network. i don't understand what the problem of this could be too be honest.

In most cases that should work, but.I don't know the exact circumstances.

What causes this issue exactly? If i understand the thread correctly, there are two processes fichting over port 443 on an interface to listen on? How is that connected to which interface the gui listens too? As far as i know there is no other web gui installed on the firewall that should also listen on a port?

If I understand the ticket correctly (but I have not been involved), there's a locking issue with the webserver, for which @fichtner proposed a simple solution https://github.com/opnsense/core/commit/226c133c8f5c4a5fc2653a56b78904cad7f4c9b3, there where other ventures in the same thread, but as they add a lot of complexity (and add risk), at the moment their not in the OPNsense codebase.
Quite some if this is old (yet cleaned-up) code, which is vital for the system from a user perspective, we're careful what to merge there. In our experience adding a lot of complexity has the risk of quite some backlash, which might be worse than the original issue that doesn't seem to affect many users.
If you're only using static interfaces, I would certainly try if https://github.com/opnsense/core/commit/226c133c8f5c4a5fc2653a56b78904cad7f4c9b3 improves the situation, other improvements might take longer to integrate. If it does, just ping @fichtner so he has another datapoint.

Will this be fixed via https://github.com/opnsense/core/commit/c95c444508bc7ac16b0d41599962361abcee48a2 in one of the future (minor) releases?

They will be in 23.1.4, but they don’t fix 500 error. Honestly, just disable listening interface selection and avoid this one.

New patch on top of 23.1.4 is 33ad50456a1
# opnsense-patch 33ad50456a1

If it works I'd like to close this ticket finally.
Cheers,
Franco

The idea is simply no more 500, but it may be that configd in detach mode will not serialise correctly. It's a one line fix then.
If you have other patches move to 23.1.4 and run:
# opnsense-revert opnsense && opnsense-patch 33ad50456a1

Ok... trap is set... now lets wait.

So far the WebGUI seems to work. Errors haven't showed up. Only having the following in the system log at pppoe reconnect:
2023-03-30T05:00:51+02:00 opnsense.<redacted> opnsense 59790 - [meta sequenceId="259"] /usr/local/etc/rc.newwanipv6: plugins_configure newwanip (execute task : webgui_configure_do(,lan))
2023-03-30T05:00:52+02:00 opnsense.<redacted> opnsense 86374 - [meta sequenceId="273"] /usr/local/etc/rc.restart_webgui: The command '/usr/local/bin/flock -ne /var/run/lighty-webConfigurator.pid /usr/local/sbin/lighttpd -f /var/etc/lighty-webConfigurator.conf' returned exit code '1', the output was ''
2023-03-30T05:00:52+02:00 opnsense.<redacted> opnsense 86374 - [meta sequenceId="274"] /usr/local/etc/rc.restart_webgui: The command '/bin/kill -'TERM' '9643'' returned exit code '1', the output was 'kill: 9643: No such process'
2023-03-30T05:00:59+02:00 opnsense.<redacted> opnsense 82595 - [meta sequenceId="278"] /usr/local/etc/rc.newwanipv6: plugins_configure newwanip (execute task : webgui_configure_do(,opt6))

Looks promising. I added 019ea527 on top ready for 23.1.6 then.


sleep for built in LCD to turn it off to conserve power and turn on/wake up by touch

There are examples for displaying things on ILI9342C
using framebuffer and LVGL.
I do not see how to turn off backlight on ILI9342C. Is there some code example? Or command line utility with the code to control brightness? I was able to code that on m5stack tough on esp32 which has same ILI9342C.
Also how to wake up screen by touch?
I guess with brightness off touch functions are still there. So I need example of code listening for touch event and controlling backlight (voltage of it?) on ILI9342C.
Thanks

Currently, you can adjust the LCD backlight through sys, with the relevant command being echo 0 > /sys/class/backlight/axp2101_m5stack_bl/brightness. A simple Python 3 call would be: python3 -c 'f=open("/sys/class/backlight/axp2101_m5stack_bl/brightness", "w");f.write("100");f.close()'.
core-config is a great tool that allows you to adjust the screen backlight directly in the terminal or command line interface. Simply execute code-config --set-lcd-backlight 0 to turn off the backlight, and code-config --set-lcd-backlight 100 to turn it on.
When it comes to reading the touchscreen input, you need to pay attention to the events in Linux input, with the interface located at /dev/input/event0. The C code will be uploaded later.

It doesn't look like
echo 0 > /sys/class/backlight/axp2101_m5stack_bl/brightness

turns off backlight. I can still see previous picture just very very dark.

Don't worry, this might be caused by light reflecting from elsewhere onto the screen. If you mind it a lot, you can erase the framebuffer buffer using a program, for example, cat /dev/zero > /dev/fb1.

This is an example of reading touch using CoreMP135. Hope it helps you. https://github.com/m5stack/M5Stack_Linux_Libs/tree/master/examples/lcd_hello_world

Thanks a lot!


flat shader bug

Godot 3.1
Windows 10 GTX 1070
16GB ram
i5
i try to add toon shader in this low poly sphere but the materail shader looks flat and not smooth.
import low poly sphere and add toon shader to it

Is this sphere looking smooth without toon? Does it look smooth in a 3D modeling program?

this is not a bug , you are using non smooth sphere

Look at the normals of the shader its not smooth at all

There is no such thing as Flat shading in Godot, you exported the model
wrong.. this information is not in the material but the geometry.
On Feb 20, 2018 09:59, "Itachi124"<EMAIL_ADDRESS>wrote:

Look at the normals of the shader its not smooth at all
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/16827#issuecomment-366969680,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AF-Z20C9FBOWUGbze2eGm_VaXonxuYRNks5tWsGjgaJpZM4SKyxa
.

Can't reproduce with a sphere with correct smooth normals:

Side note, toon shading is this:

Closing as not a bug.


Support Predicate Pushdown for Parquet Lists (#2108)

Which issue does this PR close?

Closes #2108
Rationale for this change

This PR adds support for skipping repetition levels by adding a buffer to ColumnLevelDecoderImpl. This buffer is also used to speed up skipping definition levels, as it allows for vectorised decoding.
What changes are included in this PR?

Are there any user-facing changes?

Will update with rep_levels support

https://arrow.apache.org/blog/2022/10/08/arrow-parquet-encoding-part-2/ may be helpful here

I will review this carefully tomorrow morning!


gosdk StreamRange

StreamEffectsRange
StreamTransactionsRange
etc
would allow you to fetch all the resources between two points. Useful if you want to calculate daily volume for example.

I think we should use context package instead. All Stream* functions will have another parameter ctx context.Context. Developers will be able to pass WithCancel contexts that will allow to cancel streaming objects. Then all you need to do is something like:
ctx, cancel := context.WithCancel(context.Background())
handler := func(payment Payment) {
  // Do something with a payment
  if streamedAllPaymentsIWanted {
    cancel()
  }
}
go StreamPayments("G...", &Cursor("startingToken"), handler, ctx)


Broken Link on Mod Wiki

Just a heads up, but on the "Rockets Guide" page, where it says "A static shipping route can be set up by linking two docking pads together with linkers", the docking pads link is broken. It appears that you remained the page to "Landing Pad", but you didn't update the page, or change any of the pages that link to it.

take a look at http://arwiki.dmodoomsirius.me I am now hosting the wiki for Zmaster. what ever is on his latest for what he has on github. I am finailizing updating that url atm.

i did rename the page, will have it updated in a bit

should be fixed


The progress is stopped here when the private key was wrong.

Fixed in 2016/12/1 https://github.com/AntShares/AntSharesApp/commit/eb8044cb727064a739d9bfa165df13125a09d130


Revamp Getting Started and Intro

Scratchpad for how this should go is hosted here:
https://docs.google.com/document/d/1h261WW1GPzcvQEsHC-dv_kYsDrf91AfjKHjyLC9lAqc/edit#

Done!


azure-lb primitive missing "op monitor" line (SUSE HA Netweaver article)

This page also impacted by this issue:
https://github.com/MicrosoftDocs/azure-docs/issues/97227

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 5d2a9d09-f0f0-f02a-dfc6-f9562c0d66ec
Version Independent ID: f7c0b99d-daae-5616-ab57-ff256d65bc2a
Content: Azure VMs high availability for SAP NetWeaver on SLES - Azure Virtual Machines
Content Source: articles/virtual-machines/workloads/sap/high-availability-guide-suse.md
Service: virtual-machines-sap
GitHub Login: @rdeltcheva
Microsoft Alias: radeltch

@susegrant Thanks for the feedback. We are investigating the issue and will update you shortly.

@susegrant,
I have assigned the issue to the content author to investigate further and update the document as appropriate. Thanks for the feedback once again.
@rdeltcheva,
Could you please review this and update the document as required. Thanks

I believe this has been fixed. #please-close


All collections using layout of first collections index found

Trying to get multiple collections to paginate I'm getting some odd behaviour where it uses the layout in the first pagination request it finds for all pages.
So for instance I have a number of different collections and for each collection I have a folder with an index that is the same name as the collection but without the underscore.
So my events collection has _events with my markdown files and events with index.html that should display that collection. I have the same for "gallery" and "results" collections.
If I only activate pagination for one collection it works fine. As soon as I activate it for more than one the generated index.html's for every collection appear to use the first one it finds (in alphabetical order).
I've tested this by renaming folders and moving the pagination using index.html's around. Whichever index.html it hits first with pagination enabled becomes the one used for all of my index.html's that have collections enabled. Even if its in the root and called something else the same thing still happens.
My index.html's have similar front matter and pagination logic which is basically:
---
layout: page
title: Results
pagination:
  enabled: true
  collection: results
---

{% for result in paginator.posts %}

            {{ result.title }}

            {{ result.date | date: "%A, %B %e, %Y at %I:%M%P" }}

{% endfor %}

Posting in the hope I'm being stupid but happy to add more details and replication steps if nobody can correct me quickly. Also can post original code to an open repo if needed as its an open source project.

@samfoley88 This seems to be a caching problem when using Jekyll 4. Until the maintainers release a fix you can use one of the forks from #182 or #195 as a workaround.

@salomvary Looks good to me as a fix and definitely explains the issue, my workaround is working for me but I'll close this issue out as those pull requests will definitely fix it when they get approved.


[Event Parameter Change] Codeunit 8 - AccSchedManagement - procedure CalcCellValue - Event OnBeforeCalcCellValue

We would like the parameter AccountScheduleLine and AccSchedCellValue added to the following events.
Codeunit 8 - AccSchedManagement - procedure CalcCellValue - Event OnBeforeCalcCellValue
Original:
OnBeforeCalcCellValue(AccSchedLine, ColumnLayout, CalcAddCurr, Result, IsHandled);

[IntegrationEvent(true, false)]
local procedure OnBeforeCalcCellValue(var AccSchedLine: Record "Acc. Schedule Line"; var ColumnLayout: Record "Column Layout"; CalcAddCurr: Boolean; var Result: Decimal; var IsHandled: Boolean)
begin
end;

Change
OnBeforeCalcCellValue(AccSchedLine, ColumnLayout, CalcAddCurr, Result, IsHandled, AccountScheduleLine, AccSchedCellValue); // <-- ADDED

[IntegrationEvent(true, false)]
local procedure OnBeforeCalcCellValue(var AccSchedLine: Record "Acc. Schedule Line"; var ColumnLayout: Record "Column Layout"; CalcAddCurr: Boolean; var Result: Decimal; var IsHandled: Boolean; AccountScheduleLine: Record "Acc. Schedule Line"; var AccSchedCellValue: Record "Acc. Sched. Cell Value" temporary) // <-- ADDED
begin
end;

We cannot do it as AccSchedCellValue  does not exist in this context, please provide full code to call this event.

procedure CalcCellValue(AccSchedLine: Record "Acc. Schedule Line"; ColumnLayout: Record "Column Layout"; CalcAddCurr: Boolean) Result: Decimal
    var
        GLAcc: Record "G/L Account";
        GLAccountCategory: Record "G/L Account Category";
        CostType: Record "Cost Type";
        CFAccount: Record "Cash Flow Account";
        GLAccCategoriesToVisit: Record "G/L Acc. Cat. Buffer";
        GLAccCategoriesVisited: Record "G/L Acc. Cat. Buffer";
        GLAccCatCode: Integer;
        IsHandled: Boolean;
    begin
        IsHandled := false;
        OnBeforeCalcCellValue(AccSchedLine, ColumnLayout, CalcAddCurr, Result, IsHandled);
        if not IsHandled then begin
            if AccSchedLine.Totaling = '' then
                exit(Result);

            if AccSchedCellValue.Get(AccSchedLine."Line No.", ColumnLayout."Line No.") then begin <-- We need this temporary var

We use the variable AccSchedCellValue for our own business logic and because of the temporary flag we can not get the record.

Thanks for reporting this. We agree, and we’ll publish a fix asap, either in an update for the current version or in the next major release. Please do not reply to this, as we do not monitor closed issues. If you have follow-up questions or requests, please create a new issue where you reference this one.
Build ID: 44246.