shoragan[m] has quit [Quit: Bridge terminating on SIGTERM]
static_rocket has quit [Quit: Bridge terminating on SIGTERM]
mvaittin has quit [Quit: Bridge terminating on SIGTERM]
tomba has quit [Quit: Bridge terminating on SIGTERM]
ikarso has joined #beagle
otisolsen70 has joined #beagle
ft has joined #beagle
florian has joined #beagle
mvaittin has joined #beagle
tomba has joined #beagle
static_rocket has joined #beagle
Shadyman has quit [Quit: Leaving.]
ft has quit [Quit: leaving]
Parduz has joined #beagle
<Parduz>
is the fstrim service needed on the BBB? if yes, why?
<zmatt>
fstrim is never "needed", but it can be useful to do every now and then, depending on usage of the eMMC and/or SD
starblue has quit [Ping timeout: 264 seconds]
<Parduz>
ok. I'm trying to disable some time-consuming service to get a better boot time, and i was wondering why it is active (and if it could not be "delayed" in some way)
<zmatt>
typically a concern would be that since the bbb can't keep the date/time, it would probably end up running on every boot, which is not good... but you have an rtc don't you?
<Parduz>
yes, i have
<zmatt>
by default it should only fstrim once a week
<zmatt>
not at boot
starblue has joined #beagle
<Parduz>
well, just as a "philosophical reasoning", i'd like more to have the BBB doing the same exact stuffs each time it goes on.
<zmatt>
yep, and if you minimize the amount of eMMC writes (which is a good idea anyway) then fstrimming also becomes less important
<Parduz>
it will live alone, not connected to anything, and being shut off by cutting power, not with nice "shut off", dunno if this is important
<zmatt>
it just means you really really want to avoid eMMC writes whenever possible
<Parduz>
i know
<zmatt>
(or SD, same thing but probably worse)
<Parduz>
uh! speaking of this:
<zmatt>
and we also configured some eMMC OTP settings into its most reliable configuration (but this sacrifices 50% of its space, which was fine for us but maybe not for everyone)
<Parduz>
my app calls udevadm and read the output (saved on a file open in memory) to seek for the "name" tag and see if the rtc module is installed (for compatibility reasons)
<zmatt>
ew
<zmatt>
you know udev has an API right? :P
<Parduz>
actually ... no.
<zmatt>
and wrapper libraries/modules in probably most major programming languages
<zmatt>
you can search for devices by criteria, get properties, and get notified of device additions/removals/changes
<Parduz>
i'll go looking for it, then
<Parduz>
i just found that solution at stackoverflow (or some branch of it) and it was praised, so i used it.
<Parduz>
my actual problem is that i see that the udevadm output still is saved on the .session-error file, but as there's better ways to get the infos, i'll go searching for them.
<Parduz>
.xsession-error *
<zmatt>
uhh that doesn't really make sense... if you're capturing its output to a pipe there's no plausible reason for it to end up in your .xsession-erors
<Parduz>
i agree, i'm forced to use some code not made by me so i need to check what happens there. Anyway, as i'll redo my part, i'll will see what happens after my upgrade.
<zmatt>
wait, I just read "saved on a file open in memory" ... how or why are you saving its output to file just to read that again? that's actually more complicated than just directly capturing its output
<zmatt>
how are you spawning the process? also, what programming language are we talking about?
<Parduz>
FILE *fp = popen("udevadm info -a -n rtc", "r");
<zmatt>
oh you meant FILE*, not an actual file
<Parduz>
yeah, sorry
<Parduz>
this is the first line i always have in .xsession-error: XIO: fatal IO error 11 (Resource temporarily unavailable) on X server ":0"
<Parduz>
after 10448 requests (10445 known processed) with 0 events remaining.
<zmatt>
... okay so that has absolutely nothing to do with this?
<Parduz>
yeah, i'm going over as you told me i have an API to use
<zmatt>
that's an error message from Xorg
<zmatt>
it's not from your program
<zmatt>
actually
<Parduz>
sure, i get this
<zmatt>
it might be from an X client
<zmatt>
but regardless it's X11-related
<zmatt>
kind of a weird "error" ... EAGAIN is normally not an error (in the contexts where it can appear) in the sense that it just means for a non-blocking socket that there's no more to read (or space to write)
<Parduz>
i have a bunch of warning/errors on the file: could them give you more clues?
<Parduz>
the opnebox and feh messages are just me still finishing, the other i don't know so much. I've just installed openbox and xinit on the minimal image
set_ has quit [Remote host closed the connection]
Elijah_Endee has joined #beagle
<Elijah_Endee>
Hello,
<Elijah_Endee>
I would like to know more about the obsolescence period for the BeaglePlay board as this is a hard requirement for my project team. Please kindly help with this information.
<Elijah_Endee>
Thanks
Stat_headcrabed has joined #beagle
Stat_headcrabed has quit [Quit: Stat_headcrabed]
stevemarple_ has joined #beagle
stevemarple_ has quit [Client Quit]
SteveMarple has quit [Ping timeout: 246 seconds]
SteveMarple has joined #beagle
Elijah_Endee has quit [Quit: Client closed]
rob_w has quit [Remote host closed the connection]
<zmatt>
"Xlib (libx11) will crash an application with a "Fatal IO error 11 (Resource temporarily unavailable)" after 4294967296 requests to the server. That is when the Xlib internal 32-bit sequence wraps."
<Parduz>
uh.... do you think this is related to my message? I'm not even sure my program is running, when that message appears.
<zmatt>
it's apparently the cause of the first message, regardless of what program is crashing there
<zmatt>
but it implies a long-running X11 process has just died
<zmatt>
X11 client
<zmatt>
that's been doing a ton of drawing
<zmatt>
I see a lot of random messages from random things but I have no idea what's going on here
<zmatt>
looks like some tools (xset, xsetroot) expected by some init scripts (/etc/X11/xinit/xinitrc) are missing
<Parduz>
well, i've just installed openbox, xinit, feh and noclutter. So not the "whole" xorg package
<zmatt>
it's a bit weird that that error 11 is the _first_ thing in the log
<zmatt>
oh actually xset is being called from /home/debian/.xsessionrc
<zmatt>
which is presumably your custom init script
<zmatt>
so you've trying to use a tool that isn't installed :P
<Parduz>
i never wrote that file but yes, the calls are there.
<zmatt>
hmm ok
<zmatt>
I doubt the file appeared by magic?
<Parduz>
i don't have done nothing to let openbox automatically start, but it runs after the (automated) login
<zmatt>
oh it's in the default image
<zmatt>
weird that it's in the IoT image
<Parduz>
mine is the "minimal". perhaps it is slipped in
<zmatt>
it's trying to configure the display to never go in sleep (xset -dpms), disable screen blanking (xset s off), and change the default mouse cursor from an X to a typical modern pointer
<zmatt>
these utils are part of the package x11-xserver-utils
<Parduz>
yup. the bbb never go to sleep, but i had to manage the screen being "put off" by writing something in a xorg folder
<Parduz>
about the cursor, it is always been an black arrow, i'd say that openbox manages it
<Parduz>
weird: i have a new error_
<zmatt>
Parduz: well that's because x11-xserver-utils isn't installed hence your (well, the debian user's) .xsessionrc couldn't do the setting
<zmatt>
for preventing display sleep
<zmatt>
and yeah your window manager will change the cursor for you
vagrantc has joined #beagle
<Parduz>
yeah, i've understood it and i'm fine with it
<zmatt>
setting the cursor like this in .xsessionrc is for people with extremely rudimentary environments, e.g. just x11 + their program, no window manager
<Parduz>
back to the .xsession-error, this is my first line: /home/debian/MSXPG/launcher.sh: line 23: 534 Segmentation fault ~/MSXPG/MSXPG - this
<Parduz>
before the previous XIO: fatal IO error 10 (No child processes) on X server ":0"
<Parduz>
after 4644 requests (4644 known processed) with 0 events remaining.
<Parduz>
which means that my app crashed, maybe 'cause x11 was not ready
<Parduz>
as now it is there, running happily
<Parduz>
i don't know what to think
<zmatt>
are those just old log messags? I noticed my .xsession-errors also seems to start in the middle of a session, while two 'Xsession: X session started' messages appear at later points
<zmatt>
I think maybe the first part of the file gets chopped off by something if the file gets too big
<Parduz>
i erased the file content before rebooting
<Parduz>
but:
<zmatt>
hmm
<Parduz>
wait a second:
<Parduz>
i've found this line on the journalctl
<Parduz>
[ 8.169466] BeagleBone systemd-journald[171]: System Journal (/var/log/journal/a196c2c082e749ad899d8e84ab4892c5) is 360.0M, max 350.8M, 0B free.
<Parduz>
is this related to what you're saying?
<zmatt>
no
<zmatt>
or, well, systemd-journald also rotates its "log" (journal) but it does so by periodically finishing one journal file and creating a new one, and old journal files eventually get removed
<zmatt>
.xsession-errors is just a giant mess, since it's just stderr of your xsession redirected to file, but that's then inherited by every process spawned from your xsession (including your window manager and all programs)
<zmatt>
so it can be hard to figure out what's coming from where
<zmatt>
it's created by /etc/X11/Xsession ... I see nothing to suggest there's a mechanism to restrict its size though
<Parduz>
i vaguely remember that it _should_ be restricted to 2MB, but i can't recall where i got this info.
<zmatt>
the problem is that you can't safely rotate it since there's no way to get the forest of running processes to reopen their stdout to the new file
<zmatt>
you could truncate it to zero bytes though
<zmatt>
but now that I think of it, I think I once noticed my xsession-errors had grown to more than a gigabyte
<Parduz>
i would like so much to stay here, but it is 6PM here, and my boss don't likes me staying here after. I hope to meet you here tomorrow, zmatt
<zmatt>
btw /etc/X11/Xsession is the top-level script of X11 startup, it's what's invoked by the X server to start setting up the GUI session
<zmatt>
a lot of stuff happening by default for users logging into desktop environments may not be relevant or even desirable for your situation
<Parduz>
(pls pardon me, and pls continue, i'll read your message tomorrow morning from the archive. THANKS A LOT, and sorry)
Parduz has quit [Quit: Leaving]
<zmatt>
well honestly I got other stuff to do and the bowels of X11 is not a place where I want to spend any more time than I strictly need to :P
florian has quit [Quit: Ex-Chat]
vagrantc has quit [Ping timeout: 246 seconds]
vagrantc has joined #beagle
balrog has quit [Quit: Bye]
balrog has joined #beagle
GenTooMan has quit [Read error: Connection reset by peer]
GenTooMan has joined #beagle
ikarso has quit [Quit: Connection closed for inactivity]
vagrantc has quit [Quit: leaving]
ft has joined #beagle
yCrazyEdd has quit [Ping timeout: 256 seconds]
yCrazyEdd has joined #beagle
zjason` has joined #beagle
zjason has quit [Ping timeout: 240 seconds]
xet7 has quit [Read error: Connection reset by peer]