The final debugging process (IPhyton5.0 seems to be responsible) is
described in sage-devel group
El sábado, 4 de febrero de 2017, 23:07:43 (UTC+1), Enrique Artal escribió:
>
> I was wrong, but now I am quite sure that the issue seems to appear in
> sage-7.4.beta0.
>
> El miércoles, 1 de febrero
I was wrong, but now I am quite sure that the issue seems to appear in
sage-7.4.beta0.
El miércoles, 1 de febrero de 2017, 23:27:35 (UTC+1), Enrique Artal
escribió:
>
> If I am not wrong the problem is created in sage-7.3.beta3. I can try with
> the different patches beta2->beta3. Can anyone gu
If I am not wrong the problem is created in sage-7.3.beta3. I can try with
the different patches beta2->beta3. Can anyone guess a good order to do
that?
El sábado, 14 de enero de 2017, 19:18:32 (UTC+1), Enrique Artal escribió:
>
> I have installed 7.3, 7.4 and 7.5 and we use several instances of
I have installed 7.3, 7.4 and 7.5 and we use several instances of sagenb
(it is for teaching and we use different addresses for different studies).
With 7.3, if a user reaches the limit of CPU time, his worksheet stops and
all the data in memory is lost, but quitting and opening the worksheet
a
Oh, right, this certainly has nothing to do with sagenb, what is not stopped is
sage worker that does the computation itself, right?
Could it be that you updated your OS in the meantime, and if you roll back to
sage 7.3 you would still see the same behaviour?
On sage's side it might be ipython
sagenb
El viernes, 13 de enero de 2017, 19:34:15 (UTC+1), Dima Pasechnik escribió:
>
>
>
> On Friday, January 13, 2017 at 5:30:04 PM UTC, Enrique Artal wrote:
>>
>> Putting limits in /etc/security/limits.conf (or in files in limits.d)
>> works right up to Sage 7.3. Namely, if a user performs a st
On Friday, January 13, 2017 at 5:30:04 PM UTC, Enrique Artal wrote:
>
> Putting limits in /etc/security/limits.conf (or in files in limits.d)
> works right up to Sage 7.3. Namely, if a user performs a strong computation
> (memory or CPU time), the system stops the computation when the limit is
Putting limits in /etc/security/limits.conf (or in files in limits.d) works
right up to Sage 7.3. Namely, if a user performs a strong computation
(memory or CPU time), the system stops the computation when the limit is
reached; usually one needs to quit the worksheet, but it is possible to
reus
It seems to work now with the ulimits for the server_pool users. If they
become too strict, we (maybe more precisely MIguel Marco) will try the
worker user approach. We will let know. Thanks for the help!
El domingo, 27 de noviembre de 2016, 21:23:33 (UTC+1), Nils Bruin escribió:
>
> On Sunday,
On Sunday, November 27, 2016 at 3:04:48 AM UTC-8, Enrique Artal wrote:
>
> Thanks, As you say, it would be better something more direct, but your
> approach is a strong improvement for my needs.
> By the way, I changed in our experimental notebook 7.4 -> 7.3 and the
> limits work: they stop the
In our setup some 5 years ago (we did a lab-based course for 200
undergraduates using Sage), if I recall right,
we used one user for the notebook server, and a different user, "worker",
to run computations; there were various ulimits on the
latter account (one sometimes forgotten is a limit on th
On Sun, 27 Nov 2016, Jeroen Demeyer wrote:
In general it is not easy to limit resource usage in Linux.
It's not easy, that's true. But that's independent of the fact that
ulimit within SageNB simply doesn't work due to some SageNB bug.
Yes, bugs are one thing. But the other is limiting reso
On 2016-11-27 14:10, Jori Mäntysalo wrote:
In general it is not easy to limit resource usage in Linux.
It's not easy, that's true. But that's independent of the fact that
ulimit within SageNB simply doesn't work due to some SageNB bug. I have
known about this bug for years but never bothered
On Sun, 27 Nov 2016, Enrique Artal wrote:
Thanks, As you say, it would be better something more direct, but your
approach is a strong improvement for my needs. By the way, I changed in our
experimental notebook 7.4 -> 7.3 and the limits work: they stop the process
and the notebook is still runni
Thanks, As you say, it would be better something more direct, but your
approach is a strong improvement for my needs.
By the way, I changed in our experimental notebook 7.4 -> 7.3 and the
limits work: they stop the process and the notebook is still running.
Enrique.
El domingo, 27 de noviembre
On Sat, 26 Nov 2016, Enrique Artal wrote:
By the way, using server_pool, is there a way to know which user of the
notebook is using a user of the server_pool?
AFAIK not really. I can list files in /tmp and run fuser for them, i.e.
fuser /tmp/*
and see, for example
/tmp/tmpwIR2_j: 758
By the way, using server_pool, is there a way to know which user of the
notebook is using a user of the server_pool?
El sábado, 26 de noviembre de 2016, 11:50:12 (UTC+1), Enrique Artal
escribió:
>
> I forgot to mention we use server_pool (there is one master-server and the
> ssh connections go
I forgot to mention we use server_pool (there is one master-server and the
ssh connections go to accounts in both the master-server and the
secondary-server). All the users have unlimited ulimit, we put the ulimit
as an option for the notebook.
For one notebook we put limits on the users, the pr
On Friday, November 25, 2016 at 2:24:49 PM UTC-8, Enrique Artal wrote:
>
> In my University, most math labs are done using Sagemath; for this purpose
> we have two PC's with sagenb service to which students access remotely. In
> general, it works smoothly; three classrooms with 20 students each,
19 matches
Mail list logo
