Build and include FreeBSD releases

Is your feature request related to a problem? Please describe. No FreeBSD releases available yet. With the merged PRs #207 and #208 it is now possible to build for and run rustdesk-server on FreeBSD. Those PRs are also a solution for the closed Issue #141 .

Describe the solution you'd like Extending the cargo builds with cargo build --release --target=x86_64-unknown-freebsd gives the opportunity to create an all-in-one FreeBSD install script, like the one listed at https://rustdesk.com/docs/en/self-host/install/ . Or it can be even merged into it, to have one overall script, which handles things for Linux targets and FreeBSD target[s].

The above mentioned #207 and #208 have been merged, consider to close this issue. (Or document for which reason it should remain open. (Do know that dangling issues cost human energy.))

Help me with some guidance here, what is the way to ask for automatic FreeBSD build from now on for new releases? Maybe its already a done deal here and I just can't see the signs? I do not know, fix me. Maybe the title unclear?

If this is the case (eg. from next release there wil a FreeBSD build already - as build works, plus rcd scripts provided) I'm happy to close this one of course.

Previously I wrote:

The above mentioned https://github.com/rustdesk/rustdesk-server/pull/207 and https://github.com/rustdesk/rustdesk-server/pull/208 have been merged, consider to close this issue.

In reply to the Help me with some guidance can only provide this link: https://github.com/rustdesk/rustdesk-server/tree/master/.github/workflows

My apologies that I missed the word merged in "With the merged PRs https://github.com/rustdesk/rustdesk-server/pull/207 and https://github.com/rustdesk/rustdesk-server/pull/208 it" from the opening of this issue.

Previously I wrote:

The above mentioned #207 and #208 have been merged, consider to close this issue.

In reply to the Help me with some guidance can only provide this link: https://github.com/rustdesk/rustdesk-server/tree/master/.github/workflows

Thanks I'll check it and make a PR for build.yaml. "This is the way."(?)

My apologies that I missed the word merged in "With the merged PRs #207 and #208 it" from the opening of this issue.

No problem, thanks for the answers.

Hi @n-connect,

After reading above discussion I installed rust (pkg install rust) and cloned rustdesk-server (git clone https://github.com/rustdesk/rustdesk-server.git). Then I compiled everyting by typing: cargo build --release --target=x86_64-unknown-freebsd. Up to this point, no problem. Everything seems to be compiled properly (no errors, no warnings), but I can't run hbbs nor hbbr. Both generates message Segmentation fault (core dumped) (rustdesk-utils works). Dou you have any idea why?

Regards, Mickey

Hi Mickey,

Well pretty much the same experience I have had for my first try. I've did use an older rust, installed via the rustup.rs curl way - a year or so. That give me a core dump too. Then I've unmade the changes the rustup based install did to the user's BASH environment, installed rust from pkg on FB13.x and the build worked and the binaries running non-stop since with the rcd scripts. So maybe you have a same double rust behind the curtains.

My route would be:

make sure not other rust binaries in your box, by checking your [BASH] environment setup vs. the official rust pkg files' path, which rustc which cargo is a good start for that (both under /usr/local/bin/ in the pkg's version & rust v1.67.1 is what I have on the build box)
2nd we can compare more your box SW versions with the one I did the non-core dumped build;
3rd I can share the binaries/rcd scripts as they are exist in my system and you can test it (eg. the auto build FreeBSD package still not runs over the official repo, I need to check it with the repo owners)

First I installed rust from pkg - version 1.66.0. Now I have 1.68.0 - installed from ports. Compiled again, and again only code dump :(

List of my packages: https://misiak.mini.net.pl/~marcinkk/gamma-pkg-info.txt

Maybe important: I have FreeBSD gamma 13.1-RELEASE-p6 FreeBSD 13.1-RELEASE-p6 GENERIC amd64

I can test binaries compiled by you if you share :)

BTW: Maybe somebody understand anything from below:

root@gamma# lldb --core hbbr.core hbbr
(lldb) target create "hbbr" --core "hbbr.core"
Core file '/root/rustdesk-server/target/x86_64-unknown-freebsd/release/hbbr.core' (x86_64) was loaded.
(lldb) bt all
* thread #1, name = 'hbbr', stop reason = signal SIGSEGV
  * frame #0: 0x000000080160239c libc.so.7`___lldb_unnamed_symbol5309 + 684
    frame #1: 0x0000000801642f75 libc.so.7`___lldb_unnamed_symbol5929 + 21
    frame #2: 0x00000008015f545c libc.so.7`___lldb_unnamed_symbol5275 + 572
    frame #3: 0x00000000013766ae hbbr`std::thread::local::os::Key$LT$T$GT$::get::h62d2fa0d8d4f0df6 + 126
    frame #4: 0x0000000001375462 hbbr`std::sys::unix::stack_overflow::imp::signal_handler::h3dc854a94ced3d4e (.llvm.7236699097735503739) + 34
    frame #5: 0x000000080145158e libthr.so.3`___lldb_unnamed_symbol672 + 222
    frame #6: 0x0000000801450b3f libthr.so.3`___lldb_unnamed_symbol653 + 319
    frame #7: 0x00007ffffffff2d3 [vdso]
    frame #8: 0x0000000801450634 libthr.so.3`___lldb_unnamed_symbol649 + 36
    frame #9: 0x000000080144d400 libthr.so.3`___lldb_unnamed_symbol615 + 512
    frame #10: 0x00000008016246d1 libc.so.7`___lldb_unnamed_symbol5726 + 977
    frame #11: 0x00000008016242f9 libc.so.7`___lldb_unnamed_symbol5725 + 57
    frame #12: 0x000000080160105d libc.so.7`___lldb_unnamed_symbol5299 + 141
    frame #13: 0x000000080162ac2d libc.so.7`___lldb_unnamed_symbol5781 + 381
    frame #14: 0x00000008016434f3 libc.so.7`___lldb_unnamed_symbol5934 + 179
    frame #15: 0x000000080164342a libc.so.7`___lldb_unnamed_symbol5933 + 42
    frame #16: 0x000000080164637a libc.so.7`___lldb_unnamed_symbol5954 + 506
    frame #17: 0x00000008015f534b libc.so.7`___lldb_unnamed_symbol5275 + 299
    frame #18: 0x0000000801647e81 libc.so.7`strdup + 33
    frame #19: 0x00000008014489a1 libthr.so.3`pthread_setname_np + 33
    frame #20: 0x0000000001240246 hbbr`core::ops::function::FnOnce::call_once$u7b$$u7b$vtable.shim$u7d$$u7d$::h23e41d67404fac5f + 54
    frame #21: 0x0000000001372a83 hbbr`std::sys::unix::thread::Thread::new::thread_start::h322067834044ed53 + 35
    frame #22: 0x000000080144783a libthr.so.3`___lldb_unnamed_symbol556 + 314
  thread #2, name = 'hbbr', stop reason = signal SIGSEGV
    frame #0: 0x00000008015acc57 libc.so.7`___lldb_unnamed_symbol4943 + 983
    frame #1: 0x00000008015ad98c libc.so.7`___lldb_unnamed_symbol4945 + 108
    frame #2: 0x00000008015ad34a libc.so.7`___lldb_unnamed_symbol4943 + 2762
    frame #3: 0x00000008015ab925 libc.so.7`___lldb_unnamed_symbol4936 + 117
    frame #4: 0x00000008015abf23 libc.so.7`localtime_r + 51
    frame #5: 0x0000000001263beb hbbr`chrono::sys::inner::time_to_local_tm::hd55de47a583680c3 + 59
    frame #6: 0x0000000001263568 hbbr`chrono::offset::local::Local::now::h11f5db0001ef10a1 + 88
    frame #7: 0x000000000121fe86 hbbr`std::sys_common::once::futex::Once::call::ha6c502a1b8f8cd43 + 470
    frame #8: 0x000000000122280b hbbr`flexi_logger::logger::Logger::build::h10998bbe783dbd10 + 2379
    frame #9: 0x0000000001221dc1 hbbr`flexi_logger::logger::Logger::start::hdb64b8d923f2fac2 + 49
    frame #10: 0x00000000011eb13a hbbr`hbbr::main::h7ec3500d3c2e6140 + 586
    frame #11: 0x00000000011e6ee3 hbbr`std::sys_common::backtrace::__rust_begin_short_backtrace::h6f8eddb95fa66e4b + 3
    frame #12: 0x00000000011f863d hbbr`std::rt::lang_start::_$u7b$$u7b$closure$u7d$$u7d$::h47944d3367941517 (.llvm.15953086576710281006) + 13
    frame #13: 0x0000000001382df4 hbbr`std::rt::lang_start_internal::h6f6837c266f742ab + 36
    frame #14: 0x00000000011eba55 hbbr`main + 37
    frame #15: 0x0000000001199d6d hbbr`_start(ap=<unavailable>, cleanup=<unavailable>) at crt1_c.c:75:7
  thread #3, name = 'flexi_logger-async_', stop reason = signal SIGSEGV
    frame #0: 0x000000080144d334 libthr.so.3`___lldb_unnamed_symbol615 + 308
    frame #1: 0x000000080162a0e1 libc.so.7`___lldb_unnamed_symbol5764 + 321
    frame #2: 0x00000008016276ea libc.so.7`___lldb_unnamed_symbol5746 + 1114
    frame #3: 0x00000008016297d4 libc.so.7`___lldb_unnamed_symbol5760 + 356
    frame #4: 0x00000008016245bd libc.so.7`___lldb_unnamed_symbol5726 + 701
    frame #5: 0x00000008016258dd libc.so.7`___lldb_unnamed_symbol5734 + 317
    frame #6: 0x000000080160296c libc.so.7`___lldb_unnamed_symbol5310 + 1212
    frame #7: 0x0000000801602386 libc.so.7`___lldb_unnamed_symbol5309 + 662
    frame #8: 0x0000000801642f75 libc.so.7`___lldb_unnamed_symbol5929 + 21
    frame #9: 0x00000008015f545c libc.so.7`___lldb_unnamed_symbol5275 + 572
    frame #10: 0x0000000001211762 hbbr`alloc::raw_vec::finish_grow::hc4d8b21d43712421 (.llvm.9975479776143828597) + 82
    frame #11: 0x00000000012118fe hbbr`alloc::raw_vec::RawVec$LT$T$C$A$GT$::reserve_for_push::h1a452b0124dc3e99 + 142
    frame #12: 0x0000000001229f5c hbbr`crossbeam_channel::context::Context::with::_$u7b$$u7b$closure$u7d$$u7d$::he35a475b9894a235 + 268
    frame #13: 0x000000000122ac94 hbbr`crossbeam_channel::flavors::list::Channel$LT$T$GT$::recv::hfba6570df6cf995e + 740
    frame #14: 0x0000000001232824 hbbr`crossbeam_channel::channel::Receiver$LT$T$GT$::recv::hab3e367e99e8b8da + 84
    frame #15: 0x0000000001237482 hbbr`std::sys_common::backtrace::__rust_begin_short_backtrace::h0530f5bc32947271 + 98
    frame #16: 0x0000000001240c5e hbbr`core::ops::function::FnOnce::call_once$u7b$$u7b$vtable.shim$u7d$$u7d$::hfe08b5dbd4a466bc + 190
    frame #17: 0x0000000001372a83 hbbr`std::sys::unix::thread::Thread::new::thread_start::h322067834044ed53 + 35
    frame #18: 0x000000080144783a libthr.so.3`___lldb_unnamed_symbol556 + 314

The FreeBSD build with Github Actions is actually happening, but it core dumps as yours. Finding out why yours is failing, could help with the Github Actions Linux box build fail's root cause as well. I was failed to see the build, as it literally put Linux into the name rustdesk-server-linux-amd64fb.zip, which I realized directly comes from my PR, but still 😄. Anyway, please let me know the following:

size of the 3 binaries
or just zip 'em up including the core dumps and share with me
TODO on my part, update the GitHub Actions, so FreeBSD builds will have freebsd in the zip name and add the rcd scripts somehow.

The temporary repo with the working binaries at the end of the original comment.

Original comment below: I have a 13.1 p3 instead of p6. I don't see the reason why yours fail to run yet, but I'm no rust guru. The Github Actions build happens on a Linux box for Linux (and supposedly for FreeBSD - TBD) and a Windows one for Windows build.

uname -a;ps auxd | grep rustdesk;pkg info -d rust
FreeBSD xxxxxxx 13.1-RELEASE-p3 FreeBSD 13.1-RELEASE-p3 GENERIC amd64
rustdesk 14012   0.0  0.1    12852   1836  -  Is    4Mar23      0:00.00 |-- daemon: /usr/local/sbin/hbbs[14013] (daemon)
rustdesk 14013   0.0  0.4   469708   8524  -  S     4Mar23      7:44.08 | `-- /usr/local/sbin/hbbs -r x.y.v.w -k _
rustdesk 14090   0.0  0.1    12852   1836  -  Is    4Mar23      0:00.00 |-- daemon: /usr/local/sbin/hbbr[14091] (daemon)
rustdesk 14091   0.0  0.3   265552   5416  -  I     4Mar23      0:00.74 | `-- /usr/local/sbin/hbbr -k _
rust-1.67.1:
        curl-7.85.0

The rust package not really depends on anything, except downloading capability the package itself. As it should be - if I understand the whole rust concept well. The hbbs & hubbr runs since March 2, the first build beside moderate weekly usage. No crash since that build, so I'd say it works well. Some manual restarts, poking around the rcd scripts logging destinations. I put up a repo with my build and link it here: rustd-hbbx, let me know what's the results on your box. If something still not works we can organize a screen-sharing session, there's this thing called Rustdesk 😉

Looks like you were lucky ;)

I downloaded your working files and ... Segmentation fault (core dumped).

My build with core dumps: https://misiak.mini.net.pl/~marcinkk/hbb_fbsd_with_cores.tar.zip. Archive contains realese and debug builds.

BTW: I had 13.1 p1 and the coredumps, so I made an upgrade to the newest 13.1 p6 with the same result.

interesting. I'm not sure yet, what's the root cause, because of point 3. The patch level alone on OS level is to small of a difference. It can be additional layers of security, e.g. ASLR in /etc/rc.conf etc. But I'm leaning more to or rust/cargo version:

1.62 on autobuild's Ubuntu 18.04 VM -> binary file says its for FB 12.3,
1.67.1 my builds -> binary says no FB version
1.68 yours -> binary says no FB version

Downloaded my tar.gz to another FB box, it works (-p3 patchlevel too)

Downloaded your zip onto the same box, that works too

ls -la
total 55860
drwxr-xr-x  2 root  wheel         7 Mar 26 15:29 .
drwxr-xr-x  6 root  wheel        14 Mar 26 16:08 ..
-rwxr-xr-x  1 root  wheel   5616192 Mar 26 13:16 hbbr
-rw-------  1 root  wheel  20250624 Mar 26 13:41 hbbr.core
-rwxr-xr-x  1 root  wheel   9991496 Mar 26 13:16 hbbs
-rw-------  1 root  wheel  20316160 Mar 26 13:41 hbbs.core
-rwxr-xr-x  1 root  wheel    740496 Mar 26 13:16 rustdesk-utils
# ./hbbs
[2023-03-26 16:40:46.919666 +02:00] INFO [src/common.rs:143] Private/public key written to id_ed25519/id_ed25519.pub
[2023-03-26 16:40:46.919720 +02:00] INFO [src/peer.rs:84] DB_URL=./db_v2.sqlite3
^C
# ls -la
total 55877
drwxr-xr-x  2 root  wheel        10 Mar 26 16:40 .
drwxr-xr-x  6 root  wheel        14 Mar 26 16:08 ..
-rw-r--r--  1 root  wheel         0 Mar 26 16:40 db_v2.sqlite3
-rwxr-xr-x  1 root  wheel   5616192 Mar 26 13:16 hbbr
-rw-------  1 root  wheel  20250624 Mar 26 13:41 hbbr.core
-rwxr-xr-x  1 root  wheel   9991496 Mar 26 13:16 hbbs
-rw-------  1 root  wheel  20316160 Mar 26 13:41 hbbs.core
-rw-r--r--  1 root  wheel        88 Mar 26 16:40 id_ed25519
-rw-r--r--  1 root  wheel        44 Mar 26 16:40 id_ed25519.pub
-rwxr-xr-x  1 root  wheel    740496 Mar 26 13:16 rustdesk-utils

Downloaded the main repo's autobuild to that other box rustdesk-server-linux-amd64fb.zip , it core dumps

file amd64fb/hbbs
amd64fb/hbbs: ELF 64-bit LSB pie executable, x86-64, version 1 (FreeBSD), dynamically linked, interpreter /libexec/ld-elf.so.1, for FreeBSD 12.3, FreeBSD-style, with debug_info, not stripped

Recreated the tar.gz in my temporary repo, pls. download it again, extract with -C and try again.

Test the updated tar.gz and let me know. We can move from there. Next I think we should do a screen sharing, I'll contact you with the details if we are there

Hmmm... Interesting... I think...

I don't know why I've done it (for testing...), but take a look below:

root@gamma:~/rustdesk-server# echo "$SHELL"
/bin/csh
root@gamma:~/rustdesk-server# /usr/local/sbin/hbbr
Segmentation fault (core dumped)
root@gamma:~/rustdesk-server# bash
[root@gamma ~/rustdesk-server]# echo "$SHELL"
/bin/csh
[root@gamma ~/rustdesk-server]# /usr/local/sbin/hbbr
[2023-03-27 12:39:20.718241 +02:00] INFO [src/relay_server.rs:60] #blacklist(blacklist.txt): 0
[2023-03-27 12:39:20.718280 +02:00] INFO [src/relay_server.rs:75] #blocklist(blocklist.txt): 0
[2023-03-27 12:39:20.718306 +02:00] INFO [src/relay_server.rs:81] Listening on tcp :21117
[2023-03-27 12:39:20.718312 +02:00] INFO [src/relay_server.rs:83] Listening on websocket :21119
[2023-03-27 12:39:20.718379 +02:00] INFO [src/relay_server.rs:86] Start
[2023-03-27 12:39:20.718458 +02:00] INFO [src/relay_server.rs:106] DOWNGRADE_THRESHOLD: 0.66
[2023-03-27 12:39:20.718484 +02:00] INFO [src/relay_server.rs:115] DOWNGRADE_START_CHECK: 1800s
[2023-03-27 12:39:20.718493 +02:00] INFO [src/relay_server.rs:124] LIMIT_SPEED: 4Mb/s
[2023-03-27 12:39:20.718501 +02:00] INFO [src/relay_server.rs:134] TOTAL_BANDWIDTH: 1024Mb/s
[2023-03-27 12:39:20.718509 +02:00] INFO [src/relay_server.rs:148] SINGLE_BANDWIDTH: 16Mb/s

The same with files compiled by you and with my builds.

bash is required?

I have to find a little more time for full run and test, but as can you see, started without core dump.

[I deleted the message written here ... it didn't worked as described.]

I've tried to make the script starting hbbs and hbbr with shebang #!/usr/local/bin/bash. I've tried to change the sheband in rc.d scripts. Without success :(

I can run successfully both services if I first start the bash shell. So the below works:

# bash
# service rustdesk-hbbs start
# service rustdesk-hbbr start

But when I'm trying to start services from csh or sh then I notice core dumps :( The same after system restart.

It is also possible to start hbbr and hbbs inside screen.

Finally I started hbbr and hbbs and I made a connection between two Windows machines :)

But I don't know why I have to use bash or screen :(

Okay, good catch!

I have the users set with bash, but the rc.d script uses /bin/sh (Bourne Again Shell, vs bourne SHell). In FreeBSD they set the environment from ~/.shrc (for /bin/sh) only PS line for prompt ~/.cshrc (for /bin/csh) one line for unmask

So for first I'd say, if you have go to the git repo with my build/tar.gz and extract everything, check the Readme.md do the steps there, including changes to the IP address in the /usr/local/etc/rc.d/rustdesk-hbbs script to yours, I say there's a big change it will work cause it not using csh.

In parallel, there's the interesting question why it dumps with csh. Can you share your ~/.cshrc /etc/login.conf?

I modified my prevoius comment. The idea with the script with shebang #!/usr/local/bin/bash doesn't work.

As I wrote in the modified post: I can run bot services and they works properly, but first I need to run bash or screen.

So I made modification to starting scripts:

command="/usr/local/bin/screen"
command_args="-dm /usr/sbin/daemon -p ${pidfile} -o /var/log/rustdesk-hbbs.log ${procname} ${rustdesk_hbbs_args}"

and

command="/usr/local/bin/screen"
command_args="-dm /usr/sbin/daemon -p ${pidfile} -o /var/log/rustdesk-hbbr.log ${procname} ${rustdesk_hbbr_args}"

Then I rebooted the server to be sure that both scripts were working properly. And I can confirm: my own Rustdesk Server is working right after gamma server starts :)

Both scrips are here: https://misiak.mini.net.pl/~marcinkk/rustdesk_rcd_scripts.tar.gz

Ok, do you have a special, magical relationship with csh, or it just the default how you got your system? E.g. can your can let it go, if I can't find the root cause with it?

Things I'd test from easier to final:

what if we simply move to bash on user level/re-login and test the "original" rc.d scripts I included (by they way they updated here in the main repo - now are identical with my temporary repo's tar.gz files)?
I'd see, what's the problem with those scripts on your system
what's up with the csh core dumps?

The best, if we have a common screen sharing session together

I have the original csh configuration for the user and for root.

Did you mean:

marcinkk@gamma:~ % bash
[marcinkk@gamma ~]$ hbbr --version
hbbr 1.1.7-1
[marcinkk@gamma ~]$ sudo su
root@gamma:/usr/home/marcinkk # hbbr --version
hbbr 1.1.7-1

No core dumps. The same with the screen and sudo su inside.

I made test on my 2 different servers. The first one with 13.1 and the second one with 12.3. My scripts, with the screen works on both. Without screen or bash -> Segmentation fault (core dumped).

Another sh or csh under csh -> core dump.

I think bash and screen changes something, but I have no idea what :(

BTW: @n-connect, did you make reboot test? Services started? What shell do you have for root:

marcinkk@gamma:~ % cat /etc/passwd | grep root
root:*:0:0:Charlie &:/root:/bin/csh

For interactive users, e.g which I do manage stuff - I'm not using csh, I use bash. As I wrote earlier, the rc.d scripts are fully working - start/stop/restart everything - I've tested them on 2 boxes before I've added them into this repo via PRs.

I was thinking on some limitation in your shell environment like ulimit or so, or global hardening. As asked you if there's any of such things in the rc.conf

I've asked for the the content of these , only the non-commented lines interesting ~/.shrc (for /bin/sh) ~/.cshrc (for /bin/csh) Plus the login.conf, again the non-commented.

After all It is possible that there's something with the "older" rust/cargo builds as the Github Actions Ubuntu 18.04 VM based ones are failing on mine compared to your build or my build. As my build works on your FreeBSD-s and yours working on mine, logic says something off, or at least different on with the [t]csh shell.

I'll write you directly, cause we are just running in circles while, I'm asking the same questions. I need like 5-10 minutes to see your FreeBSDs over screen sharing and do those checks I need the info from :)

Hmmm... I hope somebody will understood anything :/

I've compiled the debug build and then analyzed the core file:

root@gamma:~/rustdesk-server# lldb --core ./hbbr.core ./target/x86_64-unknown-freebsd/debug/hbbr
(lldb) target create "./target/x86_64-unknown-freebsd/debug/hbbr" --core "./hbbr.core"
Core file '/root/rustdesk-server/hbbr.core' (x86_64) was loaded.
(lldb) bt all
error: need to add support for DW_TAG_base_type '()' encoded with DW_ATE = 0x7, bit_size = 0
error: need to add support for DW_TAG_base_type '()' encoded with DW_ATE = 0x7, bit_size = 0
error: need to add support for DW_TAG_base_type '()' encoded with DW_ATE = 0x7, bit_size = 0
* thread #1, name = 'hbbr', stop reason = signal SIGSEGV
  * frame #0: 0x0000000801c1239c libc.so.7`___lldb_unnamed_symbol5309 + 684
    frame #1: 0x0000000801c52f75 libc.so.7`___lldb_unnamed_symbol5929 + 21
    frame #2: 0x0000000801c0545c libc.so.7`___lldb_unnamed_symbol5275 + 572
    frame #3: 0x00000000019438be hbbr`std::thread::local::os::Key$LT$T$GT$::get::h62d2fa0d8d4f0df6 + 126
    frame #4: 0x0000000001942672 hbbr`std::sys::unix::stack_overflow::imp::signal_handler::h3dc854a94ced3d4e (.llvm.7236699097735503739) + 34
    frame #5: 0x0000000801a6158e libthr.so.3`___lldb_unnamed_symbol672 + 222
    frame #6: 0x0000000801a60b3f libthr.so.3`___lldb_unnamed_symbol653 + 319
    frame #7: 0x00007ffffffff2d3 [vdso]
    frame #8: 0x0000000801c342f9 libc.so.7`___lldb_unnamed_symbol5725 + 57
    frame #9: 0x0000000801c1105d libc.so.7`___lldb_unnamed_symbol5299 + 141
    frame #10: 0x0000000801c3ac2d libc.so.7`___lldb_unnamed_symbol5781 + 381
    frame #11: 0x0000000801c534f3 libc.so.7`___lldb_unnamed_symbol5934 + 179
    frame #12: 0x0000000801c5342a libc.so.7`___lldb_unnamed_symbol5933 + 42
    frame #13: 0x0000000801c5637a libc.so.7`___lldb_unnamed_symbol5954 + 506
    frame #14: 0x0000000801c0534b libc.so.7`___lldb_unnamed_symbol5275 + 299
    frame #15: 0x0000000801c57e81 libc.so.7`strdup + 33
    frame #16: 0x0000000801a589a1 libthr.so.3`pthread_setname_np + 33
    frame #17: 0x000000000147dc6f hbbr`std::thread::Builder::spawn_unchecked_::_$u7b$$u7b$closure$u7d$$u7d$::h08cda037be51d433 at mod.rs:546:17
    frame #18: 0x000000000144c58f hbbr`core::ops::function::FnOnce::call_once$u7b$$u7b$vtable.shim$u7d$$u7d$::hd21456132012d641((null)=0x0000000802219140, (null)=<unavailable>) at function.rs:250:5
    frame #19: 0x000000000193fc93 hbbr`std::sys::unix::thread::Thread::new::thread_start::h322067834044ed53 + 35
    frame #20: 0x0000000801a5783a libthr.so.3`___lldb_unnamed_symbol556 + 314
  thread #2, name = 'hbbr', stop reason = signal SIGSEGV
    frame #0: 0x0000000001533779 hbbr`core::ops::range::RangeBounds::contains::h224c81410e7a97d4 [inlined] core::cmp::impls::_$LT$impl$u20$core..cmp..PartialOrd$LT$$RF$B$GT$$u20$for$u20$$RF$A$GT$::le::hecb87d4909b164b4 at cmp.rs:1553:13
    frame #1: 0x0000000001533768 hbbr`core::ops::range::RangeBounds::contains::h224c81410e7a97d4(self=0x00000000011148f4, item=0x00007fffffff860c) at range.rs:820:30
    frame #2: 0x0000000001534184 hbbr`core::ops::range::RangeInclusive$LT$Idx$GT$::contains::h5ee74ac051fceb4a(self=0x00000000011148f4, item=0x00007fffffff860c) at range.rs:508:9
    frame #3: 0x000000000152efd3 hbbr`chrono::offset::local::tz_info::rule::parse_rule_time::h5045ad8279ca77ad(cursor=0x00007fffffff8c70) at rule.rs:385:9
    frame #4: 0x0000000001530699 hbbr`chrono::offset::local::tz_info::rule::RuleDay::parse::h8a696deacc72bf63(cursor=0x00007fffffff8c70, use_string_extensions=false) at rule.rs:492:34
    frame #5: 0x000000000152c4b0 hbbr`chrono::offset::local::tz_info::rule::TransitionRule::from_tz_string::h99ba913dd9aadce8(tz_string=(data_ptr = "CET-1CEST,M3.5.0,M10.5.0/3\n", length = 26), use_string_extensions=false) at rule.rs:55:39
    frame #6: 0x00000000015232c8 hbbr`chrono::offset::local::tz_info::parser::parse::hcead044d0a34acd8(bytes=(data_ptr = "TZif2", length = 2679)) at parser.rs:91:31
    frame #7: 0x000000000151c5fa hbbr`chrono::offset::local::tz_info::timezone::TimeZone::from_tz_data::hea629c942e03ce03(bytes=(data_ptr = "TZif2", length = 2679)) at timezone.rs:92:9
    frame #8: 0x000000000151bbec hbbr`chrono::offset::local::tz_info::timezone::TimeZone::from_posix_tz::hcf94eebd94e898db(tz_string=(data_ptr = "", length = 9)) at timezone.rs:43:20
    frame #9: 0x000000000151b9b8 hbbr`chrono::offset::local::tz_info::timezone::TimeZone::local::he9dd391063f5f08f(env_tz=Option<&str> @ 0x00007fffffffac78) at timezone.rs:32:21
    frame #10: 0x0000000001540e5d hbbr`chrono::offset::local::inner::current_zone::h20c0d5b0c067d2ac(var=Option<&str> @ 0x00007fffffffae18) at unix.rs:101:5
    frame #11: 0x0000000001540d92 hbbr`_$LT$chrono..offset..local..inner..Cache$u20$as$u20$core..default..Default$GT$::default::hb400e3ea0e5b5fa5 at unix.rs:95:19
    frame #12: 0x0000000001538541 hbbr`core::ops::function::FnOnce::call_once::h6ac121518b12fa64((null)=0x0000000801a41090, (null)=<unavailable>) at function.rs:250:5
    frame #13: 0x0000000001541b5d hbbr`core::option::Option$LT$T$GT$::get_or_insert_with::hd402b23e74458710(self=0x000000080223e010, f=0x000000080223e008) at option.rs:1591:49
    frame #14: 0x00000000015405e7 hbbr`chrono::offset::local::inner::naive_to_local::_$u7b$$u7b$closure$u7d$$u7d$::hfa6a77b943aba298(maybe_cache=0x000000080223e008) at unix.rs:24:9
    frame #15: 0x0000000001538020 hbbr`std::thread::local::LocalKey$LT$T$GT$::try_with::hb8c13e2bcc91d692(self=0x00000000019a1140, f={closure_env#0} @ 0x00007fffffffb368) at local.rs:446:16
    frame #16: 0x0000000001537ea8 hbbr`std::thread::local::LocalKey$LT$T$GT$::with::h65aacb341fb30ebc(self=0x00000000019a1140, f={closure_env#0} @ 0x00007fffffffb428) at local.rs:422:9
    frame #17: 0x0000000001540553 hbbr`chrono::offset::local::inner::naive_to_local::h578642d0aaa7e588(d=0x00007fffffffb480, local=false) at unix.rs:23:5
    frame #18: 0x00000000015404e9 hbbr`chrono::offset::local::inner::now::he55a1137d0664da5 at unix.rs:19:5
    frame #19: 0x00000000015282dd hbbr`chrono::offset::local::Local::now::h4f370bf16d75b603 at mod.rs:74:9
    frame #20: 0x000000000144c6c5 hbbr`core::ops::function::FnOnce::call_once::h0ac748e508a5811b at deferred_now.rs:134:45
    frame #21: 0x000000000144c5b7 hbbr`core::ops::function::FnOnce::call_once::h0ac748e508a5811b((null)=(hbbr`_$LT$flexi_logger..util..ERROR_CHANNEL$u20$as$u20$core..ops..deref..Deref$GT$::deref::__stability::LAZY::h2c2e691d4d8ecfc7), (null)=<unavailable>) at function.rs:250:5
    frame #22: 0x000000000145b8ef hbbr`lazy_static::lazy::Lazy$LT$T$GT$::get::_$u7b$$u7b$closure$u7d$$u7d$::hfaef8f6462edbd99 at inline_lazy.rs:31:29
    frame #23: 0x00000000014495f7 hbbr`std::sync::once::Once::call_once::_$u7b$$u7b$closure$u7d$$u7d$::h066c1cd6dd01023f((null)=0x00007fffffffb6d0) at once.rs:143:41
    frame #24: 0x000000000141d29c hbbr`std::sys_common::once::futex::Once::call::hbe2c13a80a68e6d4(self=0x0000000001a05b90, ignore_poisoning=false, f=0x00007fffffffb870) at futex.rs:113:21
    frame #25: 0x00000000014493aa hbbr`std::sync::once::Once::call_once::h50c03c841b06b76c(self=0x0000000001a05b90, f={closure_env#0}<time::utc_offset::UtcOffset, fn() -> time::utc_offset::UtcOffset> @ 0x00007fffffffb888) at once.rs:143:9
    frame #26: 0x00000000014826ea hbbr`_$LT$flexi_logger..deferred_now..OFFSET$u20$as$u20$core..ops..deref..Deref$GT$::deref::h0eda486bfda42e04 [inlined] lazy_static::lazy::Lazy$LT$T$GT$::get::hef03bb0a4b13c7ca(self=0x0000000001a05b8c) at inline_lazy.rs:30:9
    frame #27: 0x00000000014826c5 hbbr`_$LT$flexi_logger..deferred_now..OFFSET$u20$as$u20$core..ops..deref..Deref$GT$::deref::h0eda486bfda42e04 [inlined] _$LT$flexi_logger..deferred_now..OFFSET$u20$as$u20$core..ops..deref..Deref$GT$::deref::__stability::h75bf217b64043ebc at lib.rs:142:21
    frame #28: 0x00000000014826c5 hbbr`_$LT$flexi_logger..deferred_now..OFFSET$u20$as$u20$core..ops..deref..Deref$GT$::deref::h0eda486bfda42e04(self=0x000000000110efb9) at lib.rs:144:17
    frame #29: 0x000000000148106b hbbr`flexi_logger::deferred_now::DeferredNow::now_local::h8c12c95991451071 at deferred_now.rs:118:45
    frame #30: 0x000000000144c901 hbbr`core::ops::function::FnOnce::call_once::h6df01ee174001c54((null)=(hbbr`_$LT$flexi_logger..util..ERROR_CHANNEL$u20$as$u20$core..ops..deref..Deref$GT$::deref::__stability::LAZY::h2c2e691d4d8ecfc7), (null)=<unavailable>) at function.rs:250:5
    frame #31: 0x000000000146ba27 hbbr`core::option::Option$LT$T$GT$::get_or_insert_with::h744df7045bd4f2a4(self=0x00007fffffffc358, f=0x0000000000000000) at option.rs:1591:49
    frame #32: 0x0000000001480e8b hbbr`flexi_logger::deferred_now::DeferredNow::now::h9d8d1fdc2b4447f0(self=0x00007fffffffc358) at deferred_now.rs:29:9
    frame #33: 0x0000000001455bf8 hbbr`flexi_logger::logger::Logger::build::hf63c1faf0e1e5178(self=Logger @ 0x00007fffffffc610) at logger.rs:721:9
    frame #34: 0x0000000001454ad1 hbbr`flexi_logger::logger::Logger::start::h4615f0098133c58c(self=<unavailable>) at logger.rs:649:38
    frame #35: 0x00000000013b331b hbbr`hbbr::main::h8d9e882749eda667 at hbbr.rs:10:19
    frame #36: 0x000000000139b8eb hbbr`core::ops::function::FnOnce::call_once::h3f5d71b90c74b1e6((null)=(hbbr`hbbr::main::h8d9e882749eda667 at hbbr.rs:9), (null)=<unavailable>) at function.rs:250:5
    frame #37: 0x00000000013c081e hbbr`std::sys_common::backtrace::__rust_begin_short_backtrace::hc9a797e5f20e068a(f=(hbbr`hbbr::main::h8d9e882749eda667 at hbbr.rs:9)) at backtrace.rs:121:18
    frame #38: 0x0000000001346071 hbbr`std::rt::lang_start::_$u7b$$u7b$closure$u7d$$u7d$::h7e0f538c62287b8c at rt.rs:166:18
    frame #39: 0x0000000001950014 hbbr`std::rt::lang_start_internal::h6f6837c266f742ab + 36
    frame #40: 0x000000000134604a hbbr`std::rt::lang_start::hecd4d6875430e800(main=(hbbr`hbbr::main::h8d9e882749eda667 at hbbr.rs:9), argc=1, argv=0x00007fffffffea40, sigpipe='\0') at rt.rs:165:17
    frame #41: 0x00000000013b3dde hbbr`main + 30
    frame #42: 0x000000000132044d hbbr`_start(ap=<unavailable>, cleanup=<unavailable>) at crt1_c.c:75:7
  thread #3, name = 'flexi_logger-fs-asy', stop reason = signal SIGSEGV
    frame #0: 0x00000000017b7101 hbbr`core::sync::atomic::atomic_store::hb8a3ec345f9caad9(dst=0x0000000802a02010, val=0, order=Release) at atomic.rs:0:15
    frame #1: 0x0000000001411b82 hbbr`core::sync::atomic::AtomicUsize::store::h0c647f07c0dbae87(self=0x0000000802a02010, val=0, order=Release) at atomic.rs:2154:26
    frame #2: 0x0000000001477a18 hbbr`crossbeam_channel::context::Context::reset::h1e789bb0c0b34ea5(self=0x00007fffdfffd628) at context.rs:84:9
    frame #3: 0x00000000014773cb hbbr`crossbeam_channel::context::Context::with::_$u7b$$u7b$closure$u7d$$u7d$::h958fae4be69c2240(cell=0x0000000802a00028) at context.rs:59:21
    frame #4: 0x000000000144b25d hbbr`std::thread::local::LocalKey$LT$T$GT$::try_with::h8d6fb68763a2f714(self=0x0000000001999028, f={closure_env#1}<crossbeam_channel::flavors::list::{impl#3}::recv::{closure_env#1}<alloc::vec::Vec<u8, alloc::alloc::Global>>, ()> @ 0x00007fffdfffd6c0) at local.rs:446:16
    frame #5: 0x00000000014769d2 hbbr`crossbeam_channel::context::Context::with::h8417bfbb5f0c7e49(f=<unavailable>) at context.rs:55:9
    frame #6: 0x000000000142fd0a hbbr`crossbeam_channel::flavors::list::Channel$LT$T$GT$::recv::h19c1abce34eaa57b(self=0x0000000802222200, deadline=Option<std::time::Instant> @ 0x00007fffdfffd7c8) at list.rs:469:13
    frame #7: 0x000000000142dcce hbbr`crossbeam_channel::channel::Receiver$LT$T$GT$::recv::h1695533d10413484(self=0x00007fffdfffdad0) at channel.rs:815:43
    frame #8: 0x000000000141ad40 hbbr`flexi_logger::writers::file_log_writer::threads::start_async_fs_writer::_$u7b$$u7b$closure$u7d$$u7d$::h4517aabdd0a0c010 at threads.rs:82:27
    frame #9: 0x000000000144835c hbbr`std::sys_common::backtrace::__rust_begin_short_backtrace::hcd64ff13f24bffdf(f=<unavailable>) at backtrace.rs:121:18
    frame #10: 0x000000000147f5ed hbbr`std::thread::Builder::spawn_unchecked_::_$u7b$$u7b$closure$u7d$$u7d$::_$u7b$$u7b$closure$u7d$$u7d$::h36a186ddad7e308e at mod.rs:558:17
    frame #11: 0x0000000001446821 hbbr`_$LT$core..panic..unwind_safe..AssertUnwindSafe$LT$F$GT$$u20$as$u20$core..ops..function..FnOnce$LT$$LP$$RP$$GT$$GT$::call_once::hbfdefefec9184e53(self=<unavailable>, _args=<unavailable>) at unwind_safe.rs:271:9
    frame #12: 0x000000000145d061 hbbr`std::panicking::try::do_call::h52e2564afc50beea(data="\U00000001") at panicking.rs:483:40
    frame #13: 0x0000000001460b0b hbbr`__rust_try + 27
    frame #14: 0x000000000145c830 hbbr`std::panicking::try::h5585845f6a4fde4d(f=<unavailable>) at panicking.rs:447:19
    frame #15: 0x000000000145c569 hbbr`std::panic::catch_unwind::hb6d6d0cb5d33a7ef(f=<unavailable>) at panic.rs:140:14
    frame #16: 0x000000000147ef7e hbbr`std::thread::Builder::spawn_unchecked_::_$u7b$$u7b$closure$u7d$$u7d$::hc0e2005cdf05ba21 at mod.rs:557:30
    frame #17: 0x000000000144c51f hbbr`core::ops::function::FnOnce::call_once$u7b$$u7b$vtable.shim$u7d$$u7d$::h69fa843360b84604((null)=0x0000000802219080, (null)=<unavailable>) at function.rs:250:5
    frame #18: 0x000000000193fc93 hbbr`std::sys::unix::thread::Thread::new::thread_start::h322067834044ed53 + 35
    frame #19: 0x0000000801a5783a libthr.so.3`___lldb_unnamed_symbol556 + 314
(lldb) exit

If I properly analyzed only this one directs to rustdesk-server sources:

    frame #35: 0x00000000013b331b hbbr`hbbr::main::h8d9e882749eda667 at hbbr.rs:10:19

I found there https://github.com/rustdesk/rustdesk-server/blob/master/src/hbbr.rs:

    let _logger = Logger::try_with_env_or_str("info")?
        .log_to_stdout()
        .format(opt_format)
        .write_mode(WriteMode::Async)
        .start()?;

I started changing the options through examples: https://docs.rs/flexi_logger/latest/flexi_logger/code_examples/index.html

Finally I have:

    let _logger = Logger::try_with_env_or_str("info")?
        .log_to_stdout()
        .format(opt_format)
        .write_mode(WriteMode::Direct)
        .start()?;

And the same in: https://github.com/rustdesk/rustdesk-server/blob/master/src/main.rs from line 11 (changed line 14).

Then I recompiled sources and voila. WORKS :) Works without screen under csh and starts on boot with @n-connect script.

I don't know if this change is ok genarally. Maybe better is to use screen?

I don't know how to change the code to compile with this change only on FreeBSD.

I hope somebody will read the above and will find a good solution.

I have:

root@gamma:~# cargo --version
cargo 1.68.0

When I compiled rustdesk-server I saw:

warning: the following packages contain code that will be rejected by a future version of Rust: nom v5.1.2

So I started to make modification i Cargo.toml and now I have (except clap all in the latest versions for today):

[dependencies]
hbb_common = { path = "libs/hbb_common" }
serde_derive = "1.0"
serde = "1.0"
serde_json = "1.0"
lazy_static = "1.4"
clap = "2"
rust-ini = "0.18"
minreq = { version = "2.7", features = ["punycode"] }
machine-uid = "0.3"
mac_address = "1.1"
whoami = "1.4"
base64 = "0.21"
axum = { version = "0.6", features = ["headers"] }
sqlx = { version = "0.6", features = [ "runtime-tokio-rustls", "sqlite", "macros", "chrono", "json" ] }
deadpool = "0.9"
async-trait = "0.1"
async-speed-limit = { git = "https://github.com/open-trade/async-speed-limit" }
uuid = { version = "1.3", features = ["v4"] }
bcrypt = "0.14"
chrono = "0.4"
jsonwebtoken = "8"
headers = "0.3"
once_cell = "1.17"
sodiumoxide = "0.2"
tokio-tungstenite = "0.18"
tungstenite = "0.18"
regex = "1.7"
tower-http = { version = "0.4", features = ["fs", "trace", "cors"] }
http = "0.2"
flexi_logger = { version = "0.25", features = ["async", "dont_minimize_extra_stacks"] }
ipnetwork = "0.20"
local-ip-address = "0.5"
dns-lookup = "1.0"
ping = "0.4"

Most of new libs does not require any changes to rustdesk-server sources, apart from the deadpool and base64 libraries. If somebody want to try the full patch is here: https://misiak.mini.net.pl/~marcinkk/rustdesk-server.diff The archive with patch and changed files: https://misiak.mini.net.pl/~marcinkk/rs-changed-sources.tar.gz

As can be seen above, the flexi_logger is with "dont_minimize_extra_stacks" - FreeBSD only?

I changed sources for compatibility with new version of base64 and deadpool libs based on the examples. I think base64 is ok, but changes in database.rs ... I don't know. It compiles without warnings and works ok on my FreeBSD 13.1 system.

rustdesk / rustdesk-server

Build and include FreeBSD releases #209