| ogra | now the million dollar question is ... what happens if /run runs out of space due to massive logging ? | 00:00 |
|---|---|---|
| ogra | (since it is mounted with size= i assume it wouldnt grow dynamically or anything= | 00:00 |
| ogra | am i missing any piece of the puzzle here or could excessive logging actually kill a system | 00:01 |
| ogra | (due to the fact that other processes couldnt write to /run anymore) | 00:03 |
| jbicha | ogra: my understanding is that Ubuntu does not set a max size for the systemd journal by default | 00:56 |
| ogra | jbicha, right ... so the possible max size is the size of /run ... and that isnt dynamic according to the mount options | 01:00 |
| ogra | which means you could potentially make /run out of space if the logs grow to its full size ... | 01:01 |
| jbicha | I have heard some user complaints about the journal getting way too big because some process is logging way too much | 01:02 |
| ogra | *make /run run out of space | 01:02 |
| ogra | right, the point is that if the above is actually true processes wouldnt be able to create sockets and tempfiles in /run which they normally do ... | 01:03 |
| ogra | this sounds so massively broken that i think i'm missing something important here ... which is why i asked ;) | 01:05 |
| infinity | ogra: It's no different from being able to starve /var with over-logging. I mean, except that /run is usually smaller, and journald is crap and certain people abuse journald quite heavily. :P | 01:41 |
| doko | ginggs: I think we have a problem with dolfin everywhere ... | 02:18 |
| === Macuser is now known as Guest69916 | ||
| ginggs | doko: looks similar to petsc, hangs during build with openmpi | 05:49 |
| ginggs | ...and arpack | 05:49 |
| === talisein is now known as Guest82313 | ||
| doko | ginggs: yes, already in the configury | 06:18 |
| ginggs | doko: i couldn't reproduce locally with gcc, openmpi and others from -proposed. and builds fine in debian | 06:21 |
| doko | rbalint: could you have a look at the nfs-utils autopkg test regression triggered by sqlite3? | 07:03 |
| rbalint | doko, ok, looking | 07:14 |
| rbalint | doko, seems like it was cloud-init, it runs fine now with latest cloud-init, just re-run it to be sure | 07:30 |
| seb128 | doko, thanks for the yaru review ... what was blocking? I expect having standards-version to 4.1.1 rather than 4.1.5 or use build-depends and not build-depends-indep are not big issues nor blockers, are they? (we are fixing, just curious if those were side comments or part of the reason you put it as incomplete) | 08:50 |
| doko | seb128: the question about gtk2 | 09:03 |
| didrocks | ok, I think I addressed it :) | 09:03 |
| seb128 | doko, k, we replied to that as well then :) | 09:09 |
| seb128 | if you can have another look? | 09:09 |
| doko | yes, after debconf dinner | 09:12 |
| seb128 | oh, right, enjoy and I hope debconf is nice :) | 09:26 |
| infinity | seb128: It's hot and sticky. | 09:36 |
| infinity | seb128: So, I guess that's "nice"? :P | 09:36 |
| === cjwatson_ is now known as cjwatson | ||
| xnox | ogra, wrong =) | 11:45 |
| xnox | jbicha, wrong =) | 11:45 |
| ogra | ah, you dragged it here | 11:45 |
| ogra | xnox, so wat am i missing ? | 11:45 |
| xnox | jbicha, ubuntu uses journald default limits that are capped dynamically based on ramsize and disksize, the actual limits are calculated and printed in the journal, when journald is started. The limits are conservative, but may seem large if one has a big hard drive. All of the bugs filed claiming that it was unlimited, were not true so far. But instead the system had large disks and journal was under the self imposed limit. The current absolute cap | 11:48 |
| xnox | for persistent logs is 4GB. But that's when persistent logging is enabled - may or may not be true, depends on the ubuntu release. | 11:48 |
| xnox | ogra, jbicha - full glory default details are at https://www.freedesktop.org/software/systemd/man/journald.conf.html#SystemMaxUse= | 11:48 |
| xnox | ogra, for you, it matters whether or not you have persistent journal enabled or not. | 11:49 |
| ogra | well, assume i'm using the default setup :) | 11:49 |
| ogra | (because thats what we do in ubuntu core) | 11:49 |
| xnox | ogra, and then check the right limits.... during boot journald logs to /run, but then flushes them to /var/log/journal if it's available. but it would not OOM your system. | 11:49 |
| ogra | so no persistence, journald.conf as is from the deb | 11:49 |
| xnox | ogra, there is no default, you have to pick one.... tell me if you have /var/log/journal directory present on disk? | 11:50 |
| xnox | ogra, it's not about journald.conf =) | 11:50 |
| ogra | we dont have a /var/log/journal in core, i can clearly see /run/log/journal being populated | 11:51 |
| xnox | ogra, that's bad, you should have /var/log/journal directory created, otherwise you have no logs from previous boot available. unless that's intentional. | 11:51 |
| xnox | ogra, all cloud images and later ubuntu releases have it pre-created by default. but it was not universally done in xenial. but we do on cloud images. | 11:52 |
| ogra | this is intentional ... we have rsyslog (this is xenial) ... | 11:52 |
| ogra | and rsyslog has a core option to allow to disable it to save disk IO on low end systems | 11:52 |
| xnox | ogra, ok, then go and read https://www.freedesktop.org/software/systemd/man/journald.conf.html#SystemMaxUse= noting that all limits apply just /run | 11:52 |
| xnox | and realise that it would not use up more than 15% of /run tmpfs ever.... | 11:53 |
| ogra | the system i looked at has rsyslog off and only uses journald with defaults ... logging to /run | 11:53 |
| ogra | aha !!!! | 11:53 |
| ogra | *that* was the info i was looking for | 11:53 |
| ogra | (the 15% bit) | 11:53 |
| * ogra hugs xnox | 11:53 | |
| ogra | thanks a lot ! | 11:54 |
| xnox | ogra, everything is in the manpages.... | 11:54 |
| xnox | ogra, possibly want to find the one on manpages.ubuntu.com | 11:54 |
| xnox | ogra, some of defaults are patched in the distro... but when i do that, i patch manpages to match reality too | 11:54 |
| ogra | well, i read the top which says "unmodified journald.conf reflects all defaults" . and SystemMaxUse= being empty made me assume there is no upper limit | 11:54 |
| ogra | i should have read on ;) | 11:55 |
| xnox | a conffile is not documentation | 11:55 |
| ogra | no, but the manpage note made me not read on but just look at the values in the conf | 11:56 |
| xnox | O_o? | 11:56 |
| * xnox notes ogra does not read man pages =)))))))))))))))) | 11:56 | |
| ogra | xnox, https://paste.ubuntu.com/p/CpftcGTb9W/ | 11:57 |
| ogra | i didnt bother to read on because of this note ... | 11:57 |
| xnox | ogra, depend on the key, "empty" has different meanings for a default what it is initialized to | 11:57 |
| ogra | right, perhaps the note should say that ... since i was assuming an empty key means no default (so no limit) | 11:58 |
| xnox | ogra, if something is numeric.... boolean... frequency.... etc..... | 11:58 |
| xnox | ogra, also i'm glad you think a logging system is stupid enough to be unlimited.... given that it is obvious that logs must be contained..... | 11:58 |
| ogra | not sure if its just me being dumb though :) or if others could fall into the same trap | 11:59 |
| xnox | ogra, anyway $ journalctl -b -u systemd-journald | 12:04 |
| xnox | should have like things like this | 12:04 |
| xnox | Aug 01 23:36:12 s1lp14 systemd-journald[701]: Runtime journal (/run/log/journal/9627530553e94a23bca5e0080fa400e4) is 8.0M, max 199.2M, 191.2M free. | 12:04 |
| xnox | Aug 01 23:36:12 s1lp14 systemd-journald[701]: System journal (/var/log/journal/9627530553e94a23bca5e0080fa400e4) is 504.0M, max 1.9G, 1.4G free. | 12:04 |
| xnox | the latter might not be here, if you don't have /var/log/journal | 12:05 |
| ogra | yep | 12:05 |
| ogra | $ sudo journalctl -b -u systemd-journald | 12:05 |
| ogra | -- Logs begin at Fri 2018-07-27 00:23:42 CEST, end at Thu 2018-08-02 14:05:32 CEST. -- | 12:05 |
| ogra | Jul 27 00:23:42 stream systemd-journald[464]: Runtime journal (/run/log/journal/) is 1.1M, max 9.1M, 8.0M free. | 12:05 |
| ogra | perfect | 12:06 |
| ogra | thanks a lot | 12:06 |
| xnox | tsimonq2, i think i fixed this.... https://launchpad.net/ubuntu/+source/gsettings-qt/0.1+17.10.20170824-5fakesync2 | 13:13 |
| xnox | tsimonq2, but now getting bus error on armhf..... can we like destroy armhf? or like kill gsettings-qt? | 13:15 |
| seb128 | shrug | 14:48 |
| seb128 | slashd, dgadomski, upload things before updating the bug and not updating the vcs = #fail :/ (speaking about gdm) | 14:48 |
| seb128 | slashd, I just merged that change and another one in the vcs and tagged/pushed, to get a conflict on uploading, now we have a vcs with mismatch the archive :/ | 14:49 |
| seb128 | slashd, dgadomski, please get the git situation sorted out, the recent commits need to be reverted and yours added, then the change reverted needs to be added back | 14:53 |
| slashd | o/ seb128 not sure to fully undertand what you mean here | 14:57 |
| seb128 | slashd, we have a packaging vcs, https://git.launchpad.net/~ubuntu-desktop/ubuntu/+source/gdm3?h=ubuntu%2Fmaster | 14:58 |
| seb128 | slashd, you are the one who uploaded https://launchpad.net/ubuntu/+source/gdm3/3.28.2-3ubuntu2 according to launchpad? | 14:58 |
| slashd | I did yes | 14:58 |
| seb128 | slashd, your upload is not in the vcs and conflicts with work pending upload done there | 14:58 |
| seb128 | slashd, oh well, I'm learning new git tricks and trying to fix it, but please next time when there is a vcs use it | 15:00 |
| slashd | seb128, sure, first time I was told something like this, will take note for sure | 15:00 |
| slashd | seb128, so does dgadomski and I have to do something at this point ? or you are good ? | 15:01 |
| seb128 | slashd, I'm good, you just created a bunch of extra work for me but I'm dealing with it | 15:01 |
| seb128 | slashd, do you plan to deal with the SRUs as well? | 15:02 |
| slashd | seb128, sorry for the inconvenient. For the SRU I was planning to do it too yes | 15:03 |
| seb128 | slashd, can you include the diff from https://code.launchpad.net/~albertomilone/ubuntu/+source/gdm3/+git/gdm3/+merge/351810 in the same upload? (I'm currently uploading that to cosmic) | 15:03 |
| seb128 | so we have both in the same SRU | 15:03 |
| seb128 | avoid another roundtrip | 15:03 |
| slashd | seb128, sure | 15:04 |
| seb128 | slashd, thx! | 15:04 |
| === tdaitx_ is now known as tdaitx | ||
| xnox | Setting up python3-twisted (17.9.0-2) ... | 16:22 |
| xnox | File "/usr/lib/python3/dist-packages/twisted/conch/manhole.py", line 154 | 16:22 |
| xnox | def write(self, data, async=False): | 16:22 |
| xnox | ^ | 16:22 |
| xnox | SyntaxError: invalid syntax | 16:22 |
| xnox | argh | 16:22 |
| xnox | packages should FTBFS on syntaxerrors.... | 16:22 |
| xnox | oh, wouldn't help probably | 16:23 |
| tsimonq2 | xnox: Thanks. | 16:30 |
| xnox | tsimonq2, no idea if this is right or wrong, but works for me | 16:33 |
| cjwatson | xnox: fixed upstream FWIW | 17:32 |
| cjwatson | commit ee535041258e7ef0b3223d2e12cd9aaa0bc2289f | 17:33 |
| tsimonq2 | xnox: Please push your patch upstream to Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=905059 | 17:38 |
| ubottu | Debian bug 905059 in gsettings-qt "gsettings-qt: FTBFS with Qt 5.11.1" [Serious,Open] | 17:38 |
| xnox | cjwatson, ah thanks! | 20:37 |
| xnox | cjwatson, oooh they did it in the neat way... cause i was like "surely that will break the function signature" | 20:39 |
| cjwatson | xnox: Yeah, clever hack | 22:32 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!