Seems to me that since the script execute an admin command (in a folder with read write permission to Admin account). you must use "sudo". Even you asked authorisation "KeepRights". As I understand, System won't ask again the password, but you must use "sudo".

No sudo is necessary when executing scripts with AuthorizationMBS. In fact, if there IS as sudo then the script can't work - at all. The scripts hang because they get confused with the sudo. I have some other scripts with AuthorizationMBS and neither of them needs sudo.

Ah. Ok.
Perhaps, try with a simple test like in MBS documentation : changing permission (chmod) on a file in /Library/LaunchDaemons
https://www.monkeybreadsoftware.net/authorization-authorizationmbs-method.shtml#17. Is it working as expected ?

Changing the permissions shouldn't be needed either because the installer installs everything as root:

No, that's not I want to say. I suggested you try the process with a simple command (chmod or other), not with the server script. This will allow to say if the issue raised from the authorisation, the command or from the script.
Thus I would try
1) with a simple command (without the script, but from xoxo)
2) with this simple command in a script, launching the script from the Xojo shell

Thanks for trying to help. But I haven't a clue what you mean. I have a similar script for installing the license which works fine.

The ps command doesn't work on Ventura so I'm looking for an alternative.

Mmmh. Perhaps Christian can help finding why there are difference between shell command from Xojo (using MBS) and command via Terminal...
Does your license install process need sudo too ?

If the Valentina guys don't have any idea then I'll ask on the Xojo forum tomorrow. If you execute a shell script with AuthorisationMBS then the script MUST NOT contain the sudo. Or the script hangs.

The license installation script is a super simple ditto:

'write shell script to temp file

dim TempFile as FolderItem = FolderItem.TemporaryFile

if TempFile = Nil then Return

dim TempBinary as BinaryStream = BinaryStream.Open(TempFile, True)

if TempBinary = Nil then Return

TempBinary.Write("#!/bin/sh" + EndOfLine.UNIX + "/usr/bin/ditto " + LicenseFile.ShellPath + " " + ServerFolder.ShellPath)

TempBinary.Close



'set permissions for shell script

dim theShell as new Shell

theShell.Execute("chmod 777 " + TempFile.ShellPath)

if theShell.ExitCode <> 0 then

  Globals.theErrorLog.logitem(currentMethodName + " shell exit code: " + str(theShell.ExitCode))

  globals.theErrorLog.DialogErrorProceed(kErrorNoInstallation)

  Return

end if



'now execute the Shell script with Authorization

if theAuthorisation = nil then 

  theAuthorisation = new AuthorizationMBS

  if not theAuthorisation.SimpleNewAuthorization then Return

end if



dim s(-1) as String

theAuthorisation.Execute(TempFile.UnixpathMBS, s)

if theAuthorisation.LastError = 0 then

  dim theResult as Integer = theAuthorisation.Wait

  if theResult = 0 then

   'snip: error handling

  

end if

Are you there?

The scripts actually did something. They made VServer crash hard:


Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 libsystem_kernel.dylib 0x192def204 __pthread_kill + 8
1 libsystem_pthread.dylib 0x192e25cec pthread_kill + 288
2 libsystem_c.dylib 0x192d5f354 __abort + 128
3 libsystem_c.dylib 0x192d5f2d4 abort + 192
4 libc++abi.dylib 0x192ddfb18 abort_message + 132
5 libc++abi.dylib 0x192dcfa0c demangling_terminate_handler() + 336
6 libobjc.A.dylib 0x192ad7774 _objc_terminate() + 160
7 libc++abi.dylib 0x192ddeeb4 std::__terminate(void (*)()) + 20
8 libc++abi.dylib 0x192de1c2c __cxxabiv1::failed_throw(__cxxabiv1::__cxa_exception*) + 36
9 libc++abi.dylib 0x192de1bd8 __cxa_throw + 140
10 libvshared_mt_fat_release_x64.dylib 0x1054b8ca4 fbl::File::ThrowFileException(unsigned int, unsigned short const*) const + 84
11 libvshared_mt_fat_release_x64.dylib 0x1054c8920 fbl::File_Mac_Posix:oCreate() + 112
12 libvshared_mt_fat_release_x64.dylib 0x1054b7bc8 fbl::File::Create() + 172
13 libvshared_mt_fat_release_x64.dylib 0x1054b3290 fbl::CreateTextFile(fbl::smart_ptr<fbl::I_Location> + 100
14 libvserver_fat_release_x64.dylib 0x1059c82f4 V_Server_Base::InitLog() + 328
15 libvserver_fat_release_x64.dylib 0x1059c7e38 V_Server_Base::Start() + 44
16 libvserver_fat_release_x64.dylib 0x1059da598 V_TP_Reactor_Server::Start() + 152
17 libvserver_fat_release_x64.dylib 0x105a2e4bc VSRV_Server::Start() + 40
18 vserver_x64 0x1049d3ed4 main + 124
19 dyld 0x192affe50 start + 2544


What file is VServer trying to create? The log file???

Yes, it was attempt to create vServer log. I’ll try to reproduce it.

With the help of Thomas Tempelmann I was able to solve the problem. I added some logging to the start script:

touch /tmp/a1
launchctl bootstrap system /Library/LaunchDaemons/com.paradigmasoft.vserver_x64.plist &>/tmp/a1

This gave me an error message:

Warning: Expecting a LaunchAgents path since the command was ran as user. Got LaunchDaemons instead.
`launchctl bootstrap` is a recommended alternative.
/Library/LaunchDaemons/com.paradigmasoft.vserver_x64.plist: service already loaded
Load failed: 37: Operation already in progress

Then I used the new launchctl syntax (since Yosemite!!!) for loading and unloading:

launchctl bootstrap system /Library/LaunchDaemons/com.paradigmasoft.vserver_x64.plist
launchctl bootout system /Library/LaunchDaemons/com.paradigmasoft.vserver_x64.plist

I'll be doing some bug reports/feature requests.

Hope you are doing as well as possible!

Warning: Expecting a LaunchAgents path since the command was ran as user

Is it not an admin user who must run the LaunchDaemon ? Or have I misunderstood...

Is using "bootstrap" a new requirement for the new OS ? I don't use it with Mojave, Catalina or BigSur

It looks like AuthorisationMBS which should be sudo in fact it isn't quite. This was surprising to me, too.

For Yosemite launchctl was rewritten. But everyone just continues to use the old syntax. See https://joelsenders.wordpress.com/2019/03/14/dear-launchctl-were-all-using-you-wrong/ .