Forever "Working. Please wait..." when setting custom props about magiskhidepropsconf HOT 16 CLOSED

I can't reproduce your issue on my end. I'm seeing some small hints in your log at other issues though. Could you try using the configuration file and change the CONFPROPS variable to:
CONFPROPS="persist.camera.HAL3.enabled=1"

Place the file in the root of your internal storage (/sdcard) and reboot.

Once you're back up and running, please collect and post the logs again.

from magiskhidepropsconf.

Hi! I did that (I copied the configuration file from the ZIP), and changed as asked.
After the two reboots (one manual and one from late_start), the prop is correctly set.
I don't know if this matters but I've reinstalled the module for checking that.
Attached are the logs. Thanks!

propslogs.tar.gz

from magiskhidepropsconf.

I'm not so sure about that... According to your logs you used the CONFDELPROPS variable rather than CONFPROPS. That means you set the module to to delete the prop "persist.camera.HAL3.enabled=1", which won't work since there's no such prop...

But, you are correct that the prop is properly set now. It just doesn't seem like it happened through the module. Did you at any point use any other way of setting this prop?

The thing about persist props is that they're persistent, meaning they'll only need to be set once and then they'll keep that value (until a new one is set).

Anyway... From what I can tell there's some kind of incompatibility with your device that is practically impossible for me to troubleshoot. It would be interesting to know if setting a prop on your device is possible via the configuration file though, but I get if you're unwilling to keep testing since things now seem to be as you want.

from magiskhidepropsconf.

I'm willing to keep testing as that's not the only prop I'd want to set (even if I could make a module with system.prop, it's lots easier using your module for that).

I looked a couple times at the config file and I'm sure of setting CONFPROPS instead of CONFDELPROPS, but yeah, after looking at the logs it shows that the property is being deleted... What I haven't checked is that, after the first try (opening this issue), the property was set, so maybe the second time it did nothing.
But it's somewhat interesting because last time I wanted to set a ro.config.tima property, the same happened (forever working). Seems like problem arises when using "special" properties (ro. and persist.).

Will try setting a random property and see if it works.
Thanks in advance for any follow up!

from magiskhidepropsconf.

Tried setting my.custom.prop=1 via props command, same thing happened.
Tried setting using config file, prop is correctly set (props even shows (active) after).

propslogs.tar.gz

from magiskhidepropsconf.

Thank you for testing.

There's something about your environment while booted that is causing issues. Everything works fine during boot, but then Magisk is running the scripts entirely in its own environment.

I'm gonna look a little closer and might come back to you with more things to test soon.

from magiskhidepropsconf.

@bryanjhv Another test if you feel up to it. Replace /data/adb/modules/MagiskHidePropsConf/common/util_functions.sh with the attached file (don't forget to rename it to .sh).

Things will look really weird unless you run the props command with the -nc option (no colour), but it'll still function as normal.

util_functions.txt

from magiskhidepropsconf.

Hi!
Tried that and no luck, props command still hangs...
I had, as you said, to run it without colors, otherwise the ANSI escape sequences were shown.
I'll try to test some other things because as you said, it might be a problem with this device, as this is a Samsung...

Thanks for your help, really appreciate it. If you have any feedback or some other things to test, I'm glad to do it.
But I understand if you don't have time/will to keep looking at logs, your module is so useful anyway (I'd stick to using config file).

I think it's ok to close the issue as it seems device-specific and might have nothing to do with your module.

propslogs.tar.gz

from magiskhidepropsconf.

Yeah, it's something about your device... If you hadn't also tried ADB I would have guessed it might be because of Termux, but I just don't know.

Your log does show that some quirks got fixed (the date function wasn't working as expected originally, but does now). In the util_functions file you tested I simply aliased all commands to use the internal Magisk Busybox (just like during boot, where things are working). I'm gonna do that in the next update, to make sure I know exactly what applets are used... To bad that didn't seem to be your issue.

If you do figure something out I'll be happy to hear it.

from magiskhidepropsconf.

Yes, I also tried using ADB and can confirm the same happens. I guess it's not something to do with Termux because the script they put on their repositories just calls MagiskSU as usual the way ADB does and I didn't really modify the environment or something.

Planning to do some set -x calls and test with ADB so I can get to something, maybe even look at the props code to see what's happening; thinking about some permissions issue I got with Magisk or some of the well-known Samsung kirks.

from magiskhidepropsconf.

Hi! I found and fixed the issue (at least for me):

I don't know if it's a bug with the code, the sh or sed implementation I have, but changing this:

To this:

		echo $(grep $2 $1 | sed "s|.*${2}||" | sed 's|\"||g')    # notice the echo

From code I've read before, there's always an echo for that or sed will think I don't know what and just hang (that was the reason it wasn't even passing reset_custprop).

from magiskhidepropsconf.

Awesome! I'll take care of it in the next update.

from magiskhidepropsconf.

Ha! Now that you've mentioned it, it makes perfect sense... I was just so blind to my own flaws that I didn't see why it would be failing there. Especially since it was working during boot and at the beginning of the props script when checking the prints list version.

Face, meet palm.

Again, thank you for bringing a clear set of eyes.

from magiskhidepropsconf.

Thank you too for helping me out to figure what was happening.
I got some insight on where to look for that and where to start.

Side note:
Do you have any documentation on where does $INSTFN get set?
I've found nothing in your code or Magisk one. Guess it's set at recovery?

from magiskhidepropsconf.

In customize.sh, which is in turn called by the module installer script that replaces the dummy update-binary when the module is downloaded through the Magisk Manager.

from magiskhidepropsconf.

Completely missed that! Seems like I'll have to review my grep -R skills.

Thanks for pointing that out!

from magiskhidepropsconf.