Re: [systemd-devel] systemd-timesync and journalctl questions

2018-09-15 Thread D.S. Ljungmark 
On Mon, 10 Sep 2018 at 21:13, Lennart Poettering 
wrote:

> On Fr, 24.08.18 14:52, David Weinehall (david.weineh...@linux.intel.com)
> wrote:
>
> > We're having two time/date related issues/questions:
> >
> > First of all we'd need some counterpart to ntpdate.
> >
> > We have a system that lacks an RTC battery--the clock is reasonably
> reliable once the system
> > has booted, but every time the device is restarted it loses system time.
> Due to the use of the
> > machine we cannot allow the ntp server to run (since we need the clock
> to be monotonic).
> > Clock skew is OK, jumps aren't.
> >
> > For this purpose we'd want an equivalent to ntpdate to be able to sync
> the clock once on boot,
> > so we can keep systemd-timesync disabled during runtime.
>
> Such a mode is currently not supported by systemd-timesyncd. That
> said, I figure we could add that though. Please provide a PR... ;-)
>
> I am not sure how big the benefit of this would be in the general
> case, after all it can take arbitrary times until networking is
> available, and thus the difference between "continue running after
> first sync" and "exit after first sync" might be minimal in many
> cases.



I’ve got a follow up here. We want code to run both before and after time
is synchronized the first time. But we -also- need to know how big the
first time jump is.
It’s lokel to be in the matter of weeks or months in our application, and
we’d want to know how much it was lagging.
We start logging measurements before things are connected, and tag them as
unknown, later when we get an application sync on time we can recalculate
to proper dates,( provided we weren’t losing power  for many times before
we get a network sync)

I’d like to be able to get this data from timesyncd as it’d allow us to run
a more “normal” system, but I realize it might not be a feature you wish to
support.

> > So far both manual reading and googling has failed to turn up any such
> mode of operation.
> > Is there any? If not, would it be hard to implement?
>
> No this shouldn't be too hard. Just make timesyncd exit after the
> first sync if some config option is set, and use
> RestartPreventExitStatus= to disable automatic restart of the service
> in that case, depending on some specific exit code. The patch should
> be 30 lines or so (including docs).
>
> > The second time-related issue pertains to journalctl.
> >
> > It seems that journalctl logs (or at least displays) events in
> date/clock order, not in
> > sequence order. While this is definitely useful when trying to correlate
> different logs
> > against each other, it also means that events that happen after a date
> adjustment might
> > end up before already existing entries, thus breaking the sequentialness
> of the log,
> > as follows:
> >
> > Date incorrect set to 2023:
> >
> > Log message 1
> > Log message 2
> >
> > Date corrected to be 2018:
> >
> > Log message 3
> > Log message 1
> > Log message 2
> >
> > Typically this is not how we want our log to behave. Is there any way to
> > show the log in sequential order?
>
> So, this is most likely cause by journalctl's journal file
> interleaving logic, combined with the fact that journald will
> automatically close and start a new journal file whenever a time jump
> is detected.
>
> Basically, one idea of journald is to ensure that within each journal
> file log entry ordering is strictly monotonic when it comes to the all
> three ordering entry metrics: the CLOCK_MONOTONIC timestamp (trivial,
> the kernel guarantees montonicity within each boot, as long as we
> start a journal file fresh each boot), the journald-maintained
> sequence number (trivial, as journald increases it by one on each
> entry, hence guaranteed monotonic), and the CLOCK_REALTIME timestamp
> (for this we'll close the existing journal file on each clock change,
> and open a new one).
>
> During display journalctl will interleave individual journal files
> again, trying to be "as deterministic as possible" and preferring the
> more reliable ordering metrics over the less reliable onces,
> i.e. sequence numbers are preferred, with a fallback to
> CLOCK_MONOTONIC with a final fallback to CLOCK_REALTIME
> timestamps. Now, this is not as great as it seems at first, as the
> three sequences might be contradictory (i.e. because of a
> CLOCK_REALTIME jump an entry that is later than another due to seqno
> or CLOCK_MONOTONIC might appear earlier if you look at
> CLOCK_REALTIME). Moreover, journalctl will refuse comparing entry
> order by seqno and CLOCK_MONOTONIC unless the machine ID/boot ID in
> the journal files match. This means stuff logged during early boot
> will only be ordered by CLOCK_REALTIME usually, but if that is not
> reliable you basically have very little to compare the entries for
> ordering with.
>
> Or to say this differently: if you have no good clock its tough to
> order stuff, unless you have a continously writable storage where you
> can count up — but we don't have that,

Re: [systemd-devel] Triggering the HW Watchdog

2018-02-27 Thread D.S. Ljungmark 
Partially,

   It shows that systemd is handling the watchdog as I expect it to
here, but it also means that the "dysfunctional" times where the
system isn't resetting properly is _not_ due to watchdog triggering,
but is a "normal system" according to systemd.

Which is a worse case for me, since it's harder to debug.

So, conclusion:
 systemd seems to handle watchdog properly
 systemd seems to not die properly when we expect it to, leaving us to
find more debugging.

I hope that makes more sense than less.


On Tue, Feb 27, 2018 at 5:34 PM, Mantas Mikulėnas <graw...@gmail.com> wrote:
> On Tue, Feb 27, 2018 at 6:25 PM, D.S. Ljungmark <ljungm...@modio.se> wrote:
>>
>>
>>
>> On 27/02/18 15:21, Lennart Poettering wrote:
>> > On Di, 27.02.18 15:12, D.S. Ljungmark (ljungm...@modio.se) wrote:
>> >
>> >>> I figure you can send SIGSTOP to PID 1, no? (there are some signals
>> >>> the kernel blocks for PID 1, but I think SIGSTOP is not among them,
>> >>> please try)
>> >>
>> >> It seems that SIGSTOP is being filtered, because nothing appears to
>> >> happen, and the system certainly isn't rebooting.
>> >
>> > You should be able to trigger an abort in PID 1 by sending it SIGABRT
>> > or SIGQUIT or so. If PID 1 aborts it will actually enter a freeze loop
>> > in which it stops pinging the hw watchdog.
>> >
>> > Lennart
>>
>>
>> ABRT works,  or well..
>>
>> systemd[1]: Caught , core dump failed (child 3844, code=killed,
>> status=6/ABRT).
>>
>> And then a broadcast, freezing execution
>>
>>
>> And after that, what I was afraid of:
>>
>> [25417.186351] watchdog: watchdog0: watchdog did not stop!
>>
>
> Isn't that exactly the result you asked for?
>
> --
> Mantas Mikulėnas
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Triggering the HW Watchdog

2018-02-27 Thread D.S. Ljungmark 


On 27/02/18 15:21, Lennart Poettering wrote:
> On Di, 27.02.18 15:12, D.S. Ljungmark (ljungm...@modio.se) wrote:
> 
>>> I figure you can send SIGSTOP to PID 1, no? (there are some signals
>>> the kernel blocks for PID 1, but I think SIGSTOP is not among them,
>>> please try)
>>
>> It seems that SIGSTOP is being filtered, because nothing appears to
>> happen, and the system certainly isn't rebooting.
> 
> You should be able to trigger an abort in PID 1 by sending it SIGABRT
> or SIGQUIT or so. If PID 1 aborts it will actually enter a freeze loop
> in which it stops pinging the hw watchdog.
> 
> Lennart


ABRT works,  or well..

systemd[1]: Caught , core dump failed (child 3844, code=killed,
status=6/ABRT).

And then a broadcast, freezing execution


And after that, what I was afraid of:

[25417.186351] watchdog: watchdog0: watchdog did not stop!


Well, that gives me a tool to debug this with, Thank you!


//D.S

-- 
8362 CB14 98AD 11EF CEB6  FA81 FCC3 7674 449E 3CFC
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Triggering the HW Watchdog

2018-02-27 Thread D.S. Ljungmark 
( re-send as I forgot the list )

On 27/02/18 13:20, Lennart Poettering wrote:> On Di, 27.02.18 12:44,
D.S. Ljungmark (ljungm...@modio.se) wrote:
>
>> Hi list!
>>
>>  We're using systemd to control the hardware watchdog, and would want to
>> induce fail state to _verify_ that the shutdown/reboot process works as
>> expected.
>>
>> How do we make systemd "fail" to ping the watchdog?
>
> I figure you can send SIGSTOP to PID 1, no? (there are some signals
> the kernel blocks for PID 1, but I think SIGSTOP is not among them,
> please try)

It seems that SIGSTOP is being filtered, because nothing appears to
happen, and the system certainly isn't rebooting.


>> How do we control which states ( root fs not available, etc) cause
>> systemd to not ping the hardware watchdog?
>
> The watchdog is for detecting software hanging. Root fs not being
> available does not really qualify as "software hanging". If you want
> to reboot the machine if it fails to bring everything up, then use
> JobTimeoutAction= on some suitable action, for example local-fs.target
> or multi-user.target.
>
> Lennart
Thanks,
  I'm trying to get to a state where the machine fails over and triggers
watchdog on known things, rather than triggering the rescue shell or
similar.


I'll try with a jobtimeout on multi-user.

//D.S.


-- 
8362 CB14 98AD 11EF CEB6  FA81 FCC3 7674 449E 3CFC
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Triggering the HW Watchdog

2018-02-27 Thread D.S. Ljungmark 
Hi list!

 We're using systemd to control the hardware watchdog, and would want to
induce fail state to _verify_ that the shutdown/reboot process works as
expected.

How do we make systemd "fail" to ping the watchdog?

How do we control which states ( root fs not available, etc) cause
systemd to not ping the hardware watchdog?

//D.S.
-- 
8362 CB14 98AD 11EF CEB6  FA81 FCC3 7674 449E 3CFC
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Illegal CPUID instruction causes systemd core dump

2018-01-05 Thread D.S. Ljungmark 
On Fri, Jan 5, 2018 at 6:47 AM, Reindl Harald <h.rei...@thelounge.net> wrote:
>
>
> Am 05.01.2018 um 05:51 schrieb D.S. Ljungmark:
>>
>> If you want I can bring a small form factor early x86 to Fosdem.
>>
>> Industrial, rugged little things with x86 chipset was rather popular
>> for a while, and you can still order them new.  The ones I have aren't
>> i486 but a 586 (cyrix, I think).
>
>
> i am sure you can find everything if you want
>
> but are you running a recent distribution with the newest software on that
> box? i strongly doubt!

Up until two years ago, yeah.  Then we migrated them to ARM.

>
> P.S.: what about using proper mail- clients which knows list-headers instead
> "reply-all" and break threads because the faster offlist-mail leading to
> filter out the list-mail with the headers which comes later or do they also
> not exist on such old hardware?
>

Sure, once Evolution + Seahorse unbreaks in combination and stops
dying with gpg2.
Until then, it's sadly web-frontends.



>
>> On Thu, Dec 28, 2017 at 8:26 PM, Reindl Harald <h.rei...@thelounge.net>
>> wrote:
>>>
>>> Am 28.12.2017 um 20:07 schrieb tedheadster:
>>>>
>>>>
>>>> I am doing regression testing on old hardware. systemd-233 just
>>>> generated the following error on startup:
>>>>
>>>> I believe it is getting an illegal instruction trap on this first
>>>> generation 486 because it is calling "cpuid" in detect_vm_cpuid()
>>>> without first checking if the hardware supports it; it doesn't in this
>>>> case.
>>>>
>>>> The gcc compiler provides a workaround in the cpuid.h header file. You
>>>> can call __get_cpuid_max() first and check the return value > 0.
>>>>
>>>>
>>>>
>>>> https://stackoverflow.com/questions/14266772/how-do-i-call-cpuid-in-linux#14266932
>>>>
>>>> The Linux kernel still supports the 486 so we have to code around this
>>>> case, even if it is ancient hardware
>>>
>>>
>>>
>>> don't get me wrong - i am for 15 years now in the IT and my first PC in
>>> 1999
>>> was a i686
>>>
>>> i don't see how a brand new systemd and a mordern userland is supposed to
>>> run on 20 years or older hardware where nearly eveyr distribution these
>>> days
>>> is i586 or i686 only or starts to drop 32bit at all
>>>
>>> if you have that old hardware normally you don't use leading edge
>>> software
>>> on it and as a user (not systemd developer) i would love to see erevry
>>> single line of code for 20 years old hardware is removed to make it
>>> cleaner
>>> and in doubt faster on recent systems
>
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel



-- 
8362 CB14 98AD 11EF CEB6  FA81 FCC3 7674 449E 3CFC
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Illegal CPUID instruction causes systemd core dump

2018-01-04 Thread D.S. Ljungmark 
If you want I can bring a small form factor early x86 to Fosdem.

Industrial, rugged little things with x86 chipset was rather popular
for a while, and you can still order them new.  The ones I have aren't
i486 but a 586 (cyrix, I think).

On Thu, Dec 28, 2017 at 8:26 PM, Reindl Harald  wrote:
>
>
> Am 28.12.2017 um 20:07 schrieb tedheadster:
>>
>> I am doing regression testing on old hardware. systemd-233 just
>> generated the following error on startup:
>>
>> I believe it is getting an illegal instruction trap on this first
>> generation 486 because it is calling "cpuid" in detect_vm_cpuid()
>> without first checking if the hardware supports it; it doesn't in this
>> case.
>>
>> The gcc compiler provides a workaround in the cpuid.h header file. You
>> can call __get_cpuid_max() first and check the return value > 0.
>>
>>
>> https://stackoverflow.com/questions/14266772/how-do-i-call-cpuid-in-linux#14266932
>>
>> The Linux kernel still supports the 486 so we have to code around this
>> case, even if it is ancient hardware
>
>
> don't get me wrong - i am for 15 years now in the IT and my first PC in 1999
> was a i686
>
> i don't see how a brand new systemd and a mordern userland is supposed to
> run on 20 years or older hardware where nearly eveyr distribution these days
> is i586 or i686 only or starts to drop 32bit at all
>
> if you have that old hardware normally you don't use leading edge software
> on it and as a user (not systemd developer) i would love to see erevry
> single line of code for 20 years old hardware is removed to make it cleaner
> and in doubt faster on recent systems
>
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel



-- 
8362 CB14 98AD 11EF CEB6  FA81 FCC3 7674 449E 3CFC
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] "bootctl install" on mdadm raid 1 fails

2017-12-14 Thread D.S. Ljungmark 
Right, and _that_ causes a far less interesting output from blkid.

/dev/md0: UUID="1492-1FE7" VERSION="FAT32" TYPE="vfat" USAGE="filesystem"

On Thu, Dec 14, 2017 at 11:53 AM, Lennart Poettering
<lenn...@poettering.net> wrote:
> On Do, 14.12.17 11:44, D.S. Ljungmark (spi...@aanstoot.se) wrote:
>
>> I seem to have the same problem, and here's the output:
>>
>> [root@spring ~]# blkid -p /dev/sda1
>
> Well, I presume you are mounting /mnt/boot through the MD layer,
> right? Hence you need to check /dev/md0p1 or something
> instead. /dev/sd1 is the name of the partition without MD...
>
> Lennart
>
> --
> Lennart Poettering, Red Hat



-- 
8362 CB14 98AD 11EF CEB6  FA81 FCC3 7674 449E 3CFC
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] "bootctl install" on mdadm raid 1 fails

2017-12-14 Thread D.S. Ljungmark 
I seem to have the same problem, and here's the output:

[root@spring ~]# blkid -p /dev/sda1
/dev/sda1:
  UUID="01c0c70f-9204-8e4e-f2a7-aa8ec14c4a41"
  UUID_SUB="2a820238-597c-bfd4-aa2e-19425f7e8fa4"
  LABEL="spring.skuggor.se:0" VERSION="1.0"
  TYPE="linux_raid_member" USAGE="raid"
  PART_ENTRY_SCHEME="gpt"
  PART_ENTRY_NAME="EFI System Partition"
  PART_ENTRY_UUID="98b45cd9-11f8-402a-8c89-a4e833581446"
  PART_ENTRY_TYPE="c12a7328-f81f-11d2-ba4b-00a0c93ec93b"
  PART_ENTRY_NUMBER="1"
  PART_ENTRY_OFFSET="2048"
  PART_ENTRY_SIZE="409600"
  PART_ENTRY_DISK="8:0"


The machine is 6 disks, raid1 on /boot,  in mdadm format 1.0 (
metadata at the end of the device)  which allows each partition to be
mounted (read only) as itself.



On Mon, Dec 11, 2017 at 11:59 PM, Lennart Poettering
 wrote:
> On Fr, 08.12.17 23:33, Bjørn Forsman (bjorn.fors...@gmail.com) wrote:
>
>> Hi all,
>>
>> I assumed bootctl would be able to install onto a mdadm raid 1 array
>> (mirror). But this happens:
>>
>>   $ bootctl --path=/mnt/boot install
>>   Failed to probe partition scheme "/mnt/boot": Input/output error
>>
>> The raid array is created with --metadata=0.90 (superblock at the end
>> of device). systemd v234 was used for testing.
>>
>> I see people online that have worked around this by setting up the ESP
>> (/boot) manually, and finalizing the install with 2x calls to
>> efibootmgr. But I'm hoping for bootctl to handle this for me :-)
>>
>> Any ideas?
>
> Hmm, we simply use libblkid on the block device, and validate that
> everything is in order, i.e. has a GPT disk label, and all the right
> UUIDs and so on. It's very simple code. If that doesn't work, then
> either your setup is borked or most likely the bug is in libblkid.
>
> We ultimately don't care much what the backing block device really is,
> as long as it exposes a GPT partition table and the kernel exposes
> proper per-partition block devices.
>
> You can check if blkid works properly by running:
>
> # blkid -p /dev/sda1
> /dev/sda1: LABEL="SYSTEM" UUID="1234-5678" VERSION="FAT32" TYPE="vfat"
> USAGE="filesystem" PART_ENTRY_SCHEME="gpt" PART_ENTRY_NAME="EFI System
> Partition" PART_ENTRY_UUID="12345678-1234-1234-1234-123456789abc"
> PART_ENTRY_TYPE="c12a7328-f81f-11d2-ba4b-00a0c93ec93b"
> PART_ENTRY_FLAGS="0x1" PART_ENTRY_NUMBER="1" PART_ENTRY_OFFSET="2048"
> PART_ENTRY_SIZE="532480" PART_ENTRY_DISK="8:0"
>
> we need at least the fields PART_ENTRY_TYPE=, PART_ENTRY_SIZE=,
> PART_ENTRY_OFFSET=, PART_ENTRY_NUMBER=, PART_ENTRY_UUID=,
> PART_ENTRY_SCHEME= and TYPE= of these. If they are missing, then
> either your setup is bad, or blkid confused.
>
> That all said, unless mdadm operates with exactly zero header and
> footer on disk I doubt this will ever work and be compatible with
> EFI. But then again, I have no clue about mdadm...
>
> Good luck,
>
> Lennart
>
> --
> Lennart Poettering, Red Hat
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel



-- 
8362 CB14 98AD 11EF CEB6  FA81 FCC3 7674 449E 3CFC
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Scheduling unit at reboot.target and shutdown.target

2017-10-27 Thread D.S. Ljungmark 


On 27/10/17 12:25, Lennart Poettering wrote:
> On Fr, 27.10.17 11:43, D.S. Ljungmark (spi...@aanstoot.se) wrote:
> 
>> So, I've got a piece of hardware I want to do a final handover to just
>> around reboot.target / shutdown.target
>>
>> This will then cause the entire CPU and hardware allocated to it to
>> actually drop power (and schedule re-power), so I don't want to do this
>> earlier.
>>
>>
>>
>> Is it simply to do:
>>
>> [Unit]
>> DefaultDependencies=no
>>
>> [Service]
>> ExecStart=/usr/bin/big-buck-bunny /dev/i2c-1
>> Type=oneshot
>>
>> [Install]
>> WantedBy=reboot.target
>>
>> or am I missing something here? ( Perhaps the fact that systemd has
>> already pivoted root to somewhere else?)
> 
> Well, the above is not the right way really.
> 
> 1. If you want to go for the unit option, it is definitely a better
>idea to define one that is started at boot (but has ExecStart=
>empty and only ExecStop= defined, and uses RemainAfterExit= to
>ensure that it stays active even without a process around). Only
>that way you can properly order your unit against other shutdown
>units.
> 
> 2. Doing this via a unit means your code is invoked during the first
>phase of shutdown, inside the usual dependency tree logic. I figure
>you actually want to do this later even, i.e. after all services
>are down, after systemd did its killing spree and umount spree and
>all that stuff. For that simply drop the binary/script of your
>choice in /usr/lib/systemd/system-shutdown/. All files in that dir
>that are marked executable are executed right before we'd return to
>the initrd/invoke the reboot() syscall. Also see:
>systemd-shutdown(8)
> 
> 3. Note that the scripts in /usr/lib/systemd/system-shutdown/ are
>invoked at a time where the root file system itself is still
>mounted. This means various weird storage daemons might still be
>pinned (think: root on mdraid/LVM/…). Hence, turning off power at
>that point is not fully safe nor correct either, except if you know
>your setup and know you don't have weird storage. If you want to
>cover this generic case too, then you have to use an initrd, make
>use of systemd's logic to transition back into the initrd at
>shutdown, and invoke what you want to invoke from there.
> 
> Lennart



Since this is an embedded case, we have fairly good control over what's
running and where.  For example, rootfs is not a problem as it's
squashfs, and shouldn't be degraded by rebooting.  As long as our
configuration/data partitions aren't mounted, we ought to be good.

And thank you for the pointer about /usr/lib/systemd/system-shutdown/
that indeed sounds a lot better for us.

ExecStop does indeed sound like the wrong solution as well, as mentioned
due to the ordering.


Thanks for the thorough explanation, much appreciated!

//D.S.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Scheduling unit at reboot.target and shutdown.target

2017-10-27 Thread D.S. Ljungmark 
So, I've got a piece of hardware I want to do a final handover to just
around reboot.target / shutdown.target

This will then cause the entire CPU and hardware allocated to it to
actually drop power (and schedule re-power), so I don't want to do this
earlier.



Is it simply to do:

[Unit]
DefaultDependencies=no

[Service]
ExecStart=/usr/bin/big-buck-bunny /dev/i2c-1
Type=oneshot

[Install]
WantedBy=reboot.target



or am I missing something here? ( Perhaps the fact that systemd has
already pivoted root to somewhere else?)

//D.S.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd should not depend on CONFIG_CRYPTO_USER_API_HASH

2017-03-20 Thread D.S. Ljungmark 
I find your argument to be strange.

"The kernel has this functionality, please do not use it and rather
reimplement it in every piece of userspace that ever needs it, because
that's supposed to be more secure."

I simply don't buy your argument here.

//D.S.

On Mon, Mar 20, 2017 at 8:22 AM, Eric Biggers  wrote:
> Hello,
>
> The latest systemd README and NEWS claim that the userspace interface to the
> in-kernel hash algorithms (CONFIG_CRYPTO_USER_API_HASH) is now required.
>
> I don't know how much thought was put into this decision, but I think it's a
> mistake security-wise.  AF_ALG sockets increase the kernel's attack surface by
> allowing users to instantiate and use arbitrary crypto algorithms, in
> combinations or ways which may not have been tested.  Indeed, historically 
> there
> have been a number of security vulnerabilities related to this feature, both 
> in
> the API itself and in the various crypto modules.  For this reason, I think
> security-conscious users would prefer to have this kernel feature turned off.
>
> Why exactly does systemd suddenly need this feature?  If it's really just to
> compute hashes, then please do it in userspace instead.  Unless systemd 
> *really*
> needs to support using hardware crypto accelerators, there is no need to call
> into the kernel just to compute hashes.  Or at the very least, make the
> dependency optional.
>
> Thanks!
>
> - Eric
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel



-- 
8362 CB14 98AD 11EF CEB6  FA81 FCC3 7674 449E 3CFC
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [networkd] Mixing DHCP & static IPs on 1 interface

2017-02-22 Thread D.S. Ljungmark 


On 22/02/17 15:57, Reindl Harald wrote:
> 
> please keep repsonses on the list
> 
> Am 22.02.2017 um 15:42 schrieb Ian Pilcher:
>> On 02/21/2017 08:28 PM, Reindl Harald wrote:
>>> since this should be all on the LAN side something is *very* unusual on
>>> your setup - the firewall i setup at office is just a virtual machine
>>> with a single NIC and is able to do NAT and filtering as well as
>>> traffic-shaping (limit all workstations together to 80% of the WAN line)
>>> with a single IP address - so i don't see any reason why your firewall
>>> can't forward packages to your router independent of the WAN state on
>>> the other side of the router
>>
>> It's not a matter for forwarding packets to a *router*.  I'm trying to
>> get packets to go to the cable modem, which listens on that 192.168.X.X
>> address - regardless of the actual public subnet
> 
> but i don't understand why it has a different IP address depending on
> the state of the WAN side - normally you talk to your modem over the LAN
> 
> "If I lose connectivity, however, my firewall doesn't have a default
> route" - solve that
> 
> https://www.cyberciti.biz/faq/linux-creating-or-adding-new-network-alias-to-a-network-card-nic/
> 

It's not that uncommon.

The device is using a DHCP relay/proxy towards the LAN side, and allows
both states at once. You configure a hard-coded subnet for diagnostics
pages, and DHCP gets routed through to the other side.

This means that his devices (linux machine) appear to themselves to be
on the open side of the network, (WAN) and not being NAT-ed at all.

So, it's para-bridging the interfaces and that's a perfectly valid thing
to do.

//D.S
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd-journald error

2016-11-30 Thread D.S. Ljungmark 


On 25/11/16 22:47, Joel wrote:
> Lennart -
> 
> 
> Thank you for the reply.
> 
> 
> It's not clear whether you are instructing me to do something
> (restart journald or rebuild initrd) or asking a question.

If your distribution builds in the config file into the initrd, it's not
enough to simply edit the journald.conf on your live system and restart
journald,  you'll also need to rebuild the initrd.

If journald is started in initrd (early boot), it will still see the
config file from the initrd if getting a reload signal.


> On Fri, 25.11.16 05:33, Joel Miller (jm-hotm...@hotmail.com) wrote:
> 
>> Because I had misspelled the word "persistent" as "persisten"
>> (dropping the final "t"), I received the following error:
>> 
>> [1.485872] systemd-journald[104]:
>> [/etc/systemd/journald.conf:11] Failed to parse storage setting,
>> ignoring: persisten
>> 
>> Despite correcting the .conf file (/etc/systemd/journald.conf in
>> SuSE Leap 42.1), the error remains, perhaps because the value is
>> cached somewhere in the system, but it is not causing any issues
>> that I can detect.  I welcome any suggestions of where to look.
> 
> You have to restart journald of course?
> 
> Or maybe rebuild your initrd because the config file is also added
> to the initrd on your distro?
> 
> Lennart
> 
> -- Lennart Poettering, Red Hat
> 
> 
> 
> ___ systemd-devel mailing
> list systemd-devel@lists.freedesktop.org 
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
> 
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Munge start Error

2016-11-17 Thread D.S. Ljungmark 


On 17/11/16 13:11, JEYARAJ wrote:
> Hi All,
> 
> Dear Sir,
> I ,am installing  job scheduling system for a single machine.munge also
> installed latest version.
> I start with Munge service .Error is showing;
> 
> Again I used the command:
> 
> Systemctl status munge.service 
> 
> Error is came.
> 
> Please help me sir..
> 

The solution is there in the image that you sent to the list. This is
not an error in systemd, nor is it systemd-specific.


See the line that says "munged[9101] : munged: Error: Failed to check
logfile".

That line is the one that is relevant.

"permission denied" means that either the directory it's attempting to
open, or the file it's attempting to open, is owned by someone else than
the user munged runs as .


I'd suggest you look at the munged mailinglist or forum for help with this.

Most probably, if the init scripts read the files as a "munge"
user, but you've manually launched it as root, you've created the log
files with the wrong permissions / owner, and then get to fix it first.


Good luck.

//D.S.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Multiple starts of a service, what am I doing wrong?

2015-09-24 Thread D.S. Ljungmark 
I've got the following unit:

[Unit]
Description=Random Submitter
Wants=network-online.target
After=network-online.target other.service
RequiresMountsFor=/data

[Service]
Type=simple
Environment=PYTHONPATH=/data
PrivateTmp=false
# Launches client config and others if needed
ExecStartPre=/usr/bin/pre-submitter
ExecStart=/usr/bin/random-submitter
Restart=always
RestartSec=60

[Install]
WantedBy=multi-user.target



With the following path unit activation:

[Path]
PathExists=/data/certificate.crt
PathExists=/data/submitter.ini

[Install]
WantedBy=multi-user.target


Status tells us:

● submitter.service - Random Submitter
Loaded: loaded (/data/systemd/submitter.service; enabled)
Active: active (running) since Wed 2015-09-23 20:20:34 UTC; 13h ago
Process: 6217 ExecStartPre=/usr/bin/pre-submitter (code=exited,
status=0/SUCCESS)
Main PID: 6225 (python3)
CGroup: /system.slice/submitter.service
└─6225 python3 /usr/bin/random-submitter

Sep 24 10:17:53 modio systemd[1]: Started Random Submitter Service.
Sep 24 10:17:53 modio systemd[1]: Started Random Submitter Service.
Sep 24 10:17:54 modio systemd[1]: Started Random Submitter Service.
Sep 24 10:17:54 modio systemd[1]: Started Random Submitter Service.
Sep 24 10:17:54 modio systemd[1]: Started Random Submitter Service.
Sep 24 10:17:54 modio systemd[1]: Started Random Submitter Service.
Sep 24 10:17:54 modio systemd[1]: Started Random Submitter Service.
Sep 24 10:17:54 modio systemd[1]: Started Random Submitter Service.
Sep 24 10:17:54 modio systemd[1]: Started Random Submitter Service.
Sep 24 10:17:54 modio systemd[1]: Started Random Submitter Service.


And the logs contain... a TON.. of those "started" messages.

journalctl --since -13h -u submitter |grep "Started" |wc -l

24341

So. What have I done wrong here?
(Systemd 215 on Debian)


-- 
8362 CB14 98AD 11EF CEB6 FA81 FCC3 7674 449E 3CFC



-- 
8362 CB14 98AD 11EF CEB6  FA81 FCC3 7674 449E 3CFC
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Multiple starts of a service, what am I doing wrong?

2015-09-24 Thread D.S. Ljungmark 
(re-send due to wrong email address)

On 24/09/15 14:38, Daniel Mack wrote:
> On 09/24/2015 01:17 PM, D.S. Ljungmark wrote:
>> I've got the following unit:
>>
>> [Unit]
>> Description=Random Submitter
>> Wants=network-online.target
>> After=network-online.target other.service
>> RequiresMountsFor=/data
>>
>> [Service]
>> Type=simple
> 
> Type=simple implies that the executable specified through ExecStart= is
> the main process and that it does not fork but 'block'. Is that the
> case? If it does fork, like most daemons do, Type= should be set to
> 'forking'.
> 
> Or do you actually want to run that binary just once, without systemd
> restarting it after it died? That you should set Type= to 'oneshot'.
> 
> See systemd.service(5) for more information.


That is correct. ExecStartPre does some environment/Testing, while the
actual submitter will run fpr ~20 hours, slowly doing network chatter,
and abort in case of network error (trusting systemd to restart it)

So, it's a daemon that never forks.

The question I have isn't about this running or not (it runs
beautifully, gets restarted when it should, and starts once it has a
certificate available)

However, systemd is _spewing_ out this "started service" message, even
while it's already running.

And that's what I'm trying to figure out.

//D.S.

-- 
8362 CB14 98AD 11EF CEB6  FA81 FCC3 7674 449E 3CFC


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Unit files on another partition

2014-12-12 Thread D.S. Ljungmark 
hi,
  Our / partitions are on a squashfs media, which means that unit files
are read-only. There is a partition for read-write content
(Scratchable), and I'm wondering if it would be possible to add
unit-files there and have the boot order cope with this correctly?


How should this be set up -properly- (of course I can just insert a unit
early on depending on the mounting of the RW-area and have everything
depend on this, but I'm not sure that's the -right- solution. )

//D.S.

-- 
8362 CB14 98AD 11EF CEB6  FA81 FCC3 7674 449E 3CFC



signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Journal, rotation and loglevels

2014-12-02 Thread D.S. Ljungmark 
On 24/10/14 00:47, Lennart Poettering wrote:
 On Thu, 23.10.14 17:19, D.S. Ljungmark (spi...@aanstoot.se) wrote:
 


 On 23/10/14 16:50, Lennart Poettering wrote:
 On Thu, 23.10.14 15:27, D.S. Ljungmark (spi...@aanstoot.se) wrote:

 Hi,
   we have a few services that are spamming a fair bit on DEBUG level of
 log output. In syslog, we'd separate the DEBUG logs from the main log,
 and set the rotation of DEBUG+ to be ~24 hours, while keeping INFO and
 above for ~4 weeks.

 How can we do something similar with Journald?

 No, currenty you cannot. You can turn off storage from a certain log
 level on (MaxLevelStore=), but you cannot change the retention time
 per log level yet.

 So if we set MaxLevelStore=INFO, we won't get the journal on disk
 stored. How much is stored in memory and how do you control that
 amount?
 
 MaxLevelStore= controls what hits /run+/var, it makes not distinction
 there. If you set MaxLevelStore= then this means debug messages get
 dropped entirely.
 
 Right now, we don't store anything to disk ( no persistent disk in the
 system ) and why we're asking is that our DEBUG logs flushed the errors
  warnings from last night, and we have no idea what actually went
 wrong.   Before this, we were storing things (syslogd) but after
 migrating to journald, we didn't figure out how to get them saved
 properly, so it's been punted onto the very long TODO list by us as well.


 Can I get a journal of ~50M (compressed?) stored on disk with Info and
 above levels, and then another 50M of debug+above in RAM?
 
 Nope, this is currently not supported, but support a scheme like this
 is on the TODO list.

Thank you, then I'll just wait.

//D.S.


-- 
8362 CB14 98AD 11EF CEB6  FA81 FCC3 7674 449E 3CFC



signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Service not restarting after Condition failed

2014-11-25 Thread D.S. Ljungmark 
On 24/11/14 20:30, Umut Tezduyar Lindskog wrote:
 Hi
 
 On Monday, November 24, 2014, D.S. Ljungmark spi...@aanstoot.se
 mailto:spi...@aanstoot.se wrote:
 
 On 10/11/14 23:09, Lennart Poettering wrote:
  On Thu, 30.10.14 18:47, D.S. Ljungmark (spi...@aanstoot.se
 javascript:;) wrote:
 
  Hi
   we have a service set to:
  ConditionFileNotEmpty=
 
  and
 
  Restart=Always
 
 
  This combination would (in my feebled mind) cause the service to
 restart
  once the Condition was fulfilled, but that doesn't seem to be the
  case.
 
  Conditions are something that are on-time evaluated right before we
  would start a unit, and cause this starting to be shortcut. That's all
  really. Restarts are only triggered when a running service dies, and
  the start job queued by that will then check the conditions again. If
  the condition doesn't hold then this start will not be executed, and
  hence no restart ever again either...
 
  Is there a way I can get a service to restart even after it has
 been set
  as inactive (dead) start condition failed?
 
  Nope, conditions are not for that. For the specific check of
  file-not-empty there's no nice way to handle this, however for
  directory-not-empty you could set up DirectoryNotEmpty=...
 
  Should I simply remove the Condition, or something else?
 
  What precisely are you trying to do?
 
  Lennart
 
 Basically, some files (config  certificates) may not exist on a system
 until it's provisioned properly, something that may take a while ( a few
 days)
 
 After provisioning, we want the services depending on those file to
 start automatically.
 
  
 Path unit files should work for
 you,  http://www.freedesktop.org/software/systemd/man/systemd.path.html
 
 Umut

Thanks, those would work well. I take it those should be in combination
to the ConditionFileNotEmpty=  for the same files?



//D.S.


-- 
8362 CB14 98AD 11EF CEB6  FA81 FCC3 7674 449E 3CFC



signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Watchdog timeout signals

2014-11-24 Thread D.S. Ljungmark 
Hi,
 We're pondering to use the WatchdogSec=.. function, but wanted to know
what signal (if any) are sent to the application before termination.

Main reason is that we want to get a proper stacktrace of the daemon if
it is killed for some reason.

//D.S.
-- 
8362 CB14 98AD 11EF CEB6  FA81 FCC3 7674 449E 3CFC



signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Watchdog timeout signals

2014-11-24 Thread D.S. Ljungmark 
On 24/11/14 17:58, Peter Sztanojev wrote:
 On Mon, Nov 24, 2014 at 5:39 PM, D.S. Ljungmark spi...@aanstoot.se wrote:
 Hi,
  We're pondering to use the WatchdogSec=.. function, but wanted to know
 what signal (if any) are sent to the application before termination.

 Main reason is that we want to get a proper stacktrace of the daemon if
 it is killed for some reason.

 
 You will be glad to hear this (depending on your version):
 http://cgit.freedesktop.org/systemd/systemd/tree/NEWS#n189
 

Those are great news, except that I'm on 215...

Well, it'll get there sooner or later, thanks!

//D.S.

-- 
8362 CB14 98AD 11EF CEB6  FA81 FCC3 7674 449E 3CFC



signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Service not restarting after Condition failed

2014-11-24 Thread D.S. Ljungmark 
On 10/11/14 23:09, Lennart Poettering wrote:
 On Thu, 30.10.14 18:47, D.S. Ljungmark (spi...@aanstoot.se) wrote:
 
 Hi
  we have a service set to:
 ConditionFileNotEmpty=

 and

 Restart=Always


 This combination would (in my feebled mind) cause the service to restart
 once the Condition was fulfilled, but that doesn't seem to be the
 case.
 
 Conditions are something that are on-time evaluated right before we
 would start a unit, and cause this starting to be shortcut. That's all
 really. Restarts are only triggered when a running service dies, and
 the start job queued by that will then check the conditions again. If
 the condition doesn't hold then this start will not be executed, and
 hence no restart ever again either...
 
 Is there a way I can get a service to restart even after it has been set
 as inactive (dead) start condition failed?
 
 Nope, conditions are not for that. For the specific check of
 file-not-empty there's no nice way to handle this, however for
 directory-not-empty you could set up DirectoryNotEmpty=...
 
 Should I simply remove the Condition, or something else?
 
 What precisely are you trying to do?
 
 Lennart

Basically, some files (config  certificates) may not exist on a system
until it's provisioned properly, something that may take a while ( a few
days)

After provisioning, we want the services depending on those file to
start automatically.

//D.S.


-- 
8362 CB14 98AD 11EF CEB6  FA81 FCC3 7674 449E 3CFC



signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Service not restarting after Condition failed

2014-10-30 Thread D.S. Ljungmark 
Hi
 we have a service set to:
ConditionFileNotEmpty=

and

Restart=Always


This combination would (in my feebled mind) cause the service to restart
once the Condition was fulfilled, but that doesn't seem to be the case.

Is there a way I can get a service to restart even after it has been set
as inactive (dead) start condition failed?

Should I simply remove the Condition, or something else?

//D.S.


-- 
8362 CB14 98AD 11EF CEB6  FA81 FCC3 7674 449E 3CFC



signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Journal, rotation and loglevels

2014-10-23 Thread D.S. Ljungmark 
Hi,
  we have a few services that are spamming a fair bit on DEBUG level of
log output. In syslog, we'd separate the DEBUG logs from the main log,
and set the rotation of DEBUG+ to be ~24 hours, while keeping INFO and
above for ~4 weeks.

How can we do something similar with Journald?

Keeping all DEBUG info isn't really possible as journald is now rotating
all logs every ~12 hours, and retention is basically shot to hell.

Regards,
 D.S.


-- 
8362 CB14 98AD 11EF CEB6  FA81 FCC3 7674 449E 3CFC





signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Journal, rotation and loglevels

2014-10-23 Thread D.S. Ljungmark 


On 23/10/14 16:50, Lennart Poettering wrote:
 On Thu, 23.10.14 15:27, D.S. Ljungmark (spi...@aanstoot.se) wrote:
 
 Hi,
   we have a few services that are spamming a fair bit on DEBUG level of
 log output. In syslog, we'd separate the DEBUG logs from the main log,
 and set the rotation of DEBUG+ to be ~24 hours, while keeping INFO and
 above for ~4 weeks.

 How can we do something similar with Journald?
 
 No, currenty you cannot. You can turn off storage from a certain log
 level on (MaxLevelStore=), but you cannot change the retention time
 per log level yet.

So if we set MaxLevelStore=INFO, we won't get the journal on disk
stored. How much is stored in memory and how do you control that amount?

Right now, we don't store anything to disk ( no persistent disk in the
system ) and why we're asking is that our DEBUG logs flushed the errors
 warnings from last night, and we have no idea what actually went
wrong.   Before this, we were storing things (syslogd) but after
migrating to journald, we didn't figure out how to get them saved
properly, so it's been punted onto the very long TODO list by us as well.


Can I get a journal of ~50M (compressed?) stored on disk with Info and
above levels, and then another 50M of debug+above in RAM?



 
 Also see this thread:
 
 http://lists.freedesktop.org/archives/systemd-devel/2014-October/024348.html
 

Thanks, seems I'm echoing the feature requests here.

//D.S.

-- 
8362 CB14 98AD 11EF CEB6  FA81 FCC3 7674 449E 3CFC



signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel