beeware
On macOS, `briefcase run` requires admin status
Describe the bug
briefcase run can fail for users with limited access. For instance, this macbook is remotely managed and limits administrative tasks by default.
❯ briefcase run --log
[helloworld] Building App...
Renaming stub binary... done
[helloworld] Ad-hoc signing app...
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 100.0% • 00:02
[helloworld] Built build/helloworld/macos/app/Hello World.app
[helloworld] Starting app...
===========================================================================
log: Must be admin to run 'stream' command
Steps to reproduce
Not specifically sure...but run briefcase run for a limited user on macOS.
Expected behavior
The app could run without log stream perhaps.
Screenshots
No response
Environment
- Operating System: Sequoia
- Python version: 3.12.7
- Software versions:
- Briefcase:
0.3.20.dev369+gf6b5d83f
- Briefcase:
Logs
briefcase.2024_12_15-11_13_36.run.log
Additional context
No response
Well... that's going to be a right pain. "Don't stream the logs" is going to be a really suboptimal solution, because you won't see any stdout/stderr output of the app.
Are you able to see the logs when you run in Xcode? It seems highly unlikely that macOS would prevent any non-admin user from being able to view logs. I wonder if a different predicate (something based on the PID perhaps?) would avoid triggering permission issues?
According to man log:
By default, the command assumes system-wide streaming. Specifying a process id with the --process option will narrow the results.
I wonder if this might also help with our chronic "Messages dropped during live streaming" problem on iOS and macOS.
Related:
- https://github.com/python/cpython/issues/130294
I wonder if this might also help with our chronic "Messages dropped during live streaming" problem on iOS and macOS.
That's an interesting thought - sounds like it would definitely worth investigating to see if PID-based filtering gets around the admin-user requirement.
The one other complication is that the current setup involves starting the log, then starting the app, which guarantees that you get all the logs. However, to filter logs based on PID, we'd need to start the app, then the logs, which would potentially leave a small window at the start of execution where a log wasn't available.
In the macOS case, the other option that might be worth pursuing is the --stdout and --stderr arguments to open. Those arguments allow streaming stdout and stderr to a file, which we could then stream. I haven't played with those options extensively, but if "Briefcase debug" mode disabled log redirection, that might provide an alternate way to display logs.
Those arguments allow streaming stdout and stderr to a file, which we could then stream.
A named pipe might be even easier, since there would be less to clean up.
the current setup involves starting the log, then starting the app, which guarantees that you get all the logs. However, to filter logs based on PID, we'd need to start the app, then the logs, which would potentially leave a small window at the start of execution where a log wasn't available
In the CPython Android testbed there's a workaround to make sure the PID exists long enough to be detected. But that only works because the Android log stream command has a mode that will give you both past and future logs from a given PID. I don't know if Apple has anything similar – if it doesn't, then the only option I can think of is to add a fixed delay at the start of every process, which would be unfortunate.
Does Xcode have similar problems with missing messages? If not, do we know how it achieves that?
I haven't noticed Xcode have issues with missing messages. However, it's not clear how it's managing piping output from processes. It seems reasonable that it's doing PID or named pipe output handling; but that detail isn't obvious from the logs Xcode provides. It wouldn't seem out of the question that it's using an undocumented internal API, with the log stream being the public, less featured interface.