[systemd-devel] systemd-run: why is output buffered now?

[Reindl Harald]

Am 01.04.2016 um 21:40 schrieb Lennart Poettering:
> On Sun, 20.03.16 14:22, Reindl Harald (h.reindl at thelounge.net) wrote:
>
>> please take a look at https://bugzilla.redhat.com/show_bug.cgi?id=1319475 -
>> this is a unlucky behavior change, not only for usability but for scripts
>> with heavy output it's also a memory usage problem
>
> Are you sure it's not PHP that buffers things in this case?

100% sure because the whole PHP stack is from own packages and the only 
change was upgrade from Fedora 22 to Fedora 23 while nothing else 
changed in the way the spamassasin-learner works

also that script was in use long before wrapped it with systemd-run and 
behaved in a ssh-session as before until the upgrade

in fact when i run the script directly without systemd-run (tested 20 
seconds ago) the first output starts instantaneously
________________________________

[root at mail-gw:~]$ cat /usr/local/bin/spamfilter-fetch-samples
#!/usr/bin/dash
/usr/bin/systemd-run -t --service-type=oneshot --quiet --nice=19 
--unit=spamfilter-fetch-samples --description=spamfilter-fetch-samples 
/usr/bin/php -d 
open_basedir="/tmp:/scripts:/usr/local:/var/lib/spamass-milter/training" 
/usr/local/bin/workers/spamfilter-fetch-samples.php
________________________________

[root at mail-gw:~]$ /usr/bin/php -d 
open_basedir="/tmp:/scripts:/usr/local:/var/lib/spamass-milter/training" 
/usr/local/bin/workers/spamfilter-fetch-samples.php
SPAM-IGNORE: BAYES_99 - 
/tmp/2016-04-02-03-19-40-5f08268e0b94b6c2b0a281466ad26a61.eml
SPAM-TRAIN:  BAYES_80 - 
/tmp/2016-04-02-03-19-40-7e4342f0d72e0d012448505fff9035e6.eml
SPAM-IGNORE: BAYES_99 - 
/tmp/2016-04-02-03-19-40-962c626c87023256f62e621f050618b1.eml
SPAM-IGNORE: BAYES_99 - 
/tmp/2016-04-02-03-19-41-8e5f75daf73a465e7637f806b472fe88.eml

> If you use systemd-run "-t" we allocate a pty and copy each byte we
> get on it directly onto the invoking terminal. There's no buffering
> applied on our side really, and everything is fully async.

the strict pty allocating instead stdout is also questionable because 
you can't use systemd-run as cronjob to just use the namespacing and get 
cron-mails as usual in case there is some output

> It would be good if you could add a "sleep 60" to your PHP
> script. Then invoke your systemd-run command line with "strace
> -f". That should show you what systemd-run does while the PHP script
> is running, and how the data flows. If it does exactly nothing during
> those 60s and you see no data flowing at all then it's PHP that's not
> sending us the data. However if you see data flowing into systemd-run
> with strace, but not out of it, then it would be a bug in systemd-run












-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20160402/524b7660/attachment-0001.sig>