-
Notifications
You must be signed in to change notification settings - Fork 627
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[DOC] make systemd-run example more reliable #2048
base: next
Are you sure you want to change the base?
Changes from all commits
aa9ebc7
d697450
0fecb6a
91dd739
51eaeda
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -72,16 +72,15 @@ void cmd_set_arguments(int argc, char **argv) { | |
stored_argv = argv; | ||
} | ||
|
||
int helper_parse_setup(char *string, char ***output, int *length, ...) { | ||
static int helper_parse_setup_v(char *string, char ***output, int *length, | ||
va_list ap) { | ||
GError *error = NULL; | ||
GHashTable *h; | ||
h = g_hash_table_new(g_str_hash, g_str_equal); | ||
// By default, we insert terminal and ssh-client | ||
g_hash_table_insert(h, "{terminal}", config.terminal_emulator); | ||
g_hash_table_insert(h, "{ssh-client}", config.ssh_client); | ||
// Add list from variable arguments. | ||
va_list ap; | ||
va_start(ap, length); | ||
while (1) { | ||
char *key = va_arg(ap, char *); | ||
if (key == (char *)0) { | ||
|
@@ -93,7 +92,6 @@ int helper_parse_setup(char *string, char ***output, int *length, ...) { | |
} | ||
g_hash_table_insert(h, key, value); | ||
} | ||
va_end(ap); | ||
|
||
char *res = helper_string_replace_if_exists_v(string, h); | ||
// Destroy key-value storage. | ||
|
@@ -115,6 +113,13 @@ int helper_parse_setup(char *string, char ***output, int *length, ...) { | |
} | ||
return FALSE; | ||
} | ||
int helper_parse_setup(char *string, char ***output, int *length, ...) { | ||
va_list ap; | ||
va_start(ap, length); | ||
int retv = helper_parse_setup_v(string, output, length, ap); | ||
va_end(ap); | ||
return retv; | ||
} | ||
|
||
void helper_tokenize_free(rofi_int_matcher **tokens) { | ||
for (size_t i = 0; tokens && tokens[i]; i++) { | ||
|
@@ -1027,15 +1032,21 @@ gboolean helper_execute(const char *wd, char **args, const char *error_precmd, | |
gboolean helper_execute_command(const char *wd, const char *cmd, | ||
gboolean run_in_term, | ||
RofiHelperExecuteContext *context) { | ||
return helper_execute_command_full(wd, cmd, run_in_term, context, "{cmd}", | ||
cmd, (char *)0); | ||
} | ||
|
||
static gboolean helper_execute_command_full_v(const char *wd, const char *cmd, | ||
gboolean run_in_term, | ||
RofiHelperExecuteContext *context, | ||
va_list ap) { | ||
char **args = NULL; | ||
int argc = 0; | ||
|
||
if (run_in_term) { | ||
helper_parse_setup(config.run_shell_command, &args, &argc, "{cmd}", cmd, | ||
(char *)0); | ||
helper_parse_setup_v(config.run_shell_command, &args, &argc, ap); | ||
} else { | ||
helper_parse_setup(config.run_command, &args, &argc, "{cmd}", cmd, | ||
(char *)0); | ||
helper_parse_setup_v(config.run_command, &args, &argc, ap); | ||
Comment on lines
-1034
to
+1049
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I just noticed this: aren't these flipped now? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. run_in terminal calls the 'run_shell_command'.. I think this is ok? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I don't have a clue how this code actually works, I only noticed that the |
||
} | ||
|
||
if (args == NULL) { | ||
|
@@ -1063,10 +1074,19 @@ gboolean helper_execute_command(const char *wd, const char *cmd, | |
|
||
return helper_execute(wd, args, "", cmd, context); | ||
} | ||
gboolean helper_execute_command_full(const char *wd, const char *cmd, | ||
gboolean run_in_term, | ||
RofiHelperExecuteContext *context, ...) { | ||
va_list ap; | ||
va_start(ap, context); | ||
gboolean retv = | ||
helper_execute_command_full_v(wd, cmd, run_in_term, context, ap); | ||
va_end(ap); | ||
return retv; | ||
} | ||
|
||
char *helper_get_theme_path(const char *file, const char **ext, | ||
const char *parent_file) { | ||
|
||
char *filename = rofi_expand_path(file); | ||
g_debug("Opening theme, testing: %s\n", filename); | ||
if (g_path_is_absolute(filename)) { | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
While it's nice to mark this as optional, that doesn't actually help anyone because you can only have one or the other but both drun and run could be used.
What we actually need is some sort of identifier that is unit-name-safe, represents what is being ran decently well and works with both drun and run.
For desktop applications, I see the desktop_id fulfilling that role. Though I'd prefer the
.desktop
suffix be stripped.For commands, I see the (escaped) executable name as the best candidate. Of course it'd "break" (as in: not represent what is being ran) if you ran
sh -c ...
or something but at that point you're explicitly doing that.Perhaps it'd be best to do that within rofi and provide an abstract
execution_id
or something that works like I described.Perhaps it'd be even better if we had run-as-system service functionality built right into rofi?
Executing
systemd-run
like this in-run-command
really isn't very robust as I've discovered with scrcpy, so perhaps "native" handling would be better.I'm really not sure how to proceed with this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't know.. I never use systemd-run. What does 'run-as-system' service entail? do you have a link to some documentation?
(we did add the DBusActivatable to latest rofi).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It means that any app launched is started as an ad-hoc systemd unit. For example the firefox I'm typing this in runs as the
app-rofi-firefox-24354.service
user unit.What this means in practice is that the initial process aswell as every process ever spawned it will be run in a cgroup that is separate from all other apps and you can apply any cgroup-based policy to it if you like.
This is most useful for stopping units (e.g. early OOM) but you could in theory do anything cgroups with this.
It also brings with it all of systemd's accounting and centralised log collection. See e.g. this example output:
I can see that the "firefox app" I launched currently uses 3.4GiB and has 833M in swap across all of its processes. I can also see all the processes Firefox has spawned. I can also see this app launch instance's logs in isolation.
Theoretically I could set e.g. memory or swap limits here though I'm not currently doing that.
Setting a memory limit without running firefox in its own cgroup would be very hard indeed and even finding out how much memory it's using usually isn't trivial with such multi-process applications. cgroups make everything simpler here.
AFAIK the big DEs' launchers also run every app launched within an ad hoc systemd unit but I don't use those, so I can't tell you how it works there.
There isn't really documentation on this other than standard systemd (user) service/unit docs and cgroup docs. There isn't really much to it other than simply using these systems.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I know what it does, but not how to do this from the rofi? Is there a dbus API I can call to launch the service?