question on sharing of /Downloads dir between chroots

[tedm]

my precise kde chroot has been running stable with the power saving modules turned off for about 24+ hours, is running cpu maxing programs very stable.

A question I have is that if I put an executable from the kde precise root into the downloads folder, then to chromeos, and run the program in a crosh window - a 2nd one, from the one the crhoot was started in, and is giving console messages, then stdout from the printf statements go to the first crosh window, not the crosh window that started the program from the kde chroot (started with crosh, shell, sudo ~/Downloads/myprogram)

Is there something I should be writing in my code so the stdout, outputs in the shell the program was initiated in?

[dnschneid]

I'm not sure I'm following entirely.

You compiled a program and saved it in the shared ~/Downloads folder, then tried to run it outside of the chroot?

First of all, when compiling something inside the chroot and running it from outside, you risk userspace binary incompatibilities stopping your program from running (or worse, it could be running but incorrectly). I think with precise it mostly works, and with quantal it sometimes works, but you're pretty much just depending on luck there. Not a great thing to do unless you really need it run outside of the chroot for some reason. You can enter the chroot and run the program directly by using something like sudo enter-chroot exec /path/to/myprogram; that will run it as the unprivileged user. If you want to run it as root still, you can add -u root before the exec.

Secondly, Chromium OS shouldn't even be letting you run the executable from the ~/Downloads directory outside of the chroot, as it's marked as noexec (the chroot's version is fine). Are you sure it's not just failing to launch, and you're looking at old output from within the chroot?

[tedm]

Yes, I realize it shouldn't run. It was just a test. It does give an error about protected space, but the program is so simple (nested counting for loops) that it doesn't allocate memory, it just prints incremental numbers. It was an experiment, but also the program that ran in the crhoot, that I could verify was running as I slept, and woke up and checked it.

On Fri, Mar 29, 2013 at 3:39 PM, David Schneider notifications@github.comwrote:

I'm not sure I'm following entirely.

You compiled a program and saved it in the shared ~/Downloads folder, then tried to run it outside of the chroot?

First of all, when compiling something inside the chroot and running it from outside, you risk userspace binary incompatibilities stopping your program from running (or worse, it could be running but incorrectly). I think with precise it mostly works, and with quantal it sometimes works, but you're pretty much just depending on luck there. Not a great thing to do unless you really need it run outside of the chroot for some reason. You can enter the chroot and run the program directly by using something like sudo enter-chroot exec /path/to/myprogram; that will run it as the unprivileged user. If you want to run it as root still, you can add -u root before the exec.

Secondly, Chromium OS shouldn't even be letting you run the executable from the ~/Downloads directory outside of the chroot, as it's marked as noexec (the chroot's version is fine). Are you sure it's not just failing to launch, and you're looking at old output from within the chroot?

— Reply to this email directly or view it on GitHubhttps://github.com/dnschneid/crouton/issues/87#issuecomment-15664018 .

[dnschneid]

Regardless of what the program actually does, it shouldn't run without remounting the Chromium OS ~/Downloads with exec. I'm still not clear on what you're seeing, but it's probably safe to say your experiment was conclusive one way or another.

[tedm]

If you want the ~5 lines of code, and exact steps to reproduce, I can paste it all here. I'm not sure if it's a bug (but saw you closed it), or a feature request, in that it would be cool it I could compile in the dev chroot, and run (and run correctly) in chromos? Would have been convenient for netflix, right? ;)

On Fri, Mar 29, 2013 at 3:56 PM, David Schneider notifications@github.comwrote:

Regardless of what the program actually does, it shouldn't run without remounting the Chromium OS ~/Downloads with exec. I'm still not clear on what you're seeing, but it's probably safe to say your experiment was conclusive one way or another.

— Reply to this email directly or view it on GitHubhttps://github.com/dnschneid/crouton/issues/87#issuecomment-15664549 .

[dnschneid]

You can already compile for Chromium OS from within crouton--you create a Chromium OS build chroot from within crouton just like you would from any development system. That's the only correct way to reliably avoid binary incompatibility.

[tedm]

Yes, I've been planning to setup that environment. There's a variation of this issue that might be even odder, here are the steps:

1. compile this code with gcc testprogram.c -o testprogram in the kde precise target in your home directory:

[code]

include

int main(void) { unsigned long long i,j;

for (i=1;i<1000000;i++) { printf("number %llu\n",i); for (j=1;j<100000000;j++) { } } return(0); } [/code]

1. exit the kde precise chroot
2. from chromeos, startkde in a crosh shell
3. without any terminals open, click on the testprog executable (with dolphin or whatever, to open the program)
4. ctrl-shift-alt-f2 back to chromeos
5. note that the output from testprog is running in a crosh terminal (but likely with mixed up numbers, e.g. not running right), intermixed with random console messages.

On Fri, Mar 29, 2013 at 4:03 PM, David Schneider notifications@github.comwrote:

You can already compile for Chromium OS from within crouton--you create a Chromium OS build chroothttps://sites.google.com/a/chromium.org/dev/chromium-os/developer-guidefrom within crouton just like you would from any development system. That's the only correct way to reliably avoid binary incompatibility.

— Reply to this email directly or view it on GitHubhttps://github.com/dnschneid/crouton/issues/87#issuecomment-15664792 .

[dnschneid]

That's normal. If you run a program that outputs to stdout or stderr, but you don't launch it from a terminal, it will output to the terminal that you launched the X session from.

[tedm]

OK, thanks. I'm new to this chroot stuff. I would have thought it would give some error in kde/dolphin saying it couldn't associate anything with it, or better yet, open up a shell and run in on the kde desktop.