| 1 |
OK. |
| 2 |
|
| 3 |
|
| 4 |
However, my real confusion or worry in fact is not the compilation of gcc, but about the logind. This obvious happens not only in compilation of gcc. Whenever there are programs consuming almost all the memory, the logind will be disconnected and not come back again. Why is the logind so fragile? Why cannot it be brought up again after the memeory become available again? Or why should the systemd depend on such a faulty logind in order to do important jobs like shutdown? Don't you think it is a serious weakness of the system? |
| 5 |
|
| 6 |
|
| 7 |
|
| 8 |
|
| 9 |
|
| 10 |
|
| 11 |
|
| 12 |
|
| 13 |
|
| 14 |
|
| 15 |
|
| 16 |
|
| 17 |
|
| 18 |
|
| 19 |
At 2022-09-17 19:43:54, "Michael" <confabulate@××××××××.com> wrote: |
| 20 |
>On Saturday, 17 September 2022 12:11:56 BST tastytea wrote: |
| 21 |
>> On 2022-09-17 17:37+0800 johnstrass <johnstrass@×××.com> wrote: |
| 22 |
>> > At 2022-09-17 14:15:51, "Walter Dnes" <waltdnes@××××××××.org> wrote: |
| 23 |
>> > >On Sat, Sep 17, 2022 at 10:40:53AM +0800, johnstrass wrote |
| 24 |
>> > > |
| 25 |
>> > >> Compiling gcc uses alot of memory, sometimes only less then 10MB |
| 26 |
>> > >> left free ( I am doing this on a small yeeloong netbook with only |
| 27 |
>> > >> 1GB memory). |
| 28 |
>> > >> |
| 29 |
>> > > Ouch, I'm surprised it compiles at all. The Gentoo install |
| 30 |
>> > > |
| 31 |
>> > > handbook |
| 32 |
>> > > |
| 33 |
>> > >https://wiki.gentoo.org/wiki/Handbook:AMD64/Full/Installation#MAKEOPTS |
| 34 |
>> > >has a dire warning about memory usage... |
| 35 |
>> > |
| 36 |
>> > Yep, I've got the gcc-12.2.0 natively compiled on this netbook using |
| 37 |
>> > gcc-11.3.0, after 5+ days + a crash + 5more days. |
| 38 |
>> > |
| 39 |
>> > I set up a large swap and I've also set up the ccache which may |
| 40 |
>> > speedup a little after the crash. |
| 41 |
>> > |
| 42 |
>> > >> Warning |
| 43 |
>> > >> |
| 44 |
>> > >> Using a large number of jobs can significantly impact memory |
| 45 |
>> > >> consumption. A good recommendation is to have at least 2 GiB of RAM |
| 46 |
>> > >> for every job specified (so, e.g. -j6 requires at least 12 GiB). To |
| 47 |
>> > >> avoid running out of memory, lower the number of jobs to fit the |
| 48 |
>> > >> available memory. |
| 49 |
>> > >> |
| 50 |
>> > > You simply don't have enough ram. You might reduce the pain and |
| 51 |
>> > > |
| 52 |
>> > > the |
| 53 |
>> > > |
| 54 |
>> > >swapping by trying something like the following in make.conf |
| 55 |
>> > >(assuming you haven't already done it) |
| 56 |
>> > > |
| 57 |
>> > > |
| 58 |
>> > >MAKEOPTS="-j1" |
| 59 |
>> > |
| 60 |
>> > I will try next time. Thanks. |
| 61 |
>> > |
| 62 |
>> > >> If this happens, what is the best way to reboot or shutdown? |
| 63 |
>> > >> |
| 64 |
>> > > Try ye olde {CTRL}{ALT}{DEL} |
| 65 |
>> > |
| 66 |
>> > I remember that I did try "CTRL+ALT+DEL" in such situations before, |
| 67 |
>> > and most times it did not work but for one or two times it worked |
| 68 |
>> > occasionally. I will try it again next time. |
| 69 |
>> |
| 70 |
>> You could also use “Magic SysRQ”s[1] to reboot the system forcefully |
| 71 |
>> but somewhat controlled. The traditional sequence is: |
| 72 |
>> r e i s u b (raising elephants is so utterly boring)[2] |
| 73 |
>> |
| 74 |
>> [1] <https://wiki.gentoo.org/wiki/Magic_SysRQ> |
| 75 |
>> [2] |
| 76 |
>> <https://www.kernel.org/doc/html/latest/admin-guide/sysrq.html#what-are-the |
| 77 |
>> -command-keys> |
| 78 |
> |
| 79 |
>Using MAKEOPTS="-j1" will help and a bigger swap will stop it crashing with |
| 80 |
>OOM, but a more sensible solution is to compile and build big packages like |
| 81 |
>gcc on a faster PC as binaries, then transfer and emerge on the slow PC with |
| 82 |
>--usepkg, or --usepkgonly options. More info: |
| 83 |
> |
| 84 |
>https://wiki.gentoo.org/wiki/Binary_package_guide |
Archives