Re: [systemd-devel] asset failure that looks like it's coming from systemd/
On 25/12/21 15:04, Scott Andrews wrote: On Sat, 25 Dec 2021 07:43:14 +1100 Jonathan Kelly wrote: On 25/12/21 01:23, Andy Pieters wrote: On Fri, 24 Dec 2021 at 10:11, Jonathan Kelly wrote: On 24/12/21 19:45, Andy Pieters wrote: On Fri, 24 Dec 2021 at 01:53, Jonathan Kelly wrote: make[2]: Entering directory '/usr/local/src/unicon/uni/lib' ../../bin/unicon -s -c gui.icn Assertion '(size_t) r < n' failed at src/basic/random-util.c:232, function genuine_random_bytes(). Aborting. make[2]: *** [../../Makedefs.uni:48: gui.u] Aborted (core dumped) What points you to suspect systems? the line from the error Assertion '(size_t) r < n' failed at src/basic/random-util.c:232, that's from systemd. https://github.com/systemd/systemd/blob/main/src/basic/random-util.c look at line 232 Have you looked at the coredump? (i.e. coredumpctl) No. I'm in the middle here ... trying to compile unicon and it borks ... the unicon people don't know anything about random-util.c ... it not part of their software. If it comes to it, I can look at more technical sleuthing, but I'd need some direction. Jonathan. After googling this for 1 minute I came across this [1] Arch AUR package is out of date, use the GIT version as documented in [1] Not the fault of systemd, the fault of using an old package. They explain that they stopped using svn in 2019, and having just downloaded the Arch AUR package it shows svn checkout in the prepare function... [1] https://sourceforge.net/p/unicon/discussion/starters/thread/4ea4931e8e/?limit=25 I'm not using the AUR, I'm cloning from GIT ./configure make I do know how to use google: that's how I found out src/basic/random-util.c was part of systemd Jonathan. I have been following this so I tried the following: cd /tmp git clone git://git.code.sf.net/p/unicon/unicon cd unicon ./configure make -j4 cd /tmp/unicon/bin/ ./unicon -version Unicon Version 13.3. December 23, 2021 (13.2-232-g3438a755 pre-release) ./unicon -features Unicon Version 13.3. December 23, 2021 (13.2-232-g3438a755 pre-release) UNIX POSIX DBM ASCII co-expressions native coswitch concurrent threads dynamic loading environment variables event monitoring external functions keyboard functions large integers multiple programs pattern type pipes pseudo terminals system function messaging libz file compression CCompiler gcc 8.3.0 Physical memory: 3932356608 bytes Revision 6306_3438a755 Arch arm_32 CPU cores 4 binaries at /tmp/unicon/bin/ My platform is raspberry pi 4 with raspios 32 bit os This has systemd version v247. raspios is based on debian 10 Is your platform/system failing as in out of memory or something like that? Maybe some type of corruption? What compiler are you using? Arch linux 64 bit - AMD FX6300 6 core / 16G mem jon@arch:/usr/local/src/unicon$ uname -a Linux arch 5.15.10-arch1-1 #1 SMP PREEMPT Fri, 17 Dec 2021 11:17:37 + x86_64 GNU/Linux jon@arch:/usr/local/src/unicon$ bin/unicon -features Unicon Version 13.3. December 14, 2021 (13.2-228-gf1990ae5 pre-release) UNIX POSIX DBM ASCII co-expressions native coswitch concurrent threads dynamic loading environment variables event monitoring external functions keyboard functions large integers multiple programs pattern type pipes pseudo terminals system function messaging graphics X Windows libz file compression JPEG images PNG images SQL via ODBC secure sockets layer encryption CCompiler gcc 11.1.0 Physical memory: 16806125568 bytes Revision 6305_f1990ae5 Arch x86_64 CPU cores 6 Binaries at /usr/local/src/unicon/bin/
Re: [systemd-devel] asset failure that looks like it's coming from systemd/
On Sat, 25 Dec 2021 07:43:14 +1100 Jonathan Kelly wrote: > On 25/12/21 01:23, Andy Pieters wrote: > > > > > > On Fri, 24 Dec 2021 at 10:11, Jonathan Kelly > > wrote: > > > > On 24/12/21 19:45, Andy Pieters wrote: > >> > >> > >> On Fri, 24 Dec 2021 at 01:53, Jonathan Kelly > >> wrote: > >> > >> make[2]: Entering directory > >> '/usr/local/src/unicon/uni/lib' ../../bin/unicon -s -c gui.icn > >> Assertion '(size_t) r < n' failed at > >> src/basic/random-util.c:232, > >> function genuine_random_bytes(). Aborting. > >> make[2]: *** [../../Makedefs.uni:48: gui.u] Aborted > >> (core dumped) > >> > >> > >> What points you to suspect systems? > > > > > > the line from the error > > > > Assertion '(size_t) r < n' failed at > > src/basic/random-util.c:232, > > > > that's from systemd. > > > > > > https://github.com/systemd/systemd/blob/main/src/basic/random-util.c > > > > look at line 232 > > > > > >> > >> Have you looked at the coredump? (i.e. coredumpctl) > > > > No. I'm in the middle here ... trying to compile unicon and it > > borks ... the unicon people don't know anything about > > random-util.c ... it not part of their software. > > > > If it comes to it, I can look at more technical sleuthing, > > but I'd need some direction. > > > > > > Jonathan. > > > > > > After googling this for 1 minute I came across this [1] > > > > Arch AUR package is out of date, use the GIT version as > > documented in [1] > > > > Not the fault of systemd, the fault of using an old package. They > > explain that they stopped using svn in 2019, and having just > > downloaded the Arch AUR package it shows svn checkout in the > > prepare function... > > > > [1] > > https://sourceforge.net/p/unicon/discussion/starters/thread/4ea4931e8e/?limit=25 > > > > > > > I'm not using the AUR, I'm cloning from GIT > > > > ./configure > make > > > I do know how to use google: that's how I found out > src/basic/random-util.c was part of systemd > > > Jonathan. I have been following this so I tried the following: cd /tmp git clone git://git.code.sf.net/p/unicon/unicon cd unicon ./configure make -j4 cd /tmp/unicon/bin/ ./unicon -version Unicon Version 13.3. December 23, 2021 (13.2-232-g3438a755 pre-release) ./unicon -features Unicon Version 13.3. December 23, 2021 (13.2-232-g3438a755 pre-release) UNIX POSIX DBM ASCII co-expressions native coswitch concurrent threads dynamic loading environment variables event monitoring external functions keyboard functions large integers multiple programs pattern type pipes pseudo terminals system function messaging libz file compression CCompiler gcc 8.3.0 Physical memory: 3932356608 bytes Revision 6306_3438a755 Arch arm_32 CPU cores 4 binaries at /tmp/unicon/bin/ My platform is raspberry pi 4 with raspios 32 bit os This has systemd version v247. raspios is based on debian 10 Is your platform/system failing as in out of memory or something like that? Maybe some type of corruption? What compiler are you using?
Re: [systemd-devel] asset failure that looks like it's coming from systemd/
On Thu, Dec 23, 2021 at 8:54 PM Jonathan Kelly wrote: > > Hi, > > in trying to compile unicon programming language - I'm on arch linux ... > > Linux arch 5.15.10-arch1-1 #1 SMP PREEMPT Fri, 17 Dec 2021 11:17:37 > + x86_64 GNU/Linux > > ... I'm getting this error > > make[2]: Entering directory '/usr/local/src/unicon/uni/lib' > ../../bin/unicon -s -c gui.icn > Assertion '(size_t) r < n' failed at src/basic/random-util.c:232, > function genuine_random_bytes(). Aborting. > make[2]: *** [../../Makedefs.uni:48: gui.u] Aborted (core dumped) > > > does anyone have any clues as to what is going on, and/or how to resolve > the issue? I would suggest running "../../bin/unicon -s -c gui.icn" in gdb to get a backtrace. That will help determine exactly what code is calling this function.
Re: [systemd-devel] asset failure that looks like it's coming from systemd/
On 25/12/21 07:43, Jonathan Kelly wrote: On 25/12/21 01:23, Andy Pieters wrote: On Fri, 24 Dec 2021 at 10:11, Jonathan Kelly wrote: On 24/12/21 19:45, Andy Pieters wrote: On Fri, 24 Dec 2021 at 01:53, Jonathan Kelly wrote: make[2]: Entering directory '/usr/local/src/unicon/uni/lib' ../../bin/unicon -s -c gui.icn Assertion '(size_t) r < n' failed at src/basic/random-util.c:232, function genuine_random_bytes(). Aborting. make[2]: *** [../../Makedefs.uni:48: gui.u] Aborted (core dumped) What points you to suspect systems? the line from the error Assertion '(size_t) r < n' failed at src/basic/random-util.c:232, that's from systemd. https://github.com/systemd/systemd/blob/main/src/basic/random-util.c look at line 232 Have you looked at the coredump? (i.e. coredumpctl) No. I'm in the middle here ... trying to compile unicon and it borks ... the unicon people don't know anything about random-util.c ... it not part of their software. If it comes to it, I can look at more technical sleuthing, but I'd need some direction. Jonathan. After googling this for 1 minute I came across this [1] Arch AUR package is out of date, use the GIT version as documented in [1] Not the fault of systemd, the fault of using an old package. They explain that they stopped using svn in 2019, and having just downloaded the Arch AUR package it shows svn checkout in the prepare function... [1] https://sourceforge.net/p/unicon/discussion/starters/thread/4ea4931e8e/?limit=25 I'm not using the AUR, I'm cloning from GIT git clone git://git.code.sf.net/p/unicon/unicon ./configure make I do know how to use google: that's how I found out src/basic/random-util.c was part of systemd Jonathan. Just wanted to add, I'm not assuming it's JUST a problem with systemd, but rather looking for some clues that I can feed back to the unicon people. Though, it is an assert that is failing. From looking at the code, it seems getrandom() is returning more than requested, which is the size of a buffer - that doesn't sound good. In any case, could someone say what would be triggering a call to genuine_random_bytes()? Thanks Jonathan.
Re: [systemd-devel] asset failure that looks like it's coming from systemd/
On 25/12/21 01:23, Andy Pieters wrote: On Fri, 24 Dec 2021 at 10:11, Jonathan Kelly wrote: On 24/12/21 19:45, Andy Pieters wrote: On Fri, 24 Dec 2021 at 01:53, Jonathan Kelly wrote: make[2]: Entering directory '/usr/local/src/unicon/uni/lib' ../../bin/unicon -s -c gui.icn Assertion '(size_t) r < n' failed at src/basic/random-util.c:232, function genuine_random_bytes(). Aborting. make[2]: *** [../../Makedefs.uni:48: gui.u] Aborted (core dumped) What points you to suspect systems? the line from the error Assertion '(size_t) r < n' failed at src/basic/random-util.c:232, that's from systemd. https://github.com/systemd/systemd/blob/main/src/basic/random-util.c look at line 232 Have you looked at the coredump? (i.e. coredumpctl) No. I'm in the middle here ... trying to compile unicon and it borks ... the unicon people don't know anything about random-util.c ... it not part of their software. If it comes to it, I can look at more technical sleuthing, but I'd need some direction. Jonathan. After googling this for 1 minute I came across this [1] Arch AUR package is out of date, use the GIT version as documented in [1] Not the fault of systemd, the fault of using an old package. They explain that they stopped using svn in 2019, and having just downloaded the Arch AUR package it shows svn checkout in the prepare function... [1] https://sourceforge.net/p/unicon/discussion/starters/thread/4ea4931e8e/?limit=25 I'm not using the AUR, I'm cloning from GIT git clone git://git.code.sf.net/p/unicon/unicon ./configure make I do know how to use google: that's how I found out src/basic/random-util.c was part of systemd Jonathan.
Re: [systemd-devel] asset failure that looks like it's coming from systemd/
On Fri, 24 Dec 2021 at 10:11, Jonathan Kelly wrote: > On 24/12/21 19:45, Andy Pieters wrote: > > > > On Fri, 24 Dec 2021 at 01:53, Jonathan Kelly wrote: > >> make[2]: Entering directory '/usr/local/src/unicon/uni/lib' >> ../../bin/unicon -s -c gui.icn >> Assertion '(size_t) r < n' failed at src/basic/random-util.c:232, >> function genuine_random_bytes(). Aborting. >> make[2]: *** [../../Makedefs.uni:48: gui.u] Aborted (core dumped) >> > > What points you to suspect systems? > > > the line from the error > > Assertion '(size_t) r < n' failed at src/basic/random-util.c:232, > > that's from systemd. > > > https://github.com/systemd/systemd/blob/main/src/basic/random-util.c > > look at line 232 > > > > Have you looked at the coredump? (i.e. coredumpctl) > > > No. I'm in the middle here ... trying to compile unicon and it borks ... > the unicon people don't know anything about random-util.c ... it not part > of their software. > > If it comes to it, I can look at more technical sleuthing, but I'd need > some direction. > > > Jonathan. > After googling this for 1 minute I came across this [1] Arch AUR package is out of date, use the GIT version as documented in [1] Not the fault of systemd, the fault of using an old package. They explain that they stopped using svn in 2019, and having just downloaded the Arch AUR package it shows svn checkout in the prepare function... [1] https://sourceforge.net/p/unicon/discussion/starters/thread/4ea4931e8e/?limit=25
Re: [systemd-devel] After= and Wants= doesn't seem to have an effect
I think the temperature-controller.service is stopped due to the
Before=temperature-controller.service in coco-wiper-manager.service.
There are no BindsTo=
The Conflicts=shutdown.target only.
I will do some more investigations after New Year.
Thank you for your time and explanations!
Merry X'mas and Happy New Year!
Christopher Wong
From: Anita Zhang
Sent: Thursday, December 23, 2021 9:21:48 AM
To: Christopher Wong
Cc: systemd-devel@lists.freedesktop.org
Subject: Re: [systemd-devel] After= and Wants= doesn't seem to have an effect
I think the telling part is "temperature-controller.service/start finished,
result=canceled". When another job for the same unit comes in (e.g.
"temperature-controller.service: Trying to enqueue job
temperature-controller.service/stop/replace") then the first job gets canceled
and replaced by the new one (this is the default behavior which I think can be
overridden). The bad part is systemd doesn't have logs to tell you why the stop
transaction was issued. Maybe you can use `systemctl show
temperature-controller.service` to see if there are BindsTo= or Conflicts=
dependencies that are not listed in the unit files and causing the stop job to
get issued.
As for your other point about why opticsd.service runs after
temperature-controller.service's stop job, I think this is by design. According
to
https://github.com/systemd/systemd/blob/4d484e14bb9864cef1d124885e625f33bf31e91c/src/core/job.c#L1659-L1698
if "b" starts after "a", but "a" has a stop job queued, then "a" will stop,
then "b" will start. Substitute opticsd for "b" and temperature-controller for
"a". The Wants= property issued a start job so what you're expecting is "a"
starts, then "b" starts. But due to the canceled job mentioned above, you're
instead left with "a" stops, then "b" starts.
Hope that helps,
Anita
On Wed, Dec 22, 2021 at 10:15 AM Christopher Wong
mailto:christopher.w...@axis.com>> wrote:
The code is being run on systemd 247.6. I finally got some debug logs to share
(see below). The starting of opticsd.service is held back, waiting for
temperature-controller.service, which is good. However, the line right after:
Job 721, which is a stop job for temperature-controller finished with
result=done. That seems to trigger the continuation of opticsd.service. I don't
have the logs for when Job 107 was started and why Job 721 is created. My guess
is that temperature-controller is waiting for coco-wiper-manager as indicated
in Job 722 and Job 809. Could this really be a bug and I am that lucky to
stumble into it?
Dec 22 18:03:17 axis-b8a44f278c56 systemd[1]: Got message type=method_call
sender=n/a destination=org.freedesktop.systemd1 path=/org/freedesktop/systemd1
interface=org.freedesktop.systemd1.Manager member=StopUnit cookie=1
reply_cookie=0 signature=ss error-name=n/a error-message=n/a
Dec 22 18:03:17 axis-b8a44f278c56 systemd[1]: temperature-controller.service:
Trying to enqueue job temperature-controller.service/stop/replace
Dec 22 18:03:17 axis-b8a44f278c56 systemd[1]: Added job
temperature-controller.service/stop to transaction.
Dec 22 18:03:17 axis-b8a44f278c56 systemd[1]: temperature-controller.service:
Job 107 temperature-controller.service/start finished, result=canceled
Dec 22 18:03:17 axis-b8a44f278c56 systemd[1]: Sent message type=signal
sender=org.freedesktop.systemd1 destination=n/a path=/org/freedesktop/systemd1
interface=org.freedesktop.systemd1.Manager member=JobRemoved cookie=1
reply_cookie=0 signature=uoss error-name=n/a error-message=n/a
Dec 22 18:03:17 axis-b8a44f278c56 systemd[1]: temperature-controller.service:
Installed new job temperature-controller.service/stop as 721
Dec 22 18:03:17 axis-b8a44f278c56 systemd[1]: temperature-controller.service:
Enqueued job temperature-controller.service/stop as 721
Dec 22 18:03:17 axis-b8a44f278c56 systemd[1]: Sent message type=signal
sender=org.freedesktop.systemd1 destination=n/a
path=/org/freedesktop/systemd1/unit/temperature_2dcontroller_2eservice
interface=org.freedesktop.DBus.Properties member=PropertiesChanged cookie=2
reply_cookie=0 signature=sa{sv}as error-name=n/a error-message=n/a
Dec 22 18:03:17 axis-b8a44f278c56 systemd[1]: Sent message type=signal
sender=org.freedesktop.systemd1 destination=n/a
path=/org/freedesktop/systemd1/unit/temperature_2dcontroller_2eservice
interface=org.freedesktop.DBus.Properties member=PropertiesChanged cookie=3
reply_cookie=0 signature=sa{sv}as error-name=n/a error-message=n/a
Dec 22 18:03:17 axis-b8a44f278c56 systemd[1]: Sent message type=signal
sender=org.freedesktop.systemd1 destination=n/a path=/org/freedesktop/systemd1
interface=org.freedesktop.systemd1.Manager member=JobNew cookie=4
reply_cookie=0 signature=uos error-name=n/a error-message=n/a
Dec 22 18:03:17 axis-b8a44f278c56 systemd[1]: Sent message type=method_return
sender=org.freedesktop.systemd1 destination=n/a path=n/a interface=n/a
member=n/a
Re: [systemd-devel] asset failure that looks like it's coming from systemd/
On 24/12/21 19:45, Andy Pieters wrote: On Fri, 24 Dec 2021 at 01:53, Jonathan Kelly wrote: make[2]: Entering directory '/usr/local/src/unicon/uni/lib' ../../bin/unicon -s -c gui.icn Assertion '(size_t) r < n' failed at src/basic/random-util.c:232, function genuine_random_bytes(). Aborting. make[2]: *** [../../Makedefs.uni:48: gui.u] Aborted (core dumped) What points you to suspect systems? the line from the error Assertion '(size_t) r < n' failed at src/basic/random-util.c:232, that's from systemd. https://github.com/systemd/systemd/blob/main/src/basic/random-util.c look at line 232 Have you looked at the coredump? (i.e. coredumpctl) No. I'm in the middle here ... trying to compile unicon and it borks ... the unicon people don't know anything about random-util.c ... it not part of their software. If it comes to it, I can look at more technical sleuthing, but I'd need some direction. Jonathan.
Re: [systemd-devel] asset failure that looks like it's coming from systemd/
On Fri, 24 Dec 2021 at 01:53, Jonathan Kelly wrote: > make[2]: Entering directory '/usr/local/src/unicon/uni/lib' > ../../bin/unicon -s -c gui.icn > Assertion '(size_t) r < n' failed at src/basic/random-util.c:232, > function genuine_random_bytes(). Aborting. > make[2]: *** [../../Makedefs.uni:48: gui.u] Aborted (core dumped) > What points you to suspect systems? Have you looked at the coredump? (i.e. coredumpctl)
