Mats Lemmens

Hi,

I had also alot of troubles getting my licenses to work and i used ChatGPT to help me. Here you can read what i and chatGPT found out and tried to make it work:



Houdini 22 hserver fails to start on Fedora due to SELinux (`203/EXEC`) — a solution

I ran into a licensing problem on Fedora 44 after installing/updating Houdini through the SideFX Launcher. I'm posting the solution here since this appears to be an SELinux issue and may affect other Fedora/RHEL-based distributions as well.

### Symptoms

Houdini reported that no valid licenses could be found, despite the License Administrator showing valid available licenses.

Checking the hserver service:


showed:

hserver.service: Failed at step EXEC spawning /usr/lib/sesi/hserver/hserver: Permission denied
Main process exited, status=203/EXEC

The executable itself existed and had normal Unix execute permissions:

-r-xr-xr-x. 1 root root ... /usr/lib/sesi/hserver/hserver

Trying the Houdini hserver client also showed that no hserver daemon was running:



### SELinux was blocking hserver

Checking the SELinux audit log:


showed denials such as:

avc: denied { execute } ...
scontext=system_u:system_r:init_t:s0
tcontext=system_u:object_r:hserver_rw_content_t:s0

After allowing that, further denials appeared for:

{ read open }

and eventually:

{ execute_no_trans }


The important part turned out to be the SELinux context assigned to the executable:



returned:

system_u:object_r:hserver_rw_content_t:s0

`restorecon` did not fix this because SELinux actually considered that to be the configured context:



also returned:

system_u:object_r:hserver_rw_content_t:s0

### Solution

Instead of adding increasingly broad SELinux exceptions, I changed the persistent SELinux context of the hserver executable to the normal `bin_t` executable type:




Afterwards:


showed the binary as `bin_t`.

Then I reset and restarted the service:



And:



finally showed:

Active: active (running)

Running:


then showed that hserver was running and connected to:

https://www.sidefx.com/license/sesinetd [www.sidefx.com]

Houdini could acquire its license normally again.


### Note about `audit2allow`

During troubleshooting I temporarily created a local SELinux policy using `audit2allow`. This was **not necessary after fixing the file context**.

I removed the temporary policy and restarted hserver again. It continued to work correctly, confirming that changing the context of `/usr/lib/sesi/hserver/hserver` to `bin_t` was the actual fix.

So if you're seeing:

hserver.service: Failed at step EXEC
status=203/EXEC
Permission denied

on Fedora or another SELinux-enabled distribution, check this first:



If the hserver executable is labeled `hserver_rw_content_t` and SELinux is blocking systemd from executing it, changing the persistent context of that executable to `bin_t` solved the problem for me.

**System in my case:**

* Fedora 44
* Houdini / hserver 22.0.368
* Installed through SideFX Launcher
* SELinux enforcing

Hi,

I have the same problem but when using the rbdbulletsolver sop. Not any of the force-guides show up when toggled on or off.

I am able to show them when doing the following:

When going into your vellumsolver/rbdbulletsolver, up top where the "breadcrumbs" or "adress" shows you where you are, you can see that you actually jumped an extra layer deeper. A dopnet is suddenly extra there. That's normal because how those nodes are build up, but if you enter that dopnet (click on it in the breadcrumb-thing), you enter a "locked off" dopnet and suddenly the guides are visible in the viewport, at least if you toggled them on on your force. If you now pin your viewport to that view, you can go back to the forces and adjust them.

The so called breadcrumb (I'm sorry, I don't have a better word)



So it seems that the toggle or view of the forces gets lost in the whole dop-setup that simplifies the rbdbulletsolver and vellumsolver.

edit: I am on version 21.0.440 on Linux.

I know it is an older post, but as johnmater is saying they want to improve the tools in there i have some remarks and maybe it get's some attention:

I'm working in the simulation industry and we often have to generate meshes from pointclouds that are several square kilometers. The pointclouds are not always perfect square and are, in my case, mostly following a river so i have very long but (relativly) narrow points clowds.

For these large pointclouds you often struggle with the sheer size. The pointcloud surface node has to have a very high subdivision to keep some detail. Wich results in a very high memory usage and is mostly unworkable. It also generates a border mesh around the pointcloud wich is going to big.

Another big problem is that the pointclouds we get are mostly already processed clouds: they have been converted into a very even grid point cloud. It looks like: 3D pointcloud to 2D pointcloud and added the height information again. It gives you a kind of JPEG compression: you have jagged edges.
If you mesh a pointcloud like this one, you'll get very jagged edges if a corner or difference in height is not exactly on the grid-lines. It would be nice if we could apply some kind of guid-geometry (curves, lines, ...) so that the surface-node takes them into account when connecting certain points. I'm thinking of something like you can add flow-lines from wich you can set the influence (and influence distance) it has on the pointcloud-surfacing so that it prioritizes the flowlines first when looking for the best points to connect.

or am i looking for a solution that already exists?

Thanks for reading!