Uki images

[Michał Zegan]

Hello,

Using fedora39, it officially doesn't support uki images... i have 
custom boot configuration.


Set layout=uki in install.conf and uki_generator to ukify, and other uki 
related options.


Everything seems to work except that, even though linux kernel is picked 
up when creating uki, initrd is not. it's like I get a initrd-less kernel.


How to make it work other than manually building uki after the fact? 
note it's stock fedora 39 with installed and working systemd-boot, so 
only population of /boot/efi/EFI/Linux is important here. Previously i 
had a custom install.d script.

Re: [systemd-devel] efivarfs mounting

[Michał Zegan]

Hello,

That seems to work, thank you.

W dniu 17.01.2023 o 13:05, Michał Zegan pisze:
It is a fedora system with a custom build kernel. As for why, probably 
the only answer is that it is because i am weird, it is a laptop also 
used as my personal playground.


When it goes to initrd, it might be it's not in initrd, in which case 
that could explain it. Can see.


W dniu 17.01.2023 o 12:33, Lennart Poettering pisze:

On Mo, 16.01.23 21:30, Michał Zegan (webc...@outlook.com) wrote:


At quick glance i cannot find anything about it. what about kernel
configuration? efivarfs is compiled as a module. is there any 
possible thing

that might happen here?

Ah, so this is not a fedora system as you claim? fedora builds it
in. And yeah, if this is a kmod then it might not be available that
early.  But why would you do that as a kmod?

Is the thing included in your initrd?

Lennart

--
Lennart Poettering, Berlin

Re: [systemd-devel] efivarfs mounting

[Michał Zegan]

It is a fedora system with a custom build kernel. As for why, probably 
the only answer is that it is because i am weird, it is a laptop also 
used as my personal playground.


When it goes to initrd, it might be it's not in initrd, in which case 
that could explain it. Can see.


W dniu 17.01.2023 o 12:33, Lennart Poettering pisze:

On Mo, 16.01.23 21:30, Michał Zegan (webc...@outlook.com) wrote:


At quick glance i cannot find anything about it. what about kernel
configuration? efivarfs is compiled as a module. is there any possible thing
that might happen here?

Ah, so this is not a fedora system as you claim? fedora builds it
in. And yeah, if this is a kmod then it might not be available that
early.  But why would you do that as a kmod?

Is the thing included in your initrd?

Lennart

--
Lennart Poettering, Berlin

Re: [systemd-devel] efivarfs mounting

[Michał Zegan]

At quick glance i cannot find anything about it. what about kernel 
configuration? efivarfs is compiled as a module. is there any possible 
thing that might happen here?


W dniu 16.01.2023 o 18:52, Lennart Poettering pisze:

On Mo, 16.01.23 18:30, Michał Zegan (webc...@outlook.com) wrote:


Hello,

What should be responsible for mounting efivarfs?

Using systemd-251 on fedora37, and my machine is booted in uefi mode also
with secureboot, but /sys/firmware/efi/efivars is not mounted on
boot, why?

pid1 does that early on, unconditionally on EFI systems. No manual
work necessary. pid consumes some efivars, hence it ensures it is
mounted aleady.


I cannot find any unit file related to efivarfs mounting, and honestly even
adding a fstab entry didn't work. I am out of ideas. Can mount it manually
but am sure previously it worked, but unsure when.

if it's not mounted, then something really strange is going
on. selinux issue maybe? or something manually unmounting it later?

Lennart

--
Lennart Poettering, Berlin

[systemd-devel] efivarfs mounting

[Michał Zegan]

Hello,

What should be responsible for mounting efivarfs?

Using systemd-251 on fedora37, and my machine is booted in uefi mode 
also with secureboot, but /sys/firmware/efi/efivars is not mounted on 
boot, why?


I cannot find any unit file related to efivarfs mounting, and honestly 
even adding a fstab entry didn't work. I am out of ideas. Can mount it 
manually but am sure previously it worked, but unsure when.

Re: [systemd-devel] Antw: Re: Antw: Re: Antw: [EXT] Re: Q: Start network in chroot?

[Michał Zegan]

W dniu 14.06.2022 o 10:19, Ulrich Windl pisze:

Michal Zegan  schrieb am 14.06.2022 um 09:25 in Nachricht



...

Sure when "init" was just a bundle of scripts, you could run one of the
scripts it runs and hope for the best. You can generally still do that,
but just don't expect asking a non-running program to do it for you to work!

Still I don't understand: systemd is running.

on the host. daemons usually read configuration, including service
files, from the place they run from. systemd is not running from chroot
so it will read services from outside of chroot, doing othervise would
be extremely weird behavior.

Thank you for this explanation; it makes sense. However (as written a moment 
ago) the original error messgae is not really helpful trying to understand the 
root cause of the issue.
But still I guess I cannot have a second systemd in chroot.


note contrary to sysvinit you are not running service scripts, but you
communicate with an already running systemd instance to start a service,
so because systemd runs from outside of chroot it cannot start a service
as if it was in a chroot, nor can this service read config files from
chroot.

OK, the problem seems to be that systemctl does not "pass" the units to systemd, but 
systemd "ate" (and digested) them all before.
passing them wouldn't help as it would still be systemd running the 
service, so it would have to run it from chroot, it would be a separate 
feature which wouldn't be something you'd expect out of the box.



You would literally need running systemd copy related to the chroot
which you cannot do without namespacing, and you would need network
interface in that ns.

namespaces are quite new to me. I have no experience with those.


this would be quite complex but doable. I am crazy enough to play with 
stuff like this when I am bored.


I imagine you would need to be careful so that trying to run your guest 
os this way won't try to do things like loading modules into the host.


another method I saw being used is running guest os in a vm if a rescue 
system allows installing software, but at this point you could install 
nspawn too and use it.





Regards,
Ulrich


would be an interesting experiment to do without container software tbh.


Regards,
Ulrich


Col









OpenPGP_0xE6516A8A8E25955D.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: [systemd-devel] Antw: Re: Antw: [EXT] Re: Q: Start network in chroot?

[Michał Zegan]

W dniu 14.06.2022 o 07:57, Ulrich Windl pisze:

Colin Guthrie  schrieb am 13.06.2022 um 16:34 in

Nachricht :


Ulrich Windl wrote on 13/06/2022 14:42:

Colin Guthrie  schrieb am 13.06.2022 um 14:58 in

Nachricht :

Ulrich Windl wrote on 13/06/2022 09:09:

Hi!

Two questions:
1) Why can't I use "systemctl start network" in a chroot environment (e.g.

mounting the system from a rescue medium to fix a defective kernel)? When I
try I get: "Running in chroot, ignoring command 'start'"

2) How can I start the network using systemd?

You may wish to consider "booting" the container rather than just chrooting.

No container involved; an unbootable system instead, and I'd like to have

networking available for repair.

So obviously I cannot boot. Without systemd it wouldn't be a problem.

So you're not running an init system but you want the (not-running) init
system to run something for you?

I don't understand:
The rescue system I'm using (SLES 14 SP3) uses systemd, and the system that 
woon't boo is also using systemd (SLES15 SP3).


If you're wanting to repair a system, and you need networking then bring
up the network in the repair image before chrooting surely? (i.e. what
Mantas said)

Well the configuration files are not in the generic rescue system, but in the 
system that won't boot (I think I had explained that).
Also things became much more complicated with systemd and wickedd and all that 
stuff.


If you want to run the network inside the (broken) system you're trying
to repair, then just run the networking scripts or program manually.
i.e. run whatever /etc/init.d/network says or whatever ExecStart= says
in /usr/lib/systemd/network.service says (paths may vary).

There are no files inside /etc/init.d/.


There will be loads of other stuff that the init system does that won't
be in place (e.g. tmpfiles, etc.) which you may or may not need to setup
manually too, but you can likely get it running.

  > Without systemd it wouldn't be a problem.

Sure when "init" was just a bundle of scripts, you could run one of the
scripts it runs and hope for the best. You can generally still do that,
but just don't expect asking a non-running program to do it for you to work!

Still I don't understand: systemd is running.


on the host. daemons usually read configuration, including service 
files, from the place they run from. systemd is not running from chroot 
so it will read services from outside of chroot, doing othervise would 
be extremely weird behavior.


note contrary to sysvinit you are not running service scripts, but you 
communicate with an already running systemd instance to start a service, 
so because systemd runs from outside of chroot it cannot start a service 
as if it was in a chroot, nor can this service read config files from 
chroot.


You would literally need running systemd copy related to the chroot 
which you cannot do without namespacing, and you would need network 
interface in that ns.


would be an interesting experiment to do without container software tbh.



Regards,
Ulrich


Col






OpenPGP_0xE6516A8A8E25955D.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: [systemd-devel] Antw: [EXT] Re: Q: Start network in chroot?

[Michał Zegan]

W dniu 13.06.2022 o 16:34, Colin Guthrie pisze:


Ulrich Windl wrote on 13/06/2022 14:42:
Colin Guthrie  schrieb am 13.06.2022 um 
14:58 in

Nachricht :

Ulrich Windl wrote on 13/06/2022 09:09:

Hi!

Two questions:
1) Why can't I use "systemctl start network" in a chroot 
environment (e.g.
mounting the system from a rescue medium to fix a defective kernel)? 
When I

try I get: "Running in chroot, ignoring command 'start'"

2) How can I start the network using systemd?


You may wish to consider "booting" the container rather than just 
chrooting.


No container involved; an unbootable system instead, and I'd like to 
have networking available for repair.

So obviously I cannot boot. Without systemd it wouldn't be a problem.


in theory you have unshare in mos environments. you might not have 
access to nspawn, but you can unshare. I have used raw namespaces 
previously, although mostly mount ns, not network ns.


also this is uncommon that you cannot configure the network before 
chrooting, as in at host side, then just copy or bindmount resolv.conf 
and have it working in chroot.




So you're not running an init system but you want the (not-running) 
init system to run something for you?


If you're wanting to repair a system, and you need networking then 
bring up the network in the repair image before chrooting surely? 
(i.e. what Mantas said)


If you want to run the network inside the (broken) system you're 
trying to repair, then just run the networking scripts or program 
manually. i.e. run whatever /etc/init.d/network says or whatever 
ExecStart= says in /usr/lib/systemd/network.service says (paths may 
vary).


There will be loads of other stuff that the init system does that 
won't be in place (e.g. tmpfiles, etc.) which you may or may not need 
to setup manually too, but you can likely get it running.


> Without systemd it wouldn't be a problem.

Sure when "init" was just a bundle of scripts, you could run one of 
the scripts it runs and hope for the best. You can generally still do 
that, but just don't expect asking a non-running program to do it for 
you to work!


Col



OpenPGP_0xE6516A8A8E25955D.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: [systemd-devel] cgroupsv2 and realtime processes

[Michał Zegan]

W dniu 6.06.2022 o 18:29, Michal Koutný pisze:

On Mon, Jun 06, 2022 at 05:59:32PM +0200, Michał Zegan  
wrote:

I assume if it would be on it would break any and all realtime
usage...?

Most likely (you'd not be able either: turn on RT policy, migrate the
process or enable CPU controller, i.e. a step that'd lead to an invalid
state).

I'm curious, what would be your use case for turning RT group
schedulling on?


I don't necessarily have any usecase, I just forgot that option was even 
configurable. Even though i knew about it's existence previously.


Arch disables it by default and this seems to be a good choice. but 
cgroupsv2 docs don't say that this behavior is conditioned on that 
option so I forgot it existed.




Thanks,
Michal


OpenPGP_0xE6516A8A8E25955D.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: [systemd-devel] cgroupsv2 and realtime processes

[Michał Zegan]

W dniu 6.06.2022 o 17:14, Michal Koutný pisze:

On Mon, Jun 06, 2022 at 04:54:03PM +0200, Michał Zegan  
wrote:

this note pointed to in the readme is quite cgroups v1 specific, I believe
what it describes was true in v1, and v2 does not have any capability to
control realtime processes in non root cgroups if I read correctly.

Yes. And it extends to v2 too where there are even no userspace knobs to
configure the RT attributes.

Therefore it works [1] with CONFIG_RT_GROUP_SCHED unset since RT
processes remain in the root cgroup (it's an implementation detail you
won't see from /proc/$pid/cgroup, where is still the regular process
membership).
To prevent confusion -- this applies only to processes (threads) with RT
policy and from all other perspectives these processes (threads) are
still in the listed cgroup.

Does that explain what you were after?
yes. forgot about that option to be fair. I assume if it would be on it 
would break any and all realtime usage...?


Michal

[1] Unless your goal is to control per-cgroup RT attributes. I
understood you just wanted to be able to place RT processes into
non-root cgroups.


OpenPGP_0xE6516A8A8E25955D.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: [systemd-devel] cgroupsv2 and realtime processes

[Michał Zegan]

W dniu 6.06.2022 o 16:02, Michal Koutný pisze:

Hello Michał.

On Sun, Jun 05, 2022 at 03:28:23PM +0200, Michał Zegan  
wrote:

I have kernel 5.17 on archlinux.

How is your kernel configured wrt CONFIG_RT_GROUP_SCHED?

it is unset



Is that still true?

That depends :-)


Yet, checking /proc/(pid)/cgroup states these processes are not in a root
cgroup, yet the cpu controller is enabled on the root cgroup
(/sys/fs/cgroup/cgroup.subtree_control lists "cpu" as one of the controllers
and I see the interface files in children).

Can anyone explain the situation?

With v2 and CONFIG_RT_GROUP_SCHED there's no way how to assign realtime
budgets to cgroups and therefore realtime tasks cannot run in them.

With !CONFIG_RT_GROUP_SCHED, there's (internally) only the root cgroup
for realtime tasks and things apparently work.

See also [1].
this note pointed to in the readme is quite cgroups v1 specific, I 
believe what it describes was true in v1, and v2 does not have any 
capability to control realtime processes in non root cgroups if I read 
correctly.




The cgroupsv2 documentation states that cgroup cpu controller
currently does not support realtime processes, so to enable it all
realtime processes must be moved to root cgroup.

Will you send a docs patch with the CONFIG_RT_GROUP_SCHED reservation?
:-p

HTH,
Michal

[1] 
https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fsystemd%2Fsystemd%2Fblob%2F369151c9c73b12fb7a88fc2b558499c2d4832982%2FREADME%23L140&data=05%7C01%7C%7C2497332c429b4459b16308da47c5367e%7C84df9e7fe9f640afb435%7C1%7C0%7C637901209614621463%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=dXYxa0cDT48qoJDUwJKA%2B2d7vBLYxdc1TuZztaQqQWI%3D&reserved=0


OpenPGP_0xE6516A8A8E25955D.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

[systemd-devel] cgroupsv2 and realtime processes

[Michał Zegan]

Hello,

This is more of a kernel than systemd question but I am not subscribed 
to any kernel ml and I assume systemd people should know the answer.


I have kernel 5.17 on archlinux. The cgroupsv2 documentation states that 
cgroup cpu controller currently does not support realtime processes, so 
to enable it all realtime processes must be moved to root cgroup.


Is that still true?

I ask because what I currently have is that things like pipewire sound 
server are running on the system, and some of pipewire's threads do have 
realtime priority, it seems.


Yet, checking /proc/(pid)/cgroup states these processes are not in a 
root cgroup, yet the cpu controller is enabled on the root cgroup 
(/sys/fs/cgroup/cgroup.subtree_control lists "cpu" as one of the 
controllers and I see the interface files in children).


Can anyone explain the situation?

The user.slice which contains, indirectly, the pipewire cgroup 
(pipewire.service) doesn't have the cpu controller enabled, but I assume 
that shouldn't make a difference.




OpenPGP_0xE6516A8A8E25955D.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: [systemd-devel] use RTC date/time to set system date time

[Michał Zegan]

Thanks for the insight.

W dniu 01.03.2021 o 17:34, Lennart Poettering pisze:
> On Mo, 01.03.21 17:17, Michał Zegan (webczat_...@poczta.onet.pl) wrote:
> 
>>> But this stuff is racy of course if the RTC is compiled as module and
>>> you care for generic hw, that might or might not have an RTC: we
>>> cannot gues swhether an RTC will show up or not in that case,
>>> i.e. whether there is an RTC connected and whether there's a driver
>>> for it. Hence we time-{set|sync}.target cannot possibly wait for it to
>>> show up since it might mean we have to wait indefinitely...
>> I actually think kernel doesn't set on module load, and if it does, it's
>> very recent. How recent would it be? What kernel?
> 
> https://github.com/torvalds/linux/commit/f9b2a4d6a5f18e0aaf715206a056565c56889d9f
> 
> (also see: https://github.com/systemd/systemd/issues/17737)
> 
>>> If you really don't want to compile it in, and love the extra
>>> headaches this involves, then make sure you run a recent kernel that
>>> can sync the system clock to RTC even when the module is loaded
>>> later. And then manually add an ordering dep to time-set.target to
>>> wait for /dev/rtc0, since that is the target that should be delayed
>>> until the RTC shows up and is probed:
>>
>> What is normally attached to this target?
> 
> time-set.target is the target that software that needs "roughly
> correct time" is ordered after. (as opposed to time-sync.target which
> is the target that software that needs "accurate correct time" is
> ordered after). Sounds vague? That's because it is, on purpose.
> 
> To illustrate the two targets a bit:
> 
> systemd-timesyncd.service is ordered before time-set.target. It
> maintains a touch file in /var/lib/ that is used to make the clock
> monotonic. systemd-timesyncd.service will complete initialization only
> after bumping the system clock according to that timestamp
> file. Enabling this service hence won't cause much boot-time delay,
> but at best gives you monotonic time, and only in late boot (since
> /var/ needs to be mounted first).
> 
> OTOH systemd-time-wait-sync.service is ordered before
> time-sync.target. This service blocks until an initial NTP sync is
> acquired over the nwtrok. Enabling this will cause boot-time delay,
> since we need to wait for an external networked time source to become
> available across the network, but it gives you pretty correct time.
> 
>> In addition, the fact the device appear probably doesn't necessarily
>> mean the time was set already?
> 
> if the kernel includes the aforementioned commit then yes, this means
> the time was set already, since the kernel's rtc_hctosys() call is
> invoked by the time the uevent notification is emitted.
> 
>>> But really, just figure out what your hw is and link the driver into
>>> the kernel. It saves you a lot of headaches, and kernel timestamps
>>> won't be crap initially.
>>
>> But kernel sets time at late boot anyway. So aren't they crap before it?
>> Like I don't understand something about the mechanism.
> 
> Well, the nice thing with the kernel's own time syncing logic is that
> it is applied immediately when the rtc shows up and has been
> probed. There are no extra delays. So yes, if your RTC is super slow
> to probe, then yeah a good number of early boot timestamps will still
> be crap, and in the worst case time-set.target will catch this and be
> delayed for the time necessary to make the timestamps accurate. But if
> the RTC is quick to be probed then you get correct timestamps as early
> as possible.
> 
> Lennart
> 
> --
> Lennart Poettering, Berlin
> 



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

Re: [systemd-devel] use RTC date/time to set system date time

[Michał Zegan]

W dniu 01.03.2021 o 17:19, Lennart Poettering pisze:
> On Mo, 01.03.21 17:09, Michał Zegan (webczat_...@poczta.onet.pl) wrote:
> 
>>>> There are problems with log timestamps when you do that, and it is
>>>> probably why it was not done.
>>>> I am wondering if the only correct way isn't to do it in initramfs (if
>>>> it's systemd) before starting the journald, so that first saved logs
>>>> have correct timestamps?
>>>
>>> The earlier you have a "correct" clock the better.
>>>
>>> But I mean, journald won't lie to you: the log messages are associated
>>> with the timestamps that were accurate at the moment they are
>>> generated. But of course, if your clock sucks then they'll look
>>> differently than you might expect.
>> However the initial log entries in journald are taken from dmesg and
>> dmesg timestamps are relative, so setting the clock before journald
>> first starts should make journal times correct.
>> Or I am wrong?
> 
> kmsg comes with monotonic timestamps only. journald stores that away
> but generally uses its own acquired timestamps, since it needs to
> guarantee monotonicity and things.
> 
> But do note that journald typically runs in the initrd already.
Yes, my idea was to wait for time *in initramfs* before journald. Like
force the rtc driver to land in initramfs, then just load it, set time
if kernel doesn't, and then start journald.
> 
> Lennart
> 
> --
> Lennart Poettering, Berlin
> 



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

Re: [systemd-devel] use RTC date/time to set system date time

[Michał Zegan]

W dniu 01.03.2021 o 16:59, Lennart Poettering pisze:
> On Mo, 01.03.21 14:52, Michał Zegan (webczat_...@poczta.onet.pl) wrote:
> 
>> Someone should really find a way to make it cooperate well with modular
>> rtcs.
>> It's popping up over and over and over and over again and no one is/will
>> build all rtc drivers into the kernel.
> 
> To my knowledge the kernel these days can also sync from the RTC if
> the RTC is loaded as module, as long as the device is named "rtc0".
> 
> But this stuff is racy of course if the RTC is compiled as module and
> you care for generic hw, that might or might not have an RTC: we
> cannot gues swhether an RTC will show up or not in that case,
> i.e. whether there is an RTC connected and whether there's a driver
> for it. Hence we time-{set|sync}.target cannot possibly wait for it to
> show up since it might mean we have to wait indefinitely...
I actually think kernel doesn't set on module load, and if it does, it's
very recent. How recent would it be? What kernel?
> 
> My recommendation: if you have embedded hw you should kow your hw,
> hence compile it in. Time is such a basic concept, it's something that
> should just work, and not require userspace interference to work.
Well, note that things like rpi are user facing embedded hardware and
from what I remember they don't have any builtin rtc drivers. Same for
odroid c2/etc.
For odroid they sell an rtc, and it's a different thing if you just need
to enable rtc in device tree, different if you need to build the kernel
just to have it correct.
Just changingdevice tree then doing some userspace config is easier.
Maybe vendors should build rtc drivers in, but they don't and if there
is no builtin rtc in something, like rpi, you have to rebuild the kernel
instead of just early module load for example, etc.
> 
> If you really don't want to compile it in, and love the extra
> headaches this involves, then make sure you run a recent kernel that
> can sync the system clock to RTC even when the module is loaded
> later. And then manually add an ordering dep to time-set.target to
> wait for /dev/rtc0, since that is the target that should be delayed
> until the RTC shows up and is probed:
What is normally attached to this target? In addition, the fact the
device appear probably doesn't necessarily mean the time was set already?
> 
> mkdir -p /etc/systemd/system/time-set.target.d
> cat > /etc/systemd/system/time-set.target.d/wait-for-rtc0.conf < [Unit]
> Wants=dev-rtc0.device
> After=dev-rtc0.device
> EOF
> 
> And:
> 
> mkdir -p /etc/udev/rules.d/
> cat > /etc/udev/rules.d/70-rtc-systemd.rules < ACTION!="remove",SUBSYSTEM=="rtc",TAG+="systemd"
> EOF
> 
> i.e. the latter makes sure there are .device units for your /dev/rtc
> devices, the former then tells time-set.target to wait for it to show
> up.
> 
> (both untested, ymmv)
> 
> And yes, you need to do this manually on your system. We cannot
> possibly know whether it's worth waiting for an RTC or not,
> generically.
> 
> But really, just figure out what your hw is and link the driver into
> the kernel. It saves you a lot of headaches, and kernel timestamps
> won't be crap initially.
But kernel sets time at late boot anyway. So aren't they crap before it?
Like I don't understand something about the mechanism.
> 
> Lennart
> 
> --
> Lennart Poettering, Berlin
> 



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

Re: [systemd-devel] use RTC date/time to set system date time

[Michał Zegan]

W dniu 01.03.2021 o 17:01, Lennart Poettering pisze:
> On Mo, 01.03.21 15:38, Michał Zegan (webczat_...@poczta.onet.pl) wrote:
> 
>> There are problems with log timestamps when you do that, and it is
>> probably why it was not done.
>> I am wondering if the only correct way isn't to do it in initramfs (if
>> it's systemd) before starting the journald, so that first saved logs
>> have correct timestamps?
> 
> The earlier you have a "correct" clock the better.
> 
> But I mean, journald won't lie to you: the log messages are associated
> with the timestamps that were accurate at the moment they are
> generated. But of course, if your clock sucks then they'll look
> differently than you might expect.
However the initial log entries in journald are taken from dmesg and
dmesg timestamps are relative, so setting the clock before journald
first starts should make journal times correct.
Or I am wrong?
> 
> Lennart
> 
> --
> Lennart Poettering, Berlin
> 



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

Re: [systemd-devel] use RTC date/time to set system date time

[Michał Zegan]

There are problems with log timestamps when you do that, and it is
probably why it was not done.
I am wondering if the only correct way isn't to do it in initramfs (if
it's systemd) before starting the journald, so that first saved logs
have correct timestamps?

W dniu 01.03.2021 o 15:28, Kevin P. Fleming pisze:
> It's fairly simple to add a one-shot service unit to use 'hwclock' to
> read from the RTC and set the kernel's real-time clock. I do this on
> my RPis which use modules for their RTCs.
> 
> On Mon, Mar 1, 2021 at 9:02 AM Michał Zegan  
> wrote:
>>
>> Someone should really find a way to make it cooperate well with modular
>> rtcs.
>> It's popping up over and over and over and over again and no one is/will
>> build all rtc drivers into the kernel.
>>
>> W dniu 01.03.2021 o 13:04, Mantas Mikulėnas pisze:
>>> Normally I think systemd expects the kernel to do this on its own.
>>>
>>> On Mon, Mar 1, 2021, 12:31 Belisko Marek >> <mailto:marek.beli...@gmail.com>> wrote:
>>>
>>> Hi,
>>>
>>> I have a case when a board boots without network connection but RTC
>>> have the correct date/time. Does systemd use RTC date/time to set
>>> systemd time or it needs to be done manually?
>>>
>>> Thanks and regards,
>>>
>>> marek
>>>
>>> --
>>> as simple and primitive as possible
>>> -
>>> Marek Belisko - OPEN-NANDRA
>>> Freelance Developer
>>>
>>> Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
>>> Tel: +421 915 052 184
>>> skype: marekwhite
>>> twitter: #opennandra
>>> web: http://open-nandra.com <http://open-nandra.com>
>>> ___
>>> systemd-devel mailing list
>>> systemd-devel@lists.freedesktop.org
>>> <mailto:systemd-devel@lists.freedesktop.org>
>>> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
>>> <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
>>>
>>
>> ___
>> systemd-devel mailing list
>> systemd-devel@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/systemd-devel



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

Re: [systemd-devel] use RTC date/time to set system date time

[Michał Zegan]

Someone should really find a way to make it cooperate well with modular
rtcs.
It's popping up over and over and over and over again and no one is/will
build all rtc drivers into the kernel.

W dniu 01.03.2021 o 13:04, Mantas Mikulėnas pisze:
> Normally I think systemd expects the kernel to do this on its own.
> 
> On Mon, Mar 1, 2021, 12:31 Belisko Marek  > wrote:
> 
> Hi,
> 
> I have a case when a board boots without network connection but RTC
> have the correct date/time. Does systemd use RTC date/time to set
> systemd time or it needs to be done manually?
> 
> Thanks and regards,
> 
> marek
> 
> -- 
> as simple and primitive as possible
> -
> Marek Belisko - OPEN-NANDRA
> Freelance Developer
> 
> Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
> Tel: +421 915 052 184
> skype: marekwhite
> twitter: #opennandra
> web: http://open-nandra.com 
> ___
> 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
> 



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

Re: [systemd-devel] Starting a socket unit that finds an active service fails

[Michał Zegan]

For me it is pretty logical, as in: the service started in relation to
socket unit gets the respective socket.
If service is already started there is no way to pass additional socket
to it without restarting it.
It may even listen exactly on the socket specified, just creating it on
it's own.

W dniu 29.01.2021 o 12:30, Ulrich Windl pisze:
> Hi!
> 
> I wonder whether this is a bug:
> When starting a socket unit that finds ist service active already, I get an 
> error
> systemd[1]: libvirtd-tls.socket: Socket service libvirtd.service already 
> active, refusing.
> systemd[1]: Failed to listen on Libvirt TLS IP socket.
> 
> When using systemd units in a pacemaker cluster this is fatal:
> pacemaker-controld[7467]:  notice: Transition 316 action 81 
> (prm_libvirtd-tls-sock_start_0 on rksaph19): expected 'ok' but got 'error'
> 
> Maybe the special problem is that two socket units (libvirtd-ro.socket, 
> libvirtd-tls.socket) exist to start the same service (libvirtd.service).
> 
> I'm clueless how to handle that. Ideas?
> 
> Regards,
> Ulrich
> 
> 
> 
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
> 



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

Re: [systemd-devel] btrfs raid not ready but systemd tries to mount it anyway

[Michał Zegan]

As a workaround I am almost sure you can instruct dracut to include the
file, can't you?

W dniu 16.10.2020 o 17:45, Lennart Poettering pisze:
> On Fr, 16.10.20 16:26, Daniel J. R. May (daniel@danieljrmay.com) wrote:
> 
>> On Fri, 2020-10-16 at 15:16 +0200, Lennart Poettering wrote:
>>> So the btrfs ready ioctl is called and the device considered by the
>>> kernel btrfs implementation  to be ready
>>> (i.e. assembled from all component devices) with this line:
>>>
>>> [   27.804250] systemd-udevd[712]: sde: 
>>> /usr/lib/udev/rules.d/64-btrfs.rules:15 RUN '/usr/bin/udevadm trigger -s 
>>> block -p ID_BTRFS_READY=0'
>>>
>>> (that's line 35792)
>>>
>>> And srv.mount then later mounts the thing correctly.
>>>
>>> Where's the problem supposed to be be?
>>>
>> I will try and summarise the situation in one message to help make
>> things clear. Here is a summarised history of the problem:
>>
>> 1. The original problem:
>> A 10 HDD BTRFS volume with 4 drives connected to the motherboard and 6
>> drives connected to the HBA *fails* to mount automatically at boot time.
>> The log for this (without any special debugging options set in grub) is
>> here:
>>
>> https://drive.google.com/file/d/1o1-7smQAjg3LKP98EFfeHbb_jZdNz_jT/view?usp=sharing
>>
>> 2. Debugging with "rd.udev.debug systemd.log_level=debug":
>> The same 10 HDD BTRFS volume with 4 drives connected to the motherboard
>> and 6 drives connected to the HBA *fails* to mount automatically at boot
>> time. The log for this with "rd.udev.debug systemd.log_level=debug" set
>> in grub is here:
>>
>> https://drive.google.com/file/d/1jVHjAQ8CY9vABtM2giPTB6XeZCclm7R-/view?usp=sharing
> 
> Ths btrfs udev rule file appears to be missing in the initrd. The
> block devices with the btrfs file systems on them will thus be marked
> ready in systemd instantly instead of being delayed until all other
> devices of the same btrfs fs have shown up in udev too.
> 
> Fix your initrd.
> 
> Lennart
> 
> --
> Lennart Poettering, Berlin
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
> 



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

Re: [systemd-devel] vt220 default for serial console still relevant?

[Michał Zegan]

Note there is an easy way to override term type.
The default serial-getty@.service at least here has no TERM set by
default, but uses it to set term type when launching getty.
You can use kernel command line and add TERM=screen for example, or
things like that, and it should be picked up, shouldn't it?
W dniu 15.07.2020 o 00:44, Christopher Cox pisze:
> On 7/14/20 4:27 PM, Mantas Mikulėnas wrote:
>> On Tue, Jul 14, 2020 at 9:48 PM Daan De Meyer
>> mailto:daan.j.deme...@gmail.com>> wrote:
>>
>>     I just tried vt241 and didn't get colorized output in konsole. I
>> looked
>>     around a bit and it doesn't really seem supported at all by terminal
>>     emulators (or at least none that I found). I also tried
>> TERM=xterm-256color
>>     with 8 different terminal emulators and got colors with all of
>> them. My
>>     workflow is simply "mkosi qemu -nographic" (with a modified mkosi
>> that adds
>>     console=ttyS0 and overrides TERM for serial-getty@ttyS0 in the
>> vm)." That
>>     connects my terminal emulator to the serial console of the vm. I then
>>     execute "ls -l --color /" in the vm and get colored output every
>> time in
>>     whatever terminal emulator that I try.
>>
>>     I'm probably missing something but I'm wondering what an example
>> terminal
>>     emulator would be where xterm-256color would not work at all (even
>> st worked
>>     perfectly and that is supposed to be pretty barebones afaik). Or
>> is it just
>>     that color is a commonly supported subset of xterm and stuff
>> breaks down
>>     with other escape codes instead? Or maybe qemu is doing some kind of
>>     translation that magically makes every TERM setting work in whatever
>>     terminal emulator I try? Apologies if this seems ignorant, I have no
>>     experience at all with this domain.
>>
>>
>> The basic formatting codes (bold, reverse, 8/16-color) are practically
>> the same everywhere. In fact they're so widespread that many programs
>> and scripts just straight up hardcode them. (xterm, st, etc. are
>> supersets of vt220/vt421 in that regard.)
>>
>> But 256-color or even 24-bit-color codes are not as widely supported.
>> The Linux VT has only recently started *recognizing* them (though
>> still maps them down to 8 colors). If you use TERM=xterm-256color with
>> Linux VT, apps can look really weird because you told them they can
>> use these extended color codes even though they cannot.
>>
>> Graphical terminal emulators recognize the "update status line" codes
>> (which goes the X11 window titlebar) -- but the Linux VT has no such
>> thing and the same code will just show up as garbage on screen.
>>
>> Google tells me VT421 supported sixel graphics. I'm not sure if any
>> programs make use of that nowadays, but if they do, then trying to use
>> TERM=vt421 with a terminal that doesn't do sixel will result in more
>> garbage on screen.
>>
>> There are various other differences like this.
> 
> Boot up logs should target "dumb" terminal only.
> 
> So, in the case of boot logs (where we have no idea where messages are
> going), if you want "color", I'd use some kind of markup and allow to be
> interpreted by whatever is viewing that.
> 
> But with regards to logs presumably going to a terminal (real or virtual
> or whatever), I'd lean on terminfo and end user selection (which could
> be by TERM in the case of an established terminal).
> 
> And of course, if it's ok for Dell/HP/IBM to assume Hyperterminal (ansi,
> 80x25) for BIOS setup,etc via serial, maybe it's not too far a stretch
> for Linux to assume something.  But IMHO, if at all possible, I'd make
> this configurable and again, lean on terminfo.
> 
> Personally I like log data that is parseable.  And data with a gazillion
> escape sequences is very noisy to look at.  Perhaps another reason for
> some sort of simple markup instead of escape sequences (?).  Hey, our
> developers are constantly hard coding ansi-escapes into their log
> messages so they look "pretty" in very very specific viewers.  Not the
> way I'd handle it.
> 
> 
> 
> 
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel



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

Re: [systemd-devel] howto switch from grub2-bios to systemd-boot

[Michał Zegan]

The thing that loads kernel and initramfs must itself be able to read
the fs, and systemd-boot delegates to uefi for that.
So things should be in ESP or you should use grub2 on uefi too and have
the grub image itself on ESP only.
Not sure about the current required partition structure I.E. where ESP
would then be mounted, though. If you have a gpt with biosboot then you
should be able to leave all grub files intact as even uefi-compatible
grub modules are in a separate directory from what I remember. although
I may be wrong at that last point because I was not using grub for some
time.

W dniu 22.06.2020 o 16:01, Reindl Harald pisze:
> what is the best way to get a Fedora using legacy-boot to UEFI and at
> the same time switch from grub2 to systemd-boot?
> 
> * how to get in installed from a live-iso to
>   the existing setup on disk
> * how to get the config files right at the first try
> * how does it work with kernel-updates
> * how to get GRUB_CMDLINE_LINUX over
> * is it possible to not kill grub2 for the time beeing
>   to boot back into BIOS-mode in case of emergency
> 
> can /boot holding the kernel itself still be a Linux RAID1 or classical
> ext4 partition or is it required that the kernel and initrd live on the
> EFI partition too?
> 
> how to get the mounts right?
> how to get the files to the correct locations?
> 
> ---
> 
> the "EFI system partition" is prepared, in that case as partition on the
> first vdisk (VMware)
> 
> in the future i need to replace my physical machines where i don't wont
> do touch the RAID1/RAID10 holding systemd and data dating back to 2011
> and in that case i consider to use a usb-drive for the EFI partition
> 
> so this is more or less a testballon for the production servers given
> that ove time i would like to switch completly to systemd-boot
> 
> ---
> 
> everything i found is talking about "you have already bootet in UEFI
> mode" which makes it a little hard especially when it comes to dnf
> operations
> 
> https://kowalski7cc.xyz/blog/systemd-boot-fedora-32/
> 
> what i don't like here at all is this (besides sudo):
> sudo dnf remove grubby grub2\* shim\* memtest86\ && sudo rm -rf
> /boot/grub2 && sudo rm -rf /boot/loader
> 
> ---
> 
> [root@testserver:~]$ df
> Filesystem Type  Size  Used Avail Use% Mounted on
> /dev/sdb1  ext4   12G  6.3G  5.4G  54% /
> /dev/sda3  ext4  376M   43M  310M  12% /boot
> /dev/sda1  vfat  100M 0  100M   0% /boot/efi
> /dev/md0   ext4  1.9G  3.0M  1.9G   1% /mnt/raid10
> 
> ---
> 
> Number  Start (sector)End (sector)  Size   Code  Name
>12048  206847   100.0 MiB   EF00  EFI system
> partition
>2  206848  227327   10.0 MiBEF02  BIOS boot partition
>3  227328 1048542   401.0 MiB   8300  Linux filesystem
> 
> ---
> 
> that was the steps to prepare the partitioning and re-install grub2 for
> now on the new layout which could be dd'ed to dozenzs of identical
> machines with one step
> 
> * rsync.sh /boot/ /data/boot/
> * umount /boot/
> * dd if=/dev/zero of=/dev/sda
> * partprobe /dev/sda
> * gdisk /dev/sda
> * o
> * n
> * end at +100M
> * type: EF00 (EFI-System)
> * n (Neue Partition erzeugen)
> * end at +10M
> * type: ef02 (BIOS boot partition)
> * n (Neue Partition erzeugen)
> + accept defaults
> * w
> * partprobe /dev/sda
> * mkfs.vfat /dev/sda1
> * mkfs.ext4 -I 256 -O ^has_journal /dev/sda3
> * e2label /dev/sda3 boot
> * UUID der bootdisk in /etc/fstab aktualisieren
> * systemctl daemon-reexec
> * mount /dev/sdb3 /boot/
> * rsync.sh /data/boot/ /boot/
> * grub2-install /dev/sda
> 
> ---
> 
> [root@testserver:~]$ cat /etc/default/grub
> GRUB_TIMEOUT=2
> GRUB_DISTRIBUTOR="Fedora"
> GRUB_SAVEDEFAULT="false"
> GRUB_TERMINAL_OUTPUT="console"
> GRUB_GFXPAYLOAD_LINUX="text"
> GRUB_CMDLINE_LINUX="quiet transparent_hugepage=never edd=off
> hpet=disable audit=0 rd.plymouth=0 plymouth.enable=0 zswap.enabled=0
> nodmraid raid=noautodetect nomodeset selinux=0 net.ifnames=0
> biosdevname=0 noswapaccount nousb usbcore.nousb noisapnp noresume
> hibernate=no kaslr thermal.off=1 nmi_watchdog=0 consoleblank=0 rd.luks=0
> rd.lvm=0 rd.md=0 rd.dm=0 vconsole.font=latarcyrheb-sun16
> vconsole.keymap=de-latin1-nodeadkeys locale.LANG=C.UTF-8"
> GRUB_DISABLE_RECOVERY="true"
> GRUB_DISABLE_SUBMENU="true"
> GRUB_DISABLE_OS_PROBER="true"
> GRUB_ENABLE_BLSCFG="false"
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
> 



signature.asc
Description: OpenPGP digital signature
___
systemd-de

Re: [systemd-devel] : How to modify systemd so that the NTP function is disabled when systemd is first started?

[Michał Zegan]

As I said, there are symlinks in /etc/systemd/system/*.target.wants that
allows disabling services like this one from starting. It is enough to
remove the one for systemd-timesync.service from multi-user.target.wants
directory. If you can do things via some config files you should also be
able to do this

W dniu 23.04.2020 o 04:14, www pisze:
> 
> hi Michal and Kevin,
> 
> We applied systemd to embedded Linux, so we often need to update/flash
> the whole system.  When we select disable *time synchronization*
> function, the embedded system will use the time itself. After we update
> the system and restart it, we need the *time synchronization* function
> is disabled. During the whole startup process, there is no automatic
> time synchronization, and *the previous time is used*. Because automatic
> time synchronization may change its original time. （*Because the time
> of the system itself may be different from that of NTP time.*） 
> 
> There is a *timesyncd.conf* file under the system，can the system
> automatically turn off the time synchronization function by modifying
> this file? 
> In this way, when updating, I can save this file to solve this problem.
> 
> 
> thanks,
> Byron
> 
> 
> 
> 
> At 2020-04-17 19:44:48, "Michał Zegan"  wrote:
>>I am not quite sure what you mean, but... generally these are symlinks
>>in /etc/systemd/system/multi-user.target.wants/ so you could delete them
>>manually if your intention is to make the actual os image with this
>>disabled from the start...
>>
>>W dniu 17.04.2020 o 12:10, www pisze:
>>> 
>>> I mean that this configuration can be preserved, even after I update the
>>> system, this function can be saved.
>>> 
>>> thanks，
>>> Byron
>>> 
>>> 
>>> 
>>> 
>>> At 2020-04-17 18:06:15, "Kevin P. Fleming"  wrote:
>>>>Both of those changes will stop the service from being started, even
>>>>when the system is rebooted. You don't need to run these commands
>>>>every time, running them one time will change the system configuration
>>>>and the service will no longer be started.
>>>>
>>>>On Fri, Apr 17, 2020 at 2:52 AM www  wrote:
>>>>>
>>>>> hi Kevin ,
>>>>>
>>>>> Thank you very much for you help. But how can I save this way of closing 
>>>>> time synchronization by command after system boot up? After I update the 
>>>>> system, the first time I start it, time synchronization is still enabled 
>>>>> by default. It's not appropriate if I close it alone every time. So when 
>>>>> I need it start every time, this function is off.
>>>>>
>>>>>
>>>>> thanks,
>>>>> Byron
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> At 2020-04-16 18:28:30, "Kevin P. Fleming"  wrote:
>>>>> >There is no need to modify systemd.
>>>>> >
>>>>> >$ systemctl disable systemd-timesyncd
>>>>> >
>>>>> >That command will stop the systemd-timesyncd service from being
>>>>> >started. It may also be necessary to mask it:
>>>>> >
>>>>> >$ systemctl mask systemd-timesyncd
>>>>> >
>>>>> >On Thu, Apr 16, 2020 at 6:22 AM www  wrote:
>>>>> >>
>>>>> >> Dear all，
>>>>> >>
>>>>> >> I want to ask a question，How to modify systemd so that the NTP 
>>>>> >> function is disabled when systemd is first started?
>>>>> >>
>>>>> >>  The default state of systend is to synchronize time from NTP. We can 
>>>>> >> use timedatectl command to disable NTP synchronize time. But if I 
>>>>> >> flash the system, the NTP  synchronize time function will auto enable. 
>>>>> >>  so I want modify the systemd and disable NTP synchronize time in 
>>>>> >> default state.
>>>>> >>
>>>>> >> thanks,
>>>>> >> Byron
>>>>> >>
>>>>> >>
>>>>> >>
>>>>> >>
>>>>> >> ___
>>>>> >> 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
>>> 
>>
> 
> 
> 
>  
> 



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

Re: [systemd-devel] ^] 3 times which key is it

[Michał Zegan]

^ often stands for ctrl, so this is ctrl+]

W dniu 20.04.2020 o 17:30, Damian Ivanov pisze:
> Hello!
> 
> Please enlighten me: which key is ^]
> 
> Br,
> Damian
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
> 



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

Re: [systemd-devel] : How to modify systemd so that the NTP function is disabled when systemd is first started?

[Michał Zegan]

I am not quite sure what you mean, but... generally these are symlinks
in /etc/systemd/system/multi-user.target.wants/ so you could delete them
manually if your intention is to make the actual os image with this
disabled from the start...

W dniu 17.04.2020 o 12:10, www pisze:
> 
> I mean that this configuration can be preserved, even after I update the
> system, this function can be saved.
> 
> thanks，
> Byron
> 
> 
> 
> 
> At 2020-04-17 18:06:15, "Kevin P. Fleming"  wrote:
>>Both of those changes will stop the service from being started, even
>>when the system is rebooted. You don't need to run these commands
>>every time, running them one time will change the system configuration
>>and the service will no longer be started.
>>
>>On Fri, Apr 17, 2020 at 2:52 AM www  wrote:
>>>
>>> hi Kevin ,
>>>
>>> Thank you very much for you help. But how can I save this way of closing 
>>> time synchronization by command after system boot up? After I update the 
>>> system, the first time I start it, time synchronization is still enabled by 
>>> default. It's not appropriate if I close it alone every time. So when I 
>>> need it start every time, this function is off.
>>>
>>>
>>> thanks,
>>> Byron
>>>
>>>
>>>
>>>
>>>
>>> At 2020-04-16 18:28:30, "Kevin P. Fleming"  wrote:
>>> >There is no need to modify systemd.
>>> >
>>> >$ systemctl disable systemd-timesyncd
>>> >
>>> >That command will stop the systemd-timesyncd service from being
>>> >started. It may also be necessary to mask it:
>>> >
>>> >$ systemctl mask systemd-timesyncd
>>> >
>>> >On Thu, Apr 16, 2020 at 6:22 AM www  wrote:
>>> >>
>>> >> Dear all，
>>> >>
>>> >> I want to ask a question，How to modify systemd so that the NTP function 
>>> >> is disabled when systemd is first started?
>>> >>
>>> >>  The default state of systend is to synchronize time from NTP. We can 
>>> >> use timedatectl command to disable NTP synchronize time. But if I flash 
>>> >> the system, the NTP  synchronize time function will auto enable.  so I 
>>> >> want modify the systemd and disable NTP synchronize time in default 
>>> >> state.
>>> >>
>>> >> thanks,
>>> >> Byron
>>> >>
>>> >>
>>> >>
>>> >>
>>> >> ___
>>> >> 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
> 



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

Re: [systemd-devel] The meaning of CanMultiSession=no on non-seat0

[Michał Zegan]

W dniu 09.04.2020 o 10:23, Pekka Paalanen pisze:
> On Thu, 9 Apr 2020 09:46:08 +0200
> Lennart Poettering  wrote:
> 
>> On Fr, 03.04.20 10:28, Pekka Paalanen (ppaala...@gmail.com) wrote:
>>
 My (maybe bad) guess is that it would need to be addressed in the kernel 
 though
 And the CanMultiSession attribute on non-seat0 doesn't matter when the 
 problem
 is all input from all devices gets sent to seat0 when seat0 is in a text 
 mode
 TTY

 ..and even if you have some kmscon like thing installed, there could still 
 be
 text mode TTYs  
>>>
>>> Hi,
>>>
>>> that is both an excellent and horrifying observation. And it makes
>>> perfect sense to me why that happens, just like you think: seat
>>> assignments happen in userspace as udev properties. Someone would have
>>> to explicitly tell the kernel about it too to fix this, e.g. remove
>>> non-seat0 devices from the VT machinery.
>>>
>>> I wonder if such kernel interface even exists?  
>>
>> There are ioctls for that in the input layer if iirc, but i don't
>> remember how precisely this works. You are hacking on a compositor, you
>> should know ;-)
> 
> Hi,
> 
> while hacking on a compositor, I have never needed to stop specific
> input devices from being routed to the VT system while allowing others.
> If a compositor runs on seat0, it will disable the whole VT input side
> (among other things) with one VT ioctl IIRC. In this case that is not
> wanted, because seat0 is intended to be used with the VT text mode and
> VT input, so disabling all VT input would stop also the wanted input.
Not sure if it's related and I don't know details, but some software
like brltty or a fenrir console screenreader are routinely taking
control over single input devices in text mode. The whole point is that
they take control over all real keyboards, and have some uinput device
that is still wired to vt, so that I can send keypresses not supported
by terminals like insert+something, and these that do not map to
screenreader would be injected to the uinput and appear on vt.
I thought display servers also take exclusive control over specific
input devices... hmm. If they do then this behavior should likely not be
happening as they still are in control of the devices.
> 
> Also a display server that runs on non-seat0 seat should never touch
> anything about VTs AFAIU. I would expect it to not have the permissions
> to do that even if it wanted to.
> 
> Like you said it being a kernel or logind bug, this is something that
> needs to be taken care of below the compositor, automatically keyed by
> the input device seat assignments.
> 
> 
> Thanks,
> pq
> 
> 
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
> 



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

Re: [systemd-devel] your are happier but without become static some service I can't loggin by console-getty et getty@tty1 services

[Michał Zegan]

W dniu 08.04.2020 o 00:44, juice pisze:
> Dorian ROSSE kirjoitti 2020-04-08 01:37:
>> Sorry I was say an error
>>
>>  I can't start them they happen crash
>>
> 
> Normally the getty@ttyX.services are off and are automatically started
> when you start a session on a VT.
tty1 is usually explicitly enabled, but othervise true.
> 
> Do you get anything relevant on journal?
> 
>   - juice -
> 
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel



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

Re: [systemd-devel] your are happier but without become static some service I can't loggin by console-getty et getty@tty1 services

[Michał Zegan]

W dniu 08.04.2020 o 00:03, Dorian ROSSE pisze:
> I explain again the problem juice
> 
> I can't use my monitor foe edit script
> 
> Because console-getty et getty@tty1 service are disabled, 
> 
> I can start but I want both service become static, 
> 
> How to become both service as static ? 
Oh, I probably get it now.
console-getty is for getty at /dev/console and I believe you should not
do this...
You can type systemctl enable getty@tty1.service if for some reason it
is disabled. It is not intended to be static.
> 
> Envoyé d’Outlook Mobile 
> 
> *From:* Dorian ROSSE
> *Sent:* Tuesday, April 7, 2020 7:47:53 PM
> *To:* systemd-devel@lists.freedesktop.org
> 
> *Subject:* your are happier but without become static some service I
> can't loggin by console-getty et getty@tty1 services
>  
> Hello,
> 
> 
> your are happier but without become static some service I can't loggin
> by console-getty et getty@tty1 services on my monitor...
> 
> I have tried too ssh access but ssh mailing list has never answer my
> e-mail...
> 
> thank you in advance to help me become static some services,
> 
> Regards.
> 
> 
> Dorian ROSSE.
> 
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
> 



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

Re: [systemd-devel] your are happier but without become static some service I can't loggin by console-getty et getty@tty1 services

[Michał Zegan]

1. I am probably not a right person to say this, but please calm down,
because that way of discussing does not make sense.
2. The problem is that we literally do not understand what you are
saying. You ask for help about problems but at least I cannot (not at
all) decipher what is the question.

W dniu 07.04.2020 o 22:21, Dorian ROSSE pisze:
> As I was say stop to talk with me
> 
> I am not on systemd mailing list for hear you
> 
> I am on for discuss between linux happier dev worker
> 
> You spend time for talk 
> 
> But I want hear a worker, 
> 
> I know there is a coredump mailing list but when I was publish there is
> some year I have never receive any answer
> 
> Systemd need take back the coredump dev 
> 
> I feel like this you talk for nothing... 
> 
> Lol
> 
> Envoyé d’Outlook Mobile 
> 
> *From:* Reindl Harald 
> *Sent:* Tuesday, April 7, 2020 10:10:57 PM
> *To:* Dorian ROSSE 
> *Subject:* Re: [systemd-devel] your are happier but without become
> static some service I can't loggin by console-getty et getty@tty1 services
>  
> 
> 
> Am 07.04.20 um 22:08 schrieb Dorian ROSSE:
>> I am not a systemd worker
>> 
>> I am more a snort worker
> 
> you are an idiot provebale by read you shit opver 3 years, not more and
> not less, creep away
> 
>> Envoyé d’Outlook Mobile 
>> 
>> *From:* systemd-devel  on
>> behalf of Reindl Harald 
>> *Sent:* Tuesday, April 7, 2020 9:56:06 PM
>> *To:* systemd-devel@lists.freedesktop.org
>> 
>> *Subject:* Re: [systemd-devel] your are happier but without become
>> static some service I can't loggin by console-getty et getty@tty1 services
>>  
>> 
>> 
>> Am 07.04.20 um 21:53 schrieb Dorian ROSSE:
>>> I am don't know why I keep talk to you, 
>>> 
>>> You aren't stop to speak, 
>>> 
>>> But when I need help you are are lazy person on the list
>> 
>> to get help you need to distinct between a problem and your imagination
>> and learn to express your imaginary problems in a way that another human
>> can understand what you are talking about, unless now any of your posts
>> is just noise for years
>> 
>> if you want coredumps seek for a broken application
> 
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
> 



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

Re: [systemd-devel] reboot on emergency.target

[Michał Zegan]

Hi,
Curious what is the use case. For me emergency is used mostly when I run
the kernel with the emergency cmdline parameter or when something fails
and I have to debug it before everything else starts.

W dniu 07.04.2020 o 10:26, Matwey V. Kornilov pisze:
> Hi,
> 
> I would like my system to reboot (with some cool down timeout) on
> emergency.target instead of running the emergency shell. What would be
> the recommended way to achieve this behavior? Is it ok just to override
> default emergency.service to whatever I want?
> 
> ___
> 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] Cannot find a way to get time read from RTC during boot

[Michał Zegan]

I have used the embedded term unfortunately, but it seems to affect at
least some devices like raspberry pi, odroid c2, like sbc's.

W dniu 31.03.2020 o 17:57, Lennart Poettering pisze:
> On Di, 31.03.20 17:39, Michał Zegan (webczat_...@poczta.onet.pl) wrote:
> 
>> Seems like rtc drivers as module is quite often a thing for embedded.
>> But not sure where this should be solved, maybe at initramfs? If one is
>> unwilling to build all rtc drivers into the kernel (the case of generic
>> kernels where you would have to build all of them in)...
> 
> Is that realistic? embedded devices and fully generic kernels?
> 
> Lennart
> 
> --
> Lennart Poettering, Berlin
> 



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

Re: [systemd-devel] Cannot find a way to get time read from RTC during boot

[Michał Zegan]

Seems like rtc drivers as module is quite often a thing for embedded.
But not sure where this should be solved, maybe at initramfs? If one is
unwilling to build all rtc drivers into the kernel (the case of generic
kernels where you would have to build all of them in)...

W dniu 31.03.2020 o 16:29, Lennart Poettering pisze:
> On Do, 12.03.20 07:13, Kevin P. Fleming (ke...@km6g.us) wrote:
> 
>> I've got some Debian Buster systems (so using the Debian systemd
>> package 241-7), which have battery-backed RTCs. However the driver for
>> these RTCs is loaded as a module, not built into the kernel. As a
>> result the kernel's feature of reading the RTC to set the system clock
>> is not available.
> 
> We generally assume that RTC drivers are built-in and the kernel does
> the initial initialization of the system clock from it.
> 
>> Prior to systemd, with the 'hwclock' package installed, a udev rule
>> would trigger reading of the RTC and setting the system clock when
>> /dev/rtc0 appeared. With systemd running, the script run by that udev
>> rule is suppressed, it doesn't do anything.
> 
>> I have systemd-timesyncd started at boot as well and syncing time with
>> an NTP server; that works fine when the system clock is set to
>> something reasonably close to the actual time. If it's not, then
>> timesyncd can't adjust the time because it's too far off (and in
>> addition I have the issue reported on GitHub where systemd-resolved
>> can't resolve NTP server names due to DNSSEC failing because the clock
>> is too far off...) The file that systemd-timesyncd stores for use on
>> reboot helps a little, but if the system is shut off for a period of
>> time (an hour or more) then the time at startup is quite far off from
>> reality, which is why I have an RTC :)
> 
> Hmm, timesyncd should be able to fix the clock in any case regardless
> how far things are off? Not sure I follow?
> 
>> With a system using solely systemd-provided services, what's the
>> proper mechanism to get the time read from an RTC whose driver is
>> loaded by systemd-modules-load.service?
> 
> There's no such mechanism. We assume that the rtc0 driver is built
> into the kernel...
> 
> Lennart
> 
> --
> Lennart Poettering, Berlin
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
> 



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

Re: [systemd-devel] Antw: Re: Antw: Re: Binary changed since start

[Michał Zegan]

W dniu 11.12.2019 o 08:17, Ulrich Windl pisze:
 Michal Zegan  schrieb am 10.12.2019 um 17:53 in
> Nachricht :
> 
> [...]
>> Well. This specifically may be doable by checking if any file open by
>> process is marked deleted, but would not work if the file was just
>> rewritten...
> 
> Did you ever try to overwrite a dynmically loaded file? I doubt it is 
> possible for obvious reasons.
What happens when glibc is updated? :) at least here on arch
> 
> [...]
> 
> Regards,
> Ulrich
> 
> 
> 



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

Re: [systemd-devel] Antw: Re: Binary changed since start

[Michał Zegan]

W dniu 10.12.2019 o 15:12, Ulrich Windl pisze:
 Lennart Poettering  schrieb am 10.12.2019 um 12:32
> in
> Nachricht <20191210113234.GA16721@gardel-login>:
>> On Di, 10.12.19 10:38, Ulrich Windl (ulrich.wi...@rz.uni‑regensburg.de)
> wrote:
>>
>>> Hi!
>>>
>>> Two questions (In Linux it's possible to replace the image of the binary 
>> that is executed on disk):
>>>
>>> 1) It seems my version of systemd (228) does not detect that a
>>> binary has changed since the service was started. In case it's still
>>> true in the current version, is it difficult to indicate that fact
>>> in "systemctl status .."?
>>
>> We don't, no. It has been requested before that we deal with that, but
>> it's not realistic to do this correctly. Thing is, binaries are
> 
> Well at least "zypper ps" does that kind of things:
> # zypper ps
> The following running processes use deleted files:
> 
> PID   | PPID  | UID  | User   | Command| Service| Files
> --+---+--++++--
> 2502  | 1 | 0| root   | multipathd | multipathd |
> /lib64/libtinfo.so.5.9
> 2903  | 1 | 100  | messagebus | dbus-daemon| dbus   |
> /lib64/libnss_sss.so.2
> 2967  | 1 | 0| root   | mcelog | mcelog |
> /lib64/libnss_sss.so.2
> 3774  | 1 | 0| root   | xinetd | xinetd |
> /lib64/libnss_sss.so.2
> 3796  | 1 | 1086 | nagios | nrpe   | nrpe   |
> /lib64/libnss_sss.so.2
> 3973  | 1 | 0| root   | sshd   | sshd   |
> /lib64/libnss_sss.so.2
> 4060  | 1 | 0| root   | automount  | autofs |
> /usr/lib64/libxml2.so.2.9.4
> 4074  | 1 | 0| root   | snmpd  | snmpd  |
> /lib64/libnss_sss.so.2
> 4079  | 1 | 74   | ntp| ntpd   | ntpd   |
> /lib64/libnss_sss.so.2
> 4080  | 4079  | 74   | ntp| ntpd   | ntpd   |
> /lib64/libnss_sss.so.2
> 4082  | 1 | 25   | at | atd| atd|
> /lib64/libnss_sss.so.2
> 4166  | 1 | 0| root   | bash   | md-mon |
> /lib64/libtinfo.so.5.9
> ...
> 25512 | 1 | 0| root   | cupsd  | cups   |
> /lib64/libnss_sss.so.2
> 26053 | 3973  | 0| root   | sshd   ||
> /lib64/libnss_sss.so.2
> 26061 | 26053 | 0| root   | bash   ||
> /lib64/libnss_sss.so.2
> 
> # zypper ps -s
> The following running processes use deleted files:
> 
> PID   | PPID  | UID  | User   | Command| Service
> --+---+--+++---
> 2502  | 1 | 0| root   | multipathd | multipathd
> 2903  | 1 | 100  | messagebus | dbus-daemon| dbus
> 2967  | 1 | 0| root   | mcelog | mcelog
> 3774  | 1 | 0| root   | xinetd | xinetd
> 3796  | 1 | 1086 | nagios | nrpe   | nrpe
> 3973  | 1 | 0| root   | sshd   | sshd
> 4060  | 1 | 0| root   | automount  | autofs
> 4074  | 1 | 0| root   | snmpd  | snmpd
> ...
> 
Well. This specifically may be doable by checking if any file open by
process is marked deleted, but would not work if the file was just
rewritten...
>> generally not statically compiled, they link against other libraries
>> which might also be updated, and which would have to be checked
>> too. And they do so via module loading (i.e. dlopen()) and explicitly,
>> we'd have to check both, which already is harder, since you cannot
>> just look at the ELF headers of binaries to determine deps
>> anymore. But they also keep other resources mapped, for example l10n
>> and i18n data, and a lot of other stuff. We'd have to check that
>> too. And then, there are the invisible dependencies too: some file
>> changed that some library a program opens and reads, but only
>> sometimes: how would you ever figure out you need to restart the
>> service? And then, there's also the fact that C is just one
>> programming language and others work very differently, and require
>> other schemes for updating, i.e. Python does something very very
>> different.
>>
>> So in the end: implementing something like that could at best be a
>> heuristic, that works sometimes but not generally. I know that some
>> distros implemented a checker for this in their package manager. But I
>> am very sure this has no place in systemd, since it's black magic and
>> you never could rely on the correctness for that.
>>
>>> 2) Given 1), would it make sense to allow an option like
>>> "RestartIfBinary Changed"?
>>
>> Binding control flow to such a heuristic sounds even more dangerous to
>> me.
> 
> I was asking for an option, not for a default.
> 
> Regards,
> Ulrich
> 
> 
>>
>> Lennart
>>
>> ‑‑
>> Lennart Poettering, Berlin
> 
> 
> 
> _

Re: [systemd-devel] systemd startup

[Michał Zegan]

Note that if systemd is running in the initramfs too, then journal logs
from the current boot will contain initramfs logs too.

W dniu 22.11.2019 o 16:25, Mantas Mikulėnas pisze:
> On Fri, Nov 22, 2019 at 5:18 PM Boyce, Kevin P [US] (AS)
> mailto:kevin.bo...@ngc.com>> wrote:
> 
> Good Morning list,
> 
> __ __
> 
> Does anyone know if there is a way to print out as much of the
> startup ordering of all systemd units including what happens in the
> initramfs before the pivot_root happens?
> 
> __ __
> 
> I just want to be able to grep the output for two units I am
> interested in to know that one is indeed starting before the other. 
> I’ve looked at the systemd-analyze plot but this is a large svg file
> that is hard to parse.  Systemctl list-dependencies comes close, but
> is missing the initramfs.
> 
> 
> Initramfs and rootfs are two fully independent systemd environments, no
> matter which tool you use to inspect them. You can use `systemctl
> list-dependencies` from within the initramfs as well, if you boot with
> the "rd.break" kernel option which will provide an interactive shell in
> the initramfs environment before pivot happens.
> 
> Note that `systemd-analyze plot` accepts --from-pattern and --to-pattern
> to limit the units that will be shown.
> 
> -- 
> Mantas Mikulėnas
> 
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
> 



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

[systemd-devel] nspawn and ovs bridges

[Michał Zegan]

Hello,
My use case is the following: make a test of routing protocols without
having... enough real hardware. I decided to do that via containers
using systemd-nspawn, and because I may need many interconnected
networks and things like qos settings applied without dirty scripts, I
decided to try openvswitch for bridge management.
The problem here is that systemd-nspawn does not really support adding
the created veth interface to the ovs bridge, even for the so called
fake bridge, because it says "operation not supported". Same happens if
I try to do ip link set iface master fakebridge.
How to deal with that situation correctly? Any ideas?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] cannot unsubscribe from this list

[Michał Zegan]

W dniu 16.10.2019 o 16:26, Brian Reichert pisze:
> On Wed, Oct 16, 2019 at 07:43:10AM +, Zbigniew J??drzejewski-Szmek wrote:
>> On Tue, Oct 15, 2019 at 04:08:24PM -0400, Brian Reichert wrote:
>>> I initiated an unsubscribe from this web page:
>>>
>>>   https://lists.freedesktop.org/mailman/options/systemd-devel
>>>
>>> That created a confirmation email, that I replied to.
>>
>> Yeah, that doesn't work. Use the web interface:
>>> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
> 
> I just tried that second web interface.
> 
> The resulting confirmation email aLso bounces:
> 
>   :
>131.252.210.177 does not like recipient.
>   Remote host said: 550 5.1.1 :
>   Recipient address rejected: User unknown in local recipient table
>   Giving up on 131.252.210.177.
> 
> I can provide email headers, SMTP logs, etc., for either failing
> use case, if anyone thinks that would help.
See the contents of the confirmation email. You can confirm by replying
(that doesn't work as you stated), but there should be also a link that
allows you to confirm on a webpage. You can use it without problems,
probably
> 
>> Zbyszek
> 
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] journald vs auditd

[Michał Zegan]

Well, actually I would like a feature to filter out audit data when
looking at logs. I often do things like journalctl -o cat -f or
journalctl -o cat -b | less or something without targetting a single
unit or whatever, and in some cases I see a ton of those. I believe
there is no way to filter only audit messages but show the rest?

W dniu 25.11.2018 o 13:53, Lennart Poettering pisze:
> On Sa, 24.11.18 14:38, Michał Zegan (webczat_...@poczta.onet.pl) wrote:
> 
>> Hello,
>> Does journald intent to replace auditd?
> 
> Well, no.
> 
> I mean, there's some useful log data generated through the audit
> framework that is not available elsewhere, and I think it's useful do
> have this among the rest of the log data, hence we added support for
> collecting that data. However, journald cannot replace auditd in most
> ways, it will only register itself as an additional listener to audit
> messages but not as the userspace consumer of it, like auditd
> does. And that's on purpose: if you want the full auditd subsystem use
> auditd really. journald is just an additional consumer of the data,
> that is all, and it doesn't want to take full possession of the audit
> stream like auditd does.
> 
>> Because it has ability to get audit messages and uses it by default,
>> also turning on audit.  On the other hand, it does not silence dmesg
>> audit messages like auditd seems to do, why?
> 
> So, yeah, this sucks a bit. This is a kernel limitation. There has
> been some work on fixing this in the kernel, but it never was
> finished.  Right now the implemented logic in the kernel is that only
> if a userspace consumer of audit is running then the forward-to-kmsg
> logic in the kernel is turned off and additional listeners (such as
> journald) do not effect that logic. The idea of the unfinished work
> was that the kernel would be changed to turn off the forward-to-kmsg
> as soon as either a consumer is active or when at least one additional
> listener is active.
> 
> There's a rhbz bug about this, open since a long long time:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1160046
> 
> It's a pity this work went nowhere...
> 
> Lennart
> 



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

[systemd-devel] journald vs auditd

[Michał Zegan]

Hello,
Does journald intent to replace auditd? Because it has ability to get
audit messages and uses it by default, also turning on audit.
On the other hand, it does not silence dmesg audit messages like auditd
seems to do, why?



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

Re: [systemd-devel] Multiple initrds in unified kernel images?

[Michał Zegan]

I am not really sure if you are right and you can concatenate cpio
archives, just be ware! they may be compressed, and in this case you
would rather cat their uncompressed form... I think so at least.

W dniu 05.10.2018 o 09:10, David Anderson pisze:
> And of course, the law of asking questions on the internet is verified,
> and I find the answer minutes after asking a thousand people. A Linux
> initramfs is a concatenation of cpio archives, so I can just `cat
> microcode.img initrd.gz >initrd`, embed that in my unified image, and
> everything should just work.
> 
> Please let me know if I'm wrong, and otherwise - thanks for being my
> rubber ducks!
> 
> - Dave
> 
> On Fri, Oct 5, 2018 at 12:02 AM David Anderson  > wrote:
> 
> Hi,
> 
> I'm exploring systemd-boot and secure booting for an Arch Linux
> install. To get secure boot working right, I need to build a unified
> kernel image that I can sign. However, I also need to pass 2 initrd
> images into the boot process (one for CPU microcode, and the proper
> OS iniramfs).
> 
> But, AFAICT from reading the EFI stub source code, I can only have
> one ".initrd" section in my unified binary.
> 
> Is it possible to have multiple initrds in a unified kernel image?
> If so, how do I construct the unified image? If not, can you suggest
> an alternative that gets me my microcode and my OS initramfs?
> 
> Thanks!
> - Dave
> 
> 
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
> 



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

[systemd-devel] systemctl is-active

[Michał Zegan]

Hello.
When systemctl is-active was added?
I need this to check if I can safely use it to check if unit is active
if I don't have prior knowledge about the systemd version I am running
this on, this is for an ansible playbook.



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

Re: [systemd-devel] udev rule to mount ext4 with data=journal

[Michał Zegan]

Hmm, why not to place such things in /etc/fstab?

W dniu 14.06.2017 o 09:30, Pascal K pisze:
> Hello everyone, 
> 
> I am new to this list and to udev (used mdev before). 
> 
> My goal: Mount a CFast card partioned with 2 partitions one FAT32 and
> one EXT4, the EXT4 I would like to mount with option "data=journal"
> 
> The Problem: from the console using mount the partition can be mounted
> with mount -o "data=journal" ... but not from my udev rule. My rule
> results in only the FAT32 partition being mounted. 
> 
> My Rule: 
> 
> KERNEL!="sd[a-z][0-9]", GOTO="media_by_label_auto_mount_end"  
> # Import FS infos  
> IMPORT{program}="/sbin/blkid -o udev -p %N"  
> 
> # Global mount options  
> ACTION=="add", ENV{mount_options}="relatime"  
> 
> # Filesystem-specific mount options  
> ACTION=="add", ENV{ID_FS_TYPE}=="vfat|ntfs",
> ENV{mount_options}="$env{mount_options},utf8,gid=100,umask=002"
> ACTION=="add", ENV{ID_FS_TYPE}=="ext4",
> ENV{mount_options}="$env{mount_options},data=journal" 
> 
> #Mount the Filesystems
> ACTION=="add", RUN+="/bin/mkdir -p /media/$env{ID_FS_LABEL}",
> RUN+="/bin/mount -o %E{mount_options} /dev/%k /media/$env{ID_FS_LABEL}" 
> 
> # Exit  
> LABEL="media_by_label_auto_mount_end"
> 
> Any help is highly appreciated, so far I can only mount with
> "data=ordered" since this seems to be the default option (for that the
> two lines matching "ENV{ID_FS_TYPE} are removed). 
> 
> Best regards
> Pascal
> 
> 
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
> 



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

[systemd-devel] spurious suspend wakeup

[Michał Zegan]

Hello.

My laptop does spuriously wake up from suspend.
Can systemd be involved in this? I do not know any timer set to use a
wake alarm, but I may be wrong. I usually suspend by closing a lid, and
logind reports lid opened after wake up, but I do not know if it is just
because lid was closed before, or because it is really open. If that is
not a systemd problem, then how to check wakeup reason?



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

Re: [systemd-devel] pid namespaces, systemd and signals on reboot(2)

[Michał Zegan]

W dniu 29.05.2017 o 11:37, Lennart Poettering pisze:
> On Sat, 27.05.17 20:51, Michał Zegan (webczat_...@poczta.onet.pl) wrote:
> 
>> Hello.
>>
>> I came across the following:
>> The manpage reboot(2) says, that inside of a pid namespace, a reboot
>> call that normally would trigger restart actually triggers sending
>> sighup to the init of a namespace, and sigint is sent in case of
>> halt/poweroff.
> 
> That's misleading. This is not what happens. Instead, PID 1's parent
> (i.e. the container manager) will be notified about reboot() being
> called inside the container by a waitid() event of the container's PID
> 1, where the exit cause is reported to be an uncaught SIGHUP.
> 
> It's quite hacky to report it that way, since there's no way to
> distuingish a real SIGHUP exit from a reboot() exit this way, but it's
> how the the kernel decided to do it.
> 
> Or in other words: SIGHUP on the container's PID 1 is how the reboot()
> is *reported*, not what actually happened.
> 
> Lennart
> 
what you just said means a man-pages doc bug and I have reported it
yesterday, thank you.



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

Re: [systemd-devel] pid namespaces, systemd and signals on reboot(2)

[Michał Zegan]

W dniu 28.05.2017 o 20:43, Mike Gilbert pisze:
> On Sat, May 27, 2017 at 2:51 PM, Michał Zegan
>  wrote:
>> Hello.
>>
>> I came across the following:
>> The manpage reboot(2) says, that inside of a pid namespace, a reboot
>> call that normally would trigger restart actually triggers sending
>> sighup to the init of a namespace, and sigint is sent in case of
>> halt/poweroff.
>> I have verified that reboot actually triggers sighup. does it mean you
>> cannot "reboot -f" in a pid namespace, because it will actually trigger
>> something like "systemctl daemon-reload"? (confusing behavior)...
>> About poweroff, I used unshare -Upfr and then typed poweroff -f, and the
>> bash started by unshare exited. Bash does not exit on sigint, so not
>> sure what was sent? sigkill?
>> Also, how does systemd handle this case when you tell systemd to power
>> off/reboot? it probably exits instead of calling reboot(2), but does it
>> make it possible to distinguish reboot from power off?
>> Sorry for such an partially offtopic question.
> 
> I think that section of reboot(2) is inaccurate. I don't see any
> trappable signal actually being sent to the init process.
> 
> What actually seems to happen is this:
> 
> - All processes in the PID namespace are terminated by the kernel (SIGKILL?).
> - The exit status on the "init" process is set so that it appears to
> have been killed using SIGHUP or SIGINT. The parent process can use
> this to distinguish between a reboot and a halt request.
> 

Oooh, well, it seems you are probably right.
Tested by setting a trap on bash level (bash is pidns pid1), and sending
it sighup. It didn't kill it, but reboot -f did kill it as though sighup
would happen, but without actually sending sighup (trap not called).
Someone could verify that, and knowing how systemd handles
reboot/poweroff in pidns is still interesting to me.



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

[systemd-devel] pid namespaces, systemd and signals on reboot(2)

[Michał Zegan]

Hello.

I came across the following:
The manpage reboot(2) says, that inside of a pid namespace, a reboot
call that normally would trigger restart actually triggers sending
sighup to the init of a namespace, and sigint is sent in case of
halt/poweroff.
I have verified that reboot actually triggers sighup. does it mean you
cannot "reboot -f" in a pid namespace, because it will actually trigger
something like "systemctl daemon-reload"? (confusing behavior)...
About poweroff, I used unshare -Upfr and then typed poweroff -f, and the
bash started by unshare exited. Bash does not exit on sigint, so not
sure what was sent? sigkill?
Also, how does systemd handle this case when you tell systemd to power
off/reboot? it probably exits instead of calling reboot(2), but does it
make it possible to distinguish reboot from power off?
Sorry for such an partially offtopic question.



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

Re: [systemd-devel] hibernation sometimes not working

[Michał Zegan]

I have probably discovered the cause, and it is, that the memory image
would be too large to fit in the swap space, and I would have to
increase the swap space.

W dniu 25.04.2017 o 05:34, Andrei Borzenkov pisze:
> 25.04.2017 04:45, Michał Zegan пишет:
>> Hello.
>>
>> I have archlinux with systemd (currently the newest released).
>> Hibernation works properly in this computer. however, after few
>> hibernations (or maybe something else triggers this condition?) it
>> suddenly stops working. trying to do systemctl hibernate in the terminal
>> says something like unknown sleep verb (I do not currently have the
>> exact message, but it is saying about unknown sleep verb). I haven't
>> found a way to hibernate when this is triggered, and I usually fully
>> shutdown the computer then.
>> Any ideas?
>>
> 
> I do not see "unknown sleep verb" message in sources; there is "Sleep
> verb not supported" which means, your current kernel says it cannot do
> what you asked. Please show exact message you get.
> 
> 
> 
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
> 



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

[systemd-devel] hibernation sometimes not working

[Michał Zegan]

Hello.

I have archlinux with systemd (currently the newest released).
Hibernation works properly in this computer. however, after few
hibernations (or maybe something else triggers this condition?) it
suddenly stops working. trying to do systemctl hibernate in the terminal
says something like unknown sleep verb (I do not currently have the
exact message, but it is saying about unknown sleep verb). I haven't
found a way to hibernate when this is triggered, and I usually fully
shutdown the computer then.
Any ideas?



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

Re: [systemd-devel] systemd and hardware real time clock

[Michał Zegan]

W dniu 09.02.2017 o 18:49, Lennart Poettering pisze:
> On Thu, 09.02.17 16:14, Michał Zegan (webczat_...@poczta.onet.pl) wrote:
> 
>> Btw, about the argument that the kernel should set rtc time because of
>> wrong timestamps in logs, so I should compile the rtc into the kernel:
>> let's compare: if I read rtc time during bootup (and rtc is a module),
>> timestamps would be bad indeed for some time.
>> But one case is, what if there is no rtc? then the kernel cannot read
>> the clock. Neither can startup scripts or systemd (if it would ever
>> try). so log timestamps would be invalid for far longer, until time is
>> synchronized from network, and that will never happen if there is no
>> network. So I still think that systemd could do it, or, better,
>> initramfs could do it to make all real system logs have a  valid
>> timestamp, like not sure if initramfs logs are important for anything if
>> there were no boot issues.
> 
> Not sure I follow? What precisely do you mean?
> 
> if there's no RTC then the timestamps of all logs before we managed to
> get an NTP network fix will always be pretty bad, there's little we
> can do about that? Or what are you saying?
> 
> Lennart
> 
Yes, exactly. In addition I was just saying that the above means, that
there is nothing bad in letting systemd (or something else after kernel)
handle modular rtcs. Because rtc in the kernel still does not cover all
possible cases (like missing rtc), and rtcs are very often compiled as
modules. Although I now believe initramfs may be a better place for
reading hardware clock than systemd running on a real root, that will
make proper boot logs have good timestamps I think, only initramfs and
the kernel will have timestamp problems.



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

Re: [systemd-devel] systemd and hardware real time clock

[Michał Zegan]

W dniu 09.02.2017 o 15:52, Lennart Poettering pisze:
> On Tue, 17.01.17 12:29, Michał Zegan (webczat_...@poczta.onet.pl) wrote:
> 
>> Hello.
>>
>> I am aware of the fact that systemd relies on the kernel to set system
>> clock from hardware clock, and that requires compiling rtc drivers into
>> the kernel, not as modules.
>> I am also aware that doing it othervise would mix timestamps in log entries.
>> The question is: if I have rtc driver as a module anyway, how to modify
>> initramfs so that system time would be set, in such a way so that it
>> happens *before* journald in initramfs starts? I assume it is an
>> initramfs using systemd inside of it.
>> One approach would be to have an udev rule that does trigger after rtc
>> appears or rtc symlink is added, this rule would start a service that
>> sets the system clock, but this service would have to always run before
>> journald, and that seems not possible in such a configuration, because
>> if someone would unplug the rtc the service would not run?
>> Another thing is to load rtc and i2c bus module where rtc is connected
>> statically without udev detection, and then the hwclock service would
>> always be triggered before journald without looking for rtcs appearing...
> 
> Well, you could write a tool that uses libudev but listens on the
> kernel mcast group instead of the udev one, and then, as soon as the
> RTC showed up would do the /dev/thing. Then, make a service of it,
> make sure to use StandardOutput=null + StandardError=null, so that you
> don't get an implicit dependency on journald, and order the service
> before journald.
> 
> Lennart
> 
Btw, about the argument that the kernel should set rtc time because of
wrong timestamps in logs, so I should compile the rtc into the kernel:
let's compare: if I read rtc time during bootup (and rtc is a module),
timestamps would be bad indeed for some time.
But one case is, what if there is no rtc? then the kernel cannot read
the clock. Neither can startup scripts or systemd (if it would ever
try). so log timestamps would be invalid for far longer, until time is
synchronized from network, and that will never happen if there is no
network. So I still think that systemd could do it, or, better,
initramfs could do it to make all real system logs have a  valid
timestamp, like not sure if initramfs logs are important for anything if
there were no boot issues.



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

[systemd-devel] systemd and hardware real time clock

[Michał Zegan]

Hello.

I am aware of the fact that systemd relies on the kernel to set system
clock from hardware clock, and that requires compiling rtc drivers into
the kernel, not as modules.
I am also aware that doing it othervise would mix timestamps in log entries.
The question is: if I have rtc driver as a module anyway, how to modify
initramfs so that system time would be set, in such a way so that it
happens *before* journald in initramfs starts? I assume it is an
initramfs using systemd inside of it.
One approach would be to have an udev rule that does trigger after rtc
appears or rtc symlink is added, this rule would start a service that
sets the system clock, but this service would have to always run before
journald, and that seems not possible in such a configuration, because
if someone would unplug the rtc the service would not run?
Another thing is to load rtc and i2c bus module where rtc is connected
statically without udev detection, and then the hwclock service would
always be triggered before journald without looking for rtcs appearing...



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

Re: [systemd-devel] Stable interface names even when hardware is added or removed, not true

[Michał Zegan]

But he coul use a .link file to give a persistent interface name based
on some property, wouldn't it be a nice thing to do?

W dniu 16.11.2016 o 17:11, Greg KH pisze:
> On Wed, Nov 16, 2016 at 03:33:42PM +0200, Pekka Sarnila wrote:
>> On 'Predictable Network Interface Names' it states as a benefit of the new
>> policy:
>>
>>   Stable interface names even when hardware is added or removed, i.e.
>>   no re-enumeration takes place
>>
>> Unfortunately this is not true.
>>
>> I'm running a mail server, kernel 4.8.6. Graphics card started to fail.
>> Replaced it with new one (newer model). Booted the system.
>>
>> All seemed to be fine, network seemed to work. But after some time got angry
>> cries: 'can't read the mail !!!'. A big headache.
>>
>> Although the new card was in the same slot as the old one kernel had changed
>> the name enp6s0 -> enp3s0 (no firmware/BIOS index available and kernel
>> policy was used as default). Since enp6s0 was not found our server instead
>> of fixed ip address used our dhcp-server to get a random temp address. Thus
>> network worked, but not in the mail-servers correct address.
>>
>> To figure this out took some nervous time.
>>
>> Now, I don't know why kernel driver got a different name for this network
>> interface (ethernet hardware is on the motherboard, and it is the only net
>> hardware on the system). But obviously it can happen.
> 
> That is because your PCI devices renumbered themselves, which is quite
> common when changing PCI devices around (or adding/removing them).  Not
> much systemd can do about this, sorry.
> 
> greg k-h
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
> 



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

Re: [systemd-devel] systemd-nspawn containers

[Michał Zegan]

well you can read user_namespaces(7), the beginning of it at least. it
probably says something about keyrings. so either this info is
incorrect, or I for example understand it wrongly, or whatever.
Also, you know, when you say that currently containers have holes and so
are still not really secure I don't actually see any example of that
except this small number of things you just cannot do there at all (for
example use/access audit or use fuse/file capabilities), and those like
cgroups that are work in progress at this very moment. Well, file caps
are also work in progress at the moment I believe, I saw some patches
lately. I don't see such problems probably because I am not a security
expert and I am not working with any kind of servers/containers in
production, this technology is just extremely interesting for me.

W dniu 11.11.2016 o 19:41, Lennart Poettering pisze:
> On Fri, 11.11.16 19:36, Michał Zegan (webczat_...@poczta.onet.pl) wrote:
> 
>> Why do you turn off keyrings? at least manpages say that userns
>> virtualizes keyrings or something similar...
> 
> That'd be a new feature then...
> 
> Lennart
> 



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

Re: [systemd-devel] systemd-nspawn containers

[Michał Zegan]

Why do you turn off keyrings? at least manpages say that userns
virtualizes keyrings or something similar...

W dniu 11.11.2016 o 19:24, Lennart Poettering pisze:
> On Fri, 11.11.16 19:21, Michał Zegan (webczat_...@poczta.onet.pl) wrote:
> 
>> audit/autofs are not properly virtualized, I know. But I thought
>> keyrings and cgroups are.
> 
> most container managers turn off keyrings entirely (as we do in nspawn
> actually).
> 
> delegating controllers in cgroupsv1 is unsafe, if you do it the
> container can make the system hang easily.
> 
> delegating controllers in cgroupvs2 is safe, but cgroupsv2 are
> incomplete as of now, the most relevant controller (cpu) is not
> available for it yet.
> 
> Lennart
> 



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

Re: [systemd-devel] systemd-nspawn containers

[Michał Zegan]

audit/autofs are not properly virtualized, I know. But I thought
keyrings and cgroups are.

W dniu 11.11.2016 o 18:28, Lennart Poettering pisze:
> On Fri, 11.11.16 16:41, Michał Zegan (webczat_...@poczta.onet.pl) wrote:
> 
>> Thank you for your answers!
>>
>> What I meant by secure containers is mostly, containers that are or will
>> be secure enough to use them for things like virtual private server
>> hosting. Is nspawn intended to be usable for such things in the future,
>> or maybe it already is, or whatever?
> 
> I run my own server this way, already as an exercise of dogfooding.
> 
> So, yes, running a VPS like this certainly works, but do note that
> nspawn doesn't do orchestration or anything. It's good enough for me,
> but if you needy fancy orchestration tools then nspawn won't be
> sufficient.
> 
>> What kernel limitations do you mean when you say about security?
> 
> Well, a lot of subsystems cannot be locked down properly for use in
> containers yet. You can lock down a lot, in particular if you use
> userns, but there are still a lot of holes in there, and in particular
> userns itself has been a major source of CVEs alone in the most recent
> kernels.
> 
> Right now, "containers" in general are not about security. Some
> companies claim they were secure, but they really aren't. And that's
> not a bug in nspawn, or docker, or lxc for that matter, it's simply a
> limiation of the kernel.
> 
> Or to say this differently: we'll do in nspawn everything we can to
> lock things down properly, but there are limits based on what the
> kernel provides... As the kernel gets improved in this area, we'll
> update nspawn to make use of it. We are sitting in the same boat in
> this regard as others container managers, and they have the same
> limits more or less we have.
> 
>> For now I know that in full containers with userns file capabilities do
>> not work (I think), you have no virtualized /proc/meminfo and friends
>> (do cgroup namespaces give a chance to change that?), you cannot mknod
>> devices (no whitelist possible at this level), no fuse support, no
>> automatic uid shifting kernel level, no possibility to mount physical
>> filesystems in userns, and no possibility to have selinux/etc per
>> container. Do you mean such limitations or something else?
> 
> Well, devices are not virtualized at all (with the exception of
> network devices), that means no udev, not hotplug events and so
> on. Some container managers ignore this, and provide access to
> selected device nodes anyway, but we don't do something like that in
> nspawn, since it's pretty broken (as /sys wouldn't match what you see
> in /dev). In general, I think people should just accept that
> containers mean "you don't get physical device access". And if you
> want physical device access, then don't use containers...
> 
>> I am interested in this topic but it is quite hard for me to track
>> progress in that area (kernel side) even though I subscribe in some
>> kernel ml's and know at least about submitted patches, or some of
>> them. What else is missing that I didn't say about that would be
>> good to have?
> 
> Well, a lot of stuff is still not properly virtualized. To mind come
> audit, autofs, keyring, cgroups, …
> 
>> Also what about setting cgroup parameters per container? nspawn does not
>> allow doing that, and you probably do not intent it to be done by
>> overriding container's scope unit settings, for example?
> 
> You can actually do that just fine. Simply set it in the nspawn  service
> file. Or if you run nspawn from the cmdline with the "-p" switch. Or
> make your changes dynamically via "systemctl set-property". It's all
> supported and works well.
> 
> Lennart
> 



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

Re: [systemd-devel] systemd-nspawn containers

[Michał Zegan]

Thank you for your answers!

What I meant by secure containers is mostly, containers that are or will
be secure enough to use them for things like virtual private server
hosting. Is nspawn intended to be usable for such things in the future,
or maybe it already is, or whatever?
What kernel limitations do you mean when you say about security?
For now I know that in full containers with userns file capabilities do
not work (I think), you have no virtualized /proc/meminfo and friends
(do cgroup namespaces give a chance to change that?), you cannot mknod
devices (no whitelist possible at this level), no fuse support, no
automatic uid shifting kernel level, no possibility to mount physical
filesystems in userns, and no possibility to have selinux/etc per
container. Do you mean such limitations or something else? I am
interested in this topic but it is quite hard for me to track progress
in that area (kernel side) even though I subscribe in some kernel ml's
and know at least about submitted patches, or some of them. What else is
missing that I didn't say about that would be good to have?

Also what about setting cgroup parameters per container? nspawn does not
allow doing that, and you probably do not intent it to be done by
overriding container's scope unit settings, for example?

W dniu 11.11.2016 o 13:52, Lennart Poettering pisze:
> On Wed, 09.11.16 18:24, Michał Zegan (webczat_...@poczta.onet.pl) wrote:
> 
>> Hello.
>>
>> Does systemd-nspawn intent to be a full secure container technology? or
>> it maybe already is? what is missing?
> 
> I am not sure what "full secure container technology" realls is
> supposed to mean.
> 
> nspawn right now is great for two things:
> 
> a) full OS containers (think VMs, except based on container
>technology. This means that inside the container you have a proper
>PID 1 running, and a network configuration daemon and most other
>things that would run on a normal, physical system, except one
>thing: no device manager, as the kernel does not virtualize
>devices)
> 
> b) as a building block for whatever you want it to be. It's a pretty
>generic tool, you can use as base for anything you like. The "rkt"
>container manager makes use of this facet.
> 
> There are a number of things nspawn is better at than other container
> managers, for example in conjunction with networkd networking happens
> pretty much entirely automatically out of the box. It also ships
> userns support that is relatively usable without much manual
> intervention. OTOH it clearly doesn't do a lot of stuff that other
> container managers do and we have no intention to ever do: do IP level
> configuration in the manager itself, support for ZFS and other exotic
> (possibly out-of-tree) storage technology, and so on.
> 
> So it really depends what you mean by "full secure container
> technology". We do a lot, we will add more, but there are also things
> I don't see on our list at all.
> 
> (And "secure" is a difficult thing anyway, currently security of
> containers on Linux is pretty limited in general, due to kernel
> limitations.)
> 
> Lennart
> 



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

[systemd-devel] systemd-nspawn containers

[Michał Zegan]

Hello.

Does systemd-nspawn intent to be a full secure container technology? or
it maybe already is? what is missing?



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

[systemd-devel] terminal permissions after machinectl shell

[Michał Zegan]

Hello, when you use machinectl shell, you get your own pseudoterminal,
don't you? but it is owned by root.
Problem is when some background process tries to open this terminal when
this background process runs from the spawned shell, like gpg-agent,
because it has no permissions to do so and fails.



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

Re: [systemd-devel] unknown problem with systemd

[Michał Zegan]

But how to check what is happening? and I am still not sure why my
normal laptop with systemd works properly and starts journald.

W dniu 14.08.2016 o 06:56, Andrei Borzenkov pisze:
> 14.08.2016 04:58, Michał Zegan пишет:
>> Hello. I have installed systemd version 231 from arch repos. actually it
>> is systemd-selinux from aur. now, the problem:
>> the system boots. but some services fail to start, notably
>> systemd-journald and systemd-networkd, not sure if others fail too.
>> When checking what happened using dmesg as journald does not work, I get
>> that the control process received signal 31, marked sigsys. no explanation.
>> I have normal systemd 231 on my laptop, and it works with journal and
>> all. In addition, running processes normally on this pc where it does
>> not work does not kill them with signal sigsys.
> 
> SIGSYS is used by seccomp to kill process with SECCOMP_RET_KILL. So it
> looks like some too restrictive filters are in effect.
> 
>> Does anyone know or suspect what may be the cause? My kernel has a
>> heavily modified configuration, and I just upgraded from 4.6 to 4.7 and
>> configured using make oldconfig.
>>
>>
>>
>> ___
>> systemd-devel mailing list
>> systemd-devel@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
>>
> 



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

[systemd-devel] unknown problem with systemd

[Michał Zegan]

Hello. I have installed systemd version 231 from arch repos. actually it
is systemd-selinux from aur. now, the problem:
the system boots. but some services fail to start, notably
systemd-journald and systemd-networkd, not sure if others fail too.
When checking what happened using dmesg as journald does not work, I get
that the control process received signal 31, marked sigsys. no explanation.
I have normal systemd 231 on my laptop, and it works with journal and
all. In addition, running processes normally on this pc where it does
not work does not kill them with signal sigsys.
Does anyone know or suspect what may be the cause? My kernel has a
heavily modified configuration, and I just upgraded from 4.6 to 4.7 and
configured using make oldconfig.



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

[systemd-devel] hardware clock

[Michał Zegan]

Hello.

There is, it seems, a problem with the hardware clock. That is, the
systemd does not care about it. Neither systemd nor udev rules set the
system time using the hardware clock.
From what I know, if the clock is a cmos rtc, the kernel always sets
time during bootup. In any other case, it should do this anyway if it is
configured to do so during compilation, but only when appropriate rtc
support is compiled into the kernel. So, userspace does not have to.
The problem is that there are cases when the rtc is not a cmos one, and
the driver is compiled as a module. This is a specific case because the
kernel will not restore the time, and systemd does not do this either.
The thing that restores the time is ntp synchronization and that is not
related to the hardware clock.
This issue is visible in case of arm boards with external realtime
clocks, as those clocks are bought separately and not part of the
platform. It would be nice if systemd would set the time, or if udev had
a rule to do this, or both (in case the module was loaded earlier during
initramfs phase). Or any other solution for that would be nice.



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

Re: [systemd-devel] looking at journal of other users

[Michał Zegan]

well, did not know about that! it actually seems to work, thank you very
much.

W dniu 12.07.2016 o 12:57, Lennart Poettering pisze:
> On Tue, 12.07.16 12:47, Michał Zegan (webczat_...@poczta.onet.pl) wrote:
> 
>> uhm the real question was: If I am already in the wheel group, how can I
>> see the journal of other user? I believe that journalctl does not merge
>> journals of all users in the system, does it? Even if it does, I believe
>> it would be quite useful to be able to do journalctl --user someone and
>> view his journal.
> 
> It will merge everything you have access to by default, as long as it
> stems from the local host. "journalctl -m" then adds in even more,
> such as stuff from local containers.
> 
> To filter logs from a specific user, try:
> 
>journalctl _UID=`id -u lennart`
> 
> (This will show all logs from user "lennart")
> 
> Lennart
> 



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

Re: [systemd-devel] looking at journal of other users

[Michał Zegan]

uhm the real question was: If I am already in the wheel group, how can I
see the journal of other user? I believe that journalctl does not merge
journals of all users in the system, does it? Even if it does, I believe
it would be quite useful to be able to do journalctl --user someone and
view his journal.

W dniu 12.07.2016 o 11:36, Lennart Poettering pisze:
> On Sat, 09.07.16 22:45, Michał Zegan (webczat_...@poczta.onet.pl) wrote:
> 
>> Hello.
>>
>> I believe administrators, like groups wheel and adm at least, have
>> access to read system journal and journals of all users.
>> journalctl can show the journal of the current user, system journal or
>> merge both of them. Could you please add the possibility to see the logs
>> of others, if not already present?
> 
> Hmm? Add yourself to the "wheel", "adm" or "systemd-journal" groups to
> see other user's logs. If you are not a member of any of these groups
> you won't get access though, for a good reason, as logs should be
> private to users. There really needs to be an authenticated operation
> in place before access can be granted, and that's done via the group
> membership of any of the three groups mentioned above.
> 
> Lennart
> 



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

[systemd-devel] looking at journal of other users

[Michał Zegan]

Hello.

I believe administrators, like groups wheel and adm at least, have
access to read system journal and journals of all users.
journalctl can show the journal of the current user, system journal or
merge both of them. Could you please add the possibility to see the logs
of others, if not already present?



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

Re: [systemd-devel] Adding a Timer section to .service files

[Michał Zegan]

the only reason to add such a thing at all is that making one file is
easier/faster. There is no other reason beside this one, so if it is not
considered a good one, then this feature is othervise useless. Also,
some time after proposing this I realized that it would be very easy to
implement what I say for new timer units, but you would need extra logic
to handle changing and reloading those timer units, or removing them
maybe, so hmm well, may be more complicated than I thought.

W dniu 08.07.2016 o 21:04, Andrei Borzenkov pisze:
> 08.07.2016 21:40, Michał Zegan пишет:
>> Well, I also came with another idea. of course if you do not want to
>> have two different ways to do one thing it is a stopper, but I will tell
>> about it for completeness as it may or may not be easier to implement.
>> Instead of creating a timer unit on service file installation or
>> something, you could have service and similar sections in the timer
>> unit, so the other way around. then, if service name is not explicitly
>> set in the unit and the service file with appropriate name does not
>> exist, it could just create it using information found in the timer unit
>> file, if such information can be found. The service file will be
>> generated in /run/systemd/system for example and it will work normally.
> 
> So you just added one more step and end up in with exactlythe same - you
> have separate timer and service units. How is it an improvement? If you
> need to have separate service unit anyway, what advantage defining it
> somewhere else offers?
> 
>> So, except the reason about not wanting to have two different ways of
>> doing one thing, it does not have other problems of the approach
>> mentioned first unless you also have another reasons not to generate
>> service units this way.
>>
> 
> 
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
> 



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

Re: [systemd-devel] Adding a Timer section to .service files

[Michał Zegan]

Well, I also came with another idea. of course if you do not want to
have two different ways to do one thing it is a stopper, but I will tell
about it for completeness as it may or may not be easier to implement.
Instead of creating a timer unit on service file installation or
something, you could have service and similar sections in the timer
unit, so the other way around. then, if service name is not explicitly
set in the unit and the service file with appropriate name does not
exist, it could just create it using information found in the timer unit
file, if such information can be found. The service file will be
generated in /run/systemd/system for example and it will work normally.
So, except the reason about not wanting to have two different ways of
doing one thing, it does not have other problems of the approach
mentioned first unless you also have another reasons not to generate
service units this way.

W dniu 08.07.2016 o 20:29, Lennart Poettering pisze:
> On Fri, 08.07.16 18:17, Michał Zegan (webczat_...@poczta.onet.pl) wrote:
> 
>> well, that makes sense, thanks. about a timer section shortcut, could it
>> be done in a different way? like, it is a shortcut and systemd should
>> somehow generate the corresponding timer file automatically? although
>> still it would need a little special logic when loading the service
>> first.
> 
> I am not convinced that providing two redundant ways to do the same
> thing is a good idea. It's bad enough we support both /etc/fstab and
> .mount for defining mounts. "Compatibility" is certainly a good enough
> excuse to do this anyway in this case. However, if we have two
> different ways to configure the same thing with systemd-native file
> formats then that's a very different thing and I am very conservative
> about really.
> 
> And as mentioned in the other mail: the load logic would become quite
> different as we'd have to look for all kinds of unit files if we try
> to load a .timer unit.
> 
> Lennart
> 



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

Re: [systemd-devel] Adding a Timer section to .service files

[Michał Zegan]

well, that makes sense, thanks. about a timer section shortcut, could it
be done in a different way? like, it is a shortcut and systemd should
somehow generate the corresponding timer file automatically? although
still it would need a little special logic when loading the service first.

W dniu 08.07.2016 o 18:06, Lennart Poettering pisze:
> On Fri, 08.07.16 15:42, Michał Zegan (webczat_...@poczta.onet.pl) wrote:
> 
>> One thing to say: I heard, at least once, that systemd's timer are more
>> complicated because in order to make a timer you need two files instead
>> of creating one, especially in comparison to cron where you need just
>> one line although I always forget the order of fields. I would say a
>> timer section in the service file could be a nice shortcut to create
>> timers for services quickly.
> 
> Yes, cron lines are much more condensed than .timer unit files, and
> /etc/fstab lines are more condensed than .mount unit files. But I also
> believe that unit files due to their relatively uniform and
> self-describing format are much easier to read at least, as well as a
> lot more extensible. After all, we do expose a number of options for
> timer units that I wouldn't even know how one could condense into a
> cron line... /etc/fstab files are a bit more extensible than cron
> lines, since the options part allows adding in additional, new
> settings, but it isn't really that pretty to write them all into the
> fourth column of a single line, without any whitespace and so on.
> 
> Ultimately it's really a design decision: tabular file formats have
> the benefit of being a lot more dense, but are neither particularly
> extensible nor self-explanatory (as you need to know what each column
> means). Unit files are a bit longer to write, but more extensible and
> self-explanatory. When we designed this we preferred the latter two
> properties over the density property.
> 
> I hope this makes sense,
> 
> Lennart
> 



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

Re: [systemd-devel] Adding a Timer section to .service files

[Michał Zegan]

One thing to say: I heard, at least once, that systemd's timer are more
complicated because in order to make a timer you need two files instead
of creating one, especially in comparison to cron where you need just
one line although I always forget the order of fields. I would say a
timer section in the service file could be a nice shortcut to create
timers for services quickly.

W dniu 08.07.2016 o 15:14, Reindl Harald pisze:
> 
> 
> Am 08.07.2016 um 15:11 schrieb One Infinite Loop:
>> There are cases when you don't need .timer files but only a [Timer]
>> section. With a well written manual page, systemd users will understand
>> why is useful to have a [Timer] section inside a .service file
> 
> FIRST: learn to quote in email
> 
> second: you need to explain the usecases very well
> third: a good design don't require read manpages all the time
> 
> 
> 
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
> 



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

[systemd-devel] audit support weirdness

[Michał Zegan]

Hello.

There is a problem with current audit support in journald. it listens
for audit events, but those same audit events go to dmesg, making a lot
of garbage.
Also, in case of a selinux enabled system, it generates huge amount of
audit output even if you do not want that, for example, pam generates
audit events for all pam stacks being traversed during user login, and
in addition this is doubled because dmesg.
This is even more of a problem because you cannot for example tell
journalctl to get all logs except audit and things like that, so it hits
readability.



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

Re: [systemd-devel] ipv6 configuration error

[Michał Zegan]

it is not large, is it: I will set up the tunnel and attach what you want.

I have set up the tunnel. systemd-networkd configured it immediately
when I issued ip tunnel add with parameters. here is ip addr output:

1: lo:  mtu 65536 qdisc noqueue state UNKNOWN
group default qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
   valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
   valid_lft forever preferred_lft forever
2: eth0:  mtu 1500 qdisc fq_codel state
UP group default qlen 1000
link/ether 00:25:90:31:ec:c6 brd ff:ff:ff:ff:ff:ff
inet 91.121.100.5/24 brd 91.121.100.255 scope global dynamic eth0
   valid_lft 572sec preferred_lft 572sec
inet6 fe80::225:90ff:fe31:ecc6/64 scope link
   valid_lft forever preferred_lft forever
3: eth1:  mtu 1500 qdisc noop state DOWN group
default qlen 1000
link/ether 00:25:90:31:ec:c7 brd ff:ff:ff:ff:ff:ff
4: vmnet:  mtu 1500 qdisc noqueue state
UP group default qlen 1000
link/ether 32:1b:ee:cb:a8:59 brd ff:ff:ff:ff:ff:ff
inet 10.0.0.1/24 brd 10.0.0.255 scope global vmnet
   valid_lft forever preferred_lft forever
inet6 2001:470:71:796::1/64 scope global
   valid_lft forever preferred_lft forever
inet6 fe80::301b:eeff:fecb:a859/64 scope link
   valid_lft forever preferred_lft forever
17: tap0:  mtu 1500 qdisc fq_codel
master vmnet state UNKNOWN group default qlen 1000
link/ether fe:ab:50:47:ec:78 brd ff:ff:ff:ff:ff:ff
inet6 fe80::fcab:50ff:fe47:ec78/64 scope link
   valid_lft forever preferred_lft forever
18: sit0@NONE:  mtu 1480 qdisc noop state DOWN group default qlen 1
link/sit 0.0.0.0 brd 0.0.0.0
19: ipv6@NONE:  mtu 1480 qdisc noqueue
state UNKNOWN group default qlen 1
link/sit 91.121.100.5 peer 216.66.80.162
inet6 2001:470:71:796::1/128 scope global
   valid_lft forever preferred_lft forever
inet6 fe80::5b79:6405/64 scope link
   valid_lft forever preferred_lft forever

Here are configs:

ipv4.network:

[Match]
Name=eth0
[Network]
DHCP=ipv4
IPv6AcceptRouterAdvertisements=false
Tunnel=ipv6

ipv6.netdev:

[NetDev]
Name=ipv6
Kind=sit
[Tunnel]
Local=91.121.100.5
Remote=216.66.80.162

ipv6.network:

[Match]
Name=ipv6
[Network]
Address=2001:470:71:796::1/128
IPv6AcceptRouterAdvertisements=false
[Route]
Destination=::/0
PreferredSource=2001:470:71:796::1


W dniu 27.05.2016 o 18:37, Tom Gundersen pisze:
> On Fri, May 27, 2016 at 5:11 PM, Michał Zegan
> mailto:webczat_...@poczta.onet.pl>> wrote:
> 
> Hello, I have encountered a very interesting problem: I have a wired
> ipv4 network configured via systemd-network, and an ipv6 sit tunnel.
> The problem is it does not start. trying to restart systemd-networkd
> gives the error like both local and remote addresses of the tunnel are
> incompatible. I assume that means there is no interface matching those
> ipv4 addresses. I know that eth0 interface is configured *after* this
> sit one, and it is configured via dhcp, so it is quite possible. What is
> happening?
> 
> 
> Hi Michał,
> 
> Could you configure it manually (using ip(8) or something) and paste the
> output of `ip link` and `ip addr`, and also attach the networkd
> configuration you tried to use (would be great of course if you could
> make it as minimal as possible, but still showing your problem).
> 
> Cheers,
> 
> Tom



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

[systemd-devel] ipv6 configuration error

[Michał Zegan]

Hello, I have encountered a very interesting problem: I have a wired
ipv4 network configured via systemd-network, and an ipv6 sit tunnel.
The problem is it does not start. trying to restart systemd-networkd
gives the error like both local and remote addresses of the tunnel are
incompatible. I assume that means there is no interface matching those
ipv4 addresses. I know that eth0 interface is configured *after* this
sit one, and it is configured via dhcp, so it is quite possible. What is
happening?



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

Re: [systemd-devel] Running ldconfig at boot

[Michał Zegan]

From what I understand, directories such as /usr/lib and stuff are
properly used even in case of a corrupted ld.so cache. like ldconfig
does not affect those directories at this time.

W dniu 20.05.2016 o 14:06, Vasiliy Tolstov pisze:
> 2016-05-20 15:01 GMT+03:00 Florian Weimer :
>> The default systemd configuration runs ldconfig at boot.  Why?
>>
>> Most deployments of systemd appear to be dynamically linked, so if the ld.so
>> caches are corrupted, you will never get to the point where you can run
>> ldconfig.
>>
>> Running ldconfig too early tends to cause problems because the file system
>> might not have been set up completely, and the cache does not match what the
>> system administrator has configured.
>>
>> Florian
> 
> 
> Also sometimes this take on my server 22s =)
> 



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

Re: [systemd-devel] overriding udev rules

[Michał Zegan]

symlink it in /etc/udev/rules.d to /dev/null.

W dniu 28.02.2016 o 11:40, Łukasz Stelmach pisze:
> Hi,
> 
> One of the default rules supplied by systemd (v215 in Debian) is
> responsible restoring the state of rfkill switches.
> 
> SUBSYSTEM=="rfkill", TAG+="systemd", 
> ENV{SYSTEMD_WANTS}+="systemd-rfkill@$name.service"
> 
> For a reason or two I'd like to override it and not restore the state.
> I don't want make a copy of 99-systemd.rules in /etc just to edit one
> line. Is there any other reasonable way to prevent the above rule from
> being executed?
> 
> Kind regards,
> 
> 
> 
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
> 



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

Re: [systemd-devel] Support for large applications

[Michał Zegan]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi, I'll add to this:

W dniu 17.02.2016 o 14:56, Zbigniew Jędrzejewski-Szmek pisze:
> On Wed, Feb 17, 2016 at 02:35:55PM +0200, Avi Kivity wrote:
>> We are using systemd to supervise our NoSQL database and are 
>> generally happy.
>> 
>> A few things will help even more:
>> 
>> 1. log core dumps immediately rather than after the dump
>> completes
>> 
>> A database will often consume all memory on the machine; dumping 
>> 120GB can take a lot of time, especially if compression is
>> enabled. As the situation is now, there is a period of time where
>> it is impossible to know what is happening.
>> 
>> (I saw that 229 improves core dumps, but did not see this
>> specifically)
> 
> The coredump is logged afterwards because that's the only way to 
> include all information (including the compressed file name) in
> one log message. But there are two changes which might mitigate the
> problem: - semi-recently we switched to lz4, which compresses
> significantly faster, have you tried that?
> 
> - recently the responsibility of writing core dumps was split out
> to a service. I'm not sure how that influences the time when the
> log message is written.
> 
>> 2. parallel compression of core dumps
>> 
>> As well as consuming all of memory, we also consume all cpus.
>> Once we dump core we may as well use those cores for compressing
>> the huge dump.
> 
> This should be implemented in the compression library. The
> compressor does not seem to be threaded, but it was we would try to
> make use of it. OTOH, single-threaded lz4 is able to produce
> ~500MB/s of compressed output, so you'd need a really fast disk to
> go above that.
> 
>> 3. watchdog during startup
>> 
>> Sometimes we need to perform expensive operations during startup 
>> (log replay, rebuild from network replica) before we can start 
>> serving. Rather than configure a huge start timeout, I'd prefer
>> to have the service report progress to systemd so that it knows
>> that startup is still in progress.

This requires cooperation from the service process, but is probably
possible.
> 
> Zbyszek ___ 
> systemd-devel mailing list systemd-devel@lists.freedesktop.org 
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWxICYAAoJEHb1CzgxXKwYDooP/2OAx9WYfFuKDDrtuQ4KNRi/
X+20724fBeSJ7NZs/JieLjVYwAIRkHD/5OXzW2S5HZAvilrQwUCiSCZfADNB+0Tv
189noHuR4l9PopMUoVl4ay13W+1O93x2Tq3SPxe0SmkQEl9tWzKYYeS98q80a5gE
179fvQtkyDfcoKLp5npxmXaQZpqarl6FH3z41hHzWJdTZKiOiAFtYYSxNgzDRvar
cBGSTsb8NLGMZBA0B0NLGWNNLMIq2qZbIJ600I1Buu6OkBGq0dyikFUpEdWdW8+k
SVOGLrNll8wxpzd8Kxm9CmoQmzw/Bgo9eeX2kpuubOd85IBfauI/vzpTXw4geWzw
PuMh9NetEWpNTx6fqbpJ+yVSygldJ1HRKeTjmM6kt527D8yRvNOGdsQEgzqxi1l3
3aWohll4FDL0f5CpnCixZH8ZNwTePIacQi3Btd76LK9m8Fu4cV9yi70L4tY6dewQ
7XZEYK77s4p8R5UpyGsx2X/rtkZI6nGNRejWSzkAfsLBb0VL5TxqJyw5goP+ATIZ
HDJz8pPN2hxDLzQ9ou70sG1O3Pt87dF4BjHqWCeoMKQJ8Z0LfhlLz44EVX/EYfjy
0A298GlPgw+Jhb8lm3e/eFnbfl3iHYaQmtewXwOhcSKfHB13TGAkPwW6YTFafVDG
JDjiS2mB3v4ONwuu2gCs
=S4f+
-END PGP SIGNATURE-
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] user unit blocking login shell from popping out because wanted by default target?

[Michał Zegan]

The only thing seems to be you cannot go low latency with system mode 
pulseaudio


W dniu 10.01.2016 o 18:53, Reindl Harald pisze:



Am 10.01.2016 um 18:42 schrieb Tom Yan:

Ugh I am not talking about system units, but user units...

P.S. Although not really relevant here, but I am using the (user)
service file provided by upstream pulseaudio


well, and i am talking about solutions and working setups

and yes i know that system-wide is not liked upstream but it's the 
only real solution to have sound everytime and everywhere because i 
have *zero* understanding for music stop to play just because i switch 
to a root VT while i had background music servers developed on windows 
15 yaers ago


On 11 January 2016 at 01:30, Reindl Harald  
wrote:



Am 10.01.2016 um 18:15 schrieb Mantas Mikulėnas:


I remember this discussed before, I think one suggestion was to split
into two targets, and only hold the login until the first target. 
Nobody

implemented it though.

But yes, pulseaudio.socket would be a requirement of that. If you 
don't

want to wait until it starts, *and* don't want to socket-activate it,
the third option is to live in a world of race conditions.

On Sun, Jan 10, 2016, 16:25 Tom Yan mailto:tom.t...@gmail.com>> wrote:

 So I am recently experiencing some issue with pulseaudio (which I
 already filed a bug report:
 https://bugs.freedesktop.org/show_bug.cgi?id=93651) that it 
takes a

 long time to start.

 The thing is, I am thinking whether it exposed a problem of 
systemd as

 well. For example:

 Jan 10 21:31:33 localhost systemd[257]: Starting Sound Service...
 Jan 10 21:31:33 localhost systemd[257]: Started D-Bus User 
Message

Bus.
 Jan 10 21:31:39 localhost systemd[257]: Started Sound Service.
 Jan 10 21:31:39 localhost systemd[257]: Reached target Default.
 Jan 10 21:31:39 localhost systemd[257]: Startup finished in 
5.830s.


 As you can see, because of pulseaudio, it takes about 6 
seconds to

 reach the default target



no idea how you configured you pulseaudio.service

but i can assure you that i have systems with pulseaudio as systemwide
daemons where the whol eboot inlcuding VMware, httpd, dbmail and two
mysql-instances takes around 18 seconds

in fact with "type=simple" it can't delay boot at all

[root@srv-rhsoft:~]$ cat /usr/lib/systemd/system/pulsed.service
[Unit]
Description=Pulseaudio Daemon
After=rtkit-daemon.service systemd-udevd.service dbus.service 
sddm.service


[Service]
Type=simple
ExecStart=-/usr/bin/pulseaudio --daemonize=false --system=true
--realtime=true --log-level=0 --log-target=stderr
--disallow-module-loading=true --disallow-exit=true --exit-idle-time=0
--disable-shm=true --no-cpu-limit=false --use-pid-file=false
--resample-method=src-sinc-best-quality

Restart=always
RestartSec=30
TimeoutSec=15
Nice=-10

PrivateTmp=yes
PrivateNetwork=yes

CapabilityBoundingSet=~CAP_AUDIT_CONTROL CAP_AUDIT_WRITE CAP_SYS_ADMIN
CAP_SYS_BOOT CAP_SYS_MODULE CAP_SYS_PTRACE

ReadOnlyDirectories=/etc
ReadOnlyDirectories=/usr
ReadOnlyDirectories=/var
ReadWriteDirectories=/var/lib/pulse

InaccessibleDirectories=-/boot
InaccessibleDirectories=-/home
InaccessibleDirectories=-/media
InaccessibleDirectories=-/root


[Install]
WantedBy=multi-user.target




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


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

[systemd-devel] really strange behaviour after using machinectl shell

[Michał Zegan]

Hello.

I encountered a really strange behaviour, and I am not sure if this is 
kernel, systemd or arch specific. Could you please try to explain to me 
what happens there? Here it is:
I log into gnome desktop using the x server, x erver is running on tty2, 
everything works. I run a terminal emulator.

In the terminal I say: machinectl shell
I enter my password and I log in as root/gain a shell. I type exit to 
exit shell.
I press ctrl+c at the bash prompt after leaving root shell. result: x 
server is killed/interrupted, probably receives the sigint signal as if 
the tty driver regained partial control over keyboard.
Like, the gui works properly at least keyboard does (I am blind so I 
don't know if the screen does not switch to a text mode), but pressing 
ctrl+c probably goes to the vt and so interrupts the foreground process 
there, the xorg x server.

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

Re: [systemd-devel] checking predictable interface names

[Michał Zegan]

It seems that it works, and also seems that it does not require udev 
itself to be running with support for this although i am not sure. just 
that the way of making such a test is not obvious, unfortunately.


W dniu 19.10.2015 o 16:49, Colin Guthrie pisze:

Michał Zegan wrote on 17/10/15 20:32:

Hello.
On non systemd systems, or on systems with disabled ifnames, is it
possible to somehow check what would be the interface name after rename
by default?
I would need this for example in case when I installed a system into a
chroot environment, while the host is for example not a systemd system,
and I want to configure network because I will have no other access to
the newly installed os after reboot.

Does this work for you?

udevadm test-builtin net_id 

?



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

[systemd-devel] checking predictable interface names

[Michał Zegan]

Hello.
On non systemd systems, or on systems with disabled ifnames, is it 
possible to somehow check what would be the interface name after rename 
by default?
I would need this for example in case when I installed a system into a 
chroot environment, while the host is for example not a systemd system, 
and I want to configure network because I will have no other access to 
the newly installed os after reboot.

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

Re: [systemd-devel] What I think is really wrong with systemd

[Michał Zegan]

W dniu 16.09.2015 o 15:08, Martin Pitt pisze:

Michał Zegan [2015-09-16 14:41 +0200]:

I actually believe that debian does some splitting, for example pam-systemd
module is in a separate package. Actually I feel that particular case is
wrong, but it happens there. I mean debian jessie, of course.

FYI, this is required for supporting Multi-Arch, it's not wrong.


Actually I was not quite right, I think that what annoyed me was that 
the pam_systemd module was not installed by default.


Debian does split the package quite a bit, yes. All libraries, their
-dev packages, and libnss*/libpam* need to be separate binaries, and
udev and systemd-sysv need to be separate for supporting other init
systems still. We also recently split out "systemd-container" for
nspawn/machinectl/importd etc. so that we can enable all features
without introducing big new dependencies into minimal systems.

Martin


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

Re: [systemd-devel] What I think is really wrong with systemd

[Michał Zegan]

I actually believe that debian does some splitting, for example 
pam-systemd module is in a separate package. Actually I feel that 
particular case is wrong, but it happens there. I mean debian jessie, of 
course.


W dniu 16.09.2015 o 12:30, Colin Guthrie pisze:

I wouldn't normally grace such rants with a reply, but I'll try and keep
this one short.

dott...@gmail.com wrote on 16/09/15 08:47:

Hi, sorry for another rant, but I'm a software developer and a user of
a Linux-based operating system here.

I read the post about at 0pointer.de about "myths about systemd". [1]
I want to address the issue of it being monolithic.
More specifically, I want to tell what where is that coming from.

systemd started an an init system. It had an idea of doing one thing
"the proper way" - of system init on Linux-based systems.
That made the project easy to understand and follow.

Now, as was written in that post, the project consists of over 69
binaries, where most of them are entirely optional.

The problem with this project is not how it is written.
It is how it is *packaged and distributed* to end-users.

Luckily, I use Gentoo. I have Portage, which will happily compile the
package on my system and I can tell it by USE flags what to compile
and what not to. Other package managers doesn't work this way. They
fetch *pre-compiled packages*.

So basically you're complaining to the upstream systemd project about
how downstreams consume it?

You should really take this complaint to downstreams.


Now, what is the PACKAGE "systemd" doing? Init? Is it a HTTP server?
A system logger? Something that uses QR codes? Can I replace it with
another package?

The answer is: no one but the developers know.

Not true, the developers know, but also the downstream package
maintainers know too - or at least they should know. It's their job to
decide which components to use to build their operating system.


The package doesn't even have an understandable version numbering. It
is one increasing number. How is a package maintainer supposed to know
if version change from 340 to 341 introduces major changes? I don't
even know *what* changed unless I read a ChangeLog.

Package maintainers are *expected* to read the changelog. This isn't
some minor part of the operating system we're dealing with. These are
the key building blocks that make up the very base of the userspace
layer. If I'm using a distro, I want my package maintainer to at very
least read the changelog, but ideally be much more informed than even that!


Normally, you have a major version and a minor version. If the major
version changes, it is an alarm to do throught testing to see if
everything works wellon the new one. Minor changes are minor, so they
require less testing.

Minor, major etc., this doesn't matter. Even minor changes can introduce
major bugs. The fact that someone arbitrarily decided "this is a minor
change" doesn't make the change safe in any way. Testing of such key
components should be the same regardless. Adopting such a scheme in a
project like systemd serves no purpose but to create a fake illusion of
"safeness".


What this project needs is division of this one big have-it-all
package into individual packages, each containing components for a
specific purpose. There is nothing wrong with them depending on each
other, but they should be in different packages, each having a
separate build system and version, for the following reasons:

1) You as developers are more aware of what changes in the project,
beause commits are associated with individual componenets.

They already are, both in the commit message and simply by doing "git
log" in the appropriate folders.


2) If a component was a failure, you can just drop
the package and work on another - nothing else needs work.
Most importantly, the main component is not touched.

This can still happen and is irrelevant to how the git repo is structured.


3) The people that are not involved with the developement are more aware
what the suite of packages called systemd is actually composed of.
Package maintainers can now block one component if there is
something wrong with it, but not all the others.

If this is how downstream want to work (i.e. provide competing
component) then they can package things that way if they like. Doing it
upstream has no purpose other than adding overhead.


4) The user can then install the init system from systemd, and keep
their system logger. Example: systemd-logind should not pass the
messages to another logger. The other projects should be encouraged
to use systemd APIs/ABIs on Linux to get them.
This makes systemd-logind more lightweight.

This shouldn't really be about user choice, but distributor choice.
Distributors are welcome to package things as they wish within the basic
constructs.

Your example doesn't make sense. systemd-logind already does not pass
message to another logger, it uses the journal exclusively.


5) Most importantly:

Re: [systemd-devel] hostname can be changed without permission checks

[Michał Zegan]

Okay, You seem to be right. Didn't notice that.

W dniu 12.09.2015 o 05:31, Michael Chapman pisze:

On Sat, 12 Sep 2015, Michał Zegan wrote:

Hello.

It seems that I am able to change a hostname with hostnamectl 
set-hostname name without any problems, even logged in as 
unprivileged user, and I did not get any authentication requests.
I did not modify polkit rules to allow this, not sure about the 
default ones, but they probably shouldn't allow that, just checked 
that implicit rules are auth_admin_keep, arch does not have vendor 
rules and I also do not have my own..


Did you check both /etc/polkit-1/rules.d/ and 
/usr/share/polkit-1/rules.d/?


On my system (Fedora), gnome-control-center has added a rule to the 
latter directory to allow a local user set the hostname, locale, etc., 
if they are in the "wheel" group. Perhaps you have something similar?


You can test whether PolicyKit is allowing the action with:

  pkcheck --action-id org.freedesktop.hostname1.set-hostname \
--process $$ --allow-user-interaction

If this exits successfully, then it's something in your PolicyKit 
configuration allowing the action, not systemd.


- Michael


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

[systemd-devel] hostname can be changed without permission checks

[Michał Zegan]

Hello.

It seems that I am able to change a hostname with hostnamectl 
set-hostname name without any problems, even logged in as unprivileged 
user, and I did not get any authentication requests.
I did not modify polkit rules to allow this, not sure about the default 
ones, but they probably shouldn't allow that, just checked that implicit 
rules are auth_admin_keep, arch does not have vendor rules and I also do 
not have my own..

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

[systemd-devel] containers again

[Michał Zegan]

Hello.

Before you stated that containers are not a security feature right now. 
It is required to manually shift uids/gids on images etc.
What are other known problems with containers that use ALL namespaces? 
Like if not counting the problem of uid allocation and manual shifting 
of them.

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

[systemd-devel] containers

[Michał Zegan]

Hello.

Is systemd-nspawn intended to eventually become usable for full system 
containers/general use with enough security to run things like vps 
hosting? How much is missing to be able to do that, or maybe it already 
can? Like you have user namespaces support that probably adds more 
security in addition to other namespaces, not sure though.

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

Re: [systemd-devel] Controlling user processes with systemd+cgroups

[Michał Zegan]

if you would override the slice in the unit file using override files it 
would not work?
Also not sure, I think I understand the question as "how to create 
cgroup per user group" but well, I may understand it wrong.


W dniu 06.09.2015 o 17:25, Lennart Poettering pisze:

On Sun, 06.09.15 17:05, Michał Zegan (webczat_...@poczta.onet.pl) wrote:


Well, actually I believe you could mess with unit configuration overrides,
couldn't you?
I was experimenting once by giving the user test 1% of cpu using cgroup
controls.

Well, you can of course configure limits on individual sessions,
per-user and for all users combined, by using "systemctl set-property"
on the session scope unit, the per-user slice unit, or the
"user.slice" unit, respectively. However, what Benjamin tries to do
(as far as I understood it) is to introduce groups that combine the
resources of multiple users into one, and can have limits on
them. Now, the slice concept would allow that, but there's no nice way
to tell logind to place specific users in specific slices, they all
end up below user.slice and that's it.

Lennart



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

Re: [systemd-devel] Controlling user processes with systemd+cgroups

[Michał Zegan]

Well, actually I believe you could mess with unit configuration 
overrides, couldn't you?
I was experimenting once by giving the user test 1% of cpu using cgroup 
controls.


W dniu 06.09.2015 o 16:14, Lennart Poettering pisze:

On Thu, 03.09.15 14:57, Benjamin Rose (benr...@math.princeton.edu) wrote:


As far as I can tell, systemd-logind when included through PAM, only makes a
cgroup like "user-" under the user slice. But I am looking to make this
based not only on user ID, but also group ID. Is there any way to achieve
all of this within systemd?

This is currently not possible, but certainly something we'd like to
cover eventually. The way we'd like to see this implemented someday
though is through an extensible user database that actually would
allow us to attach slice information to a user directly.

Currently, because we have no way to store nicely for each user which
slice it shall be attached to we will attach all logged in users to
the same "user.slice". In an ideal world, where the user database is
synchronized from an LDAP server the slice information belongs onto
the LDAP server as well. However, there's no commonly accepted
implementation and API for this on Linux, which we could use to query
such an additional user field from logind.

Ultimately our goal is that you build your tree of slices, and then
freely attach users, services, containers, VMs to these slices at the
places you want them. You can already do that nicely for services and
containers (at least for nspawn containers), but for users this is
really missing.

Sorry,

Lennart



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

[systemd-devel] machinectl shell problems

[Michał Zegan]

Hello.

I have a kvm vps running archlinux with systemd-225, I have just 
upgraded systemd and probably restarted most of the systemd components.
I am trying machinectl shell from my ordinary user session over ssh. it 
gives me the possibility to authenticate as admin, then says that it 
connected to the local host. But, it disconnects immediately.

The message in the journal says:
container-shell@5.service: Failed at step STDIN spawning /bin/sh: No 
such file or directory


Is it my fault or a systemd bug?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] terminals not appearing

[Michał Zegan]

I have actually reported this as an issue on github.
From the later conversation via issue comments with Lennard I have 
discovered that brltty is holding the /dev/vcsa open, interfering with 
tty autoactivation logic.


W dniu 24.08.2015 o 12:08, David Herrmann pisze:

Hi

On Tue, Aug 18, 2015 at 11:55 PM, Michał Zegan
 wrote:

Seems like this does not apply. I said that terminals do not start, and this
is random, sometimes they do. n_auto_vts = 6.

Can you provide more details about this? How do you reproduce it? What
are you running on your machine? What other graphical and/or text
console do you run?
Please be as specific as possible!

Btw., if you run a graphical login on a VT, then there might not be
any getty appearing on it for as much as 90s. So please try whether it
works after 90s.

Thanks
David


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

Re: [systemd-devel] SElinux in container

[Michał Zegan]

Unfortunately, SELinux is not namespace/whatever aware and such a setup 
is not possible. Unless I suddenly became wrong in this area.


W dniu 23.08.2015 o 14:10, arnaud gaboury pisze:

Here is my setup:

Host:  Archlinux systemd 224-1
Container: Fedora 22 systemd 219

The container is a server and has vocation to be one day deployed on a
dediacted server for production. In this way, I would like to set
SElinux (default in Fedora). Unfortunately, doing it in Arch host is
not a trivial affair and as host is a desktop, I would like to avoid.

For now, SElinux is enabled in the Kernel with disables at boot with selinux=0.

Is there any way to enable and configure SElinux only in the
container? Looking at capabilities(7) did not give me any hints. As a
side note, CAP_SYS_MODULE does not work for container. I guess it is
due to systemd 219 on the container ?

Thank you.



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

Re: [systemd-devel] user/session buses

[Michał Zegan]

Ahm, I understand, Although it's actually a pitty. I believe it could be 
useful in some cases notably remote login, not quite sure though.



W dniu 22.08.2015 o 16:58, Mantas Mikulėnas pisze:


Well, you just wouldn't have more than one graphical session. That's 
part of the general plan afaik.


Note that this is already half-broken, because some of those programs 
actually *expect* to be unique *per user* – e.g. dconf-daemon for 
writing to the dconf db – and having two copies of it in two sessions 
might be bad…



On Sat, Aug 22, 2015, 13:36 Michał Zegan <mailto:webczat_...@poczta.onet.pl>> wrote:


Hello.

I believe, although may be wrong, that session buses were used to
enforce single instances of programs, like a program registered a name
on dbus and another instance of the same program could not run.
How would it affect user buses in case of multiple graphical user
sessions?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
<mailto:systemd-devel@lists.freedesktop.org>
http://lists.freedesktop.org/mailman/listinfo/systemd-devel



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

[systemd-devel] user/session buses

[Michał Zegan]

Hello.

I believe, although may be wrong, that session buses were used to 
enforce single instances of programs, like a program registered a name 
on dbus and another instance of the same program could not run.

How would it affect user buses in case of multiple graphical user sessions?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Systemd --user and the role of DBUS API

[Michał Zegan]

I may not understand something, but how does it work when I have things 
like at-spi2-registryd running on my session? I cannot start one local 
and one remote gui session, for example? Of course I mean the user bus.


W dniu 19.08.2015 o 18:13, Simon McVittie pisze:

On 19/08/15 14:12, Mantas Mikulėnas wrote:

sd-bus has better performance and native
kdbus support (and a better API than e.g. dbus-glib), but if you're
writing programs in GTK or Qt or EFL, then you'll still want GDBus or
QtDBus or Eldbus.

To clarify, *everything* has a better API than dbus-glib. libdbus, the
low-level reference implementation that is described as painful by its
own documentation, is better than dbus-glib. Please don't use dbus-glib.

If you don't care about portability beyond Linux, sd-bus is essentially
a better libdbus; if you do care about portability beyond Linux, sd-bus
is unsuitable.


The current devel branch (1.9.20) of dbus-daemon installs the
--user units dbus.socket and dbus.service necessary for this.

It only does that if you configure with --enable-user-session. It is
currently opt-in, because it changes the semantics of how the OS is put
together, and some people seem to feel very strongly about the
historical per-login-session buses. I might swap the user bus from
opt-in to opt-out in 1.11 or 1.13 or something. On Debian and its
derivatives, installing the dbus-user-session package has the same
effect as --enable-user-session (and I'd encourage other general-purpose
distributions to use similar packaging).

dbus 1.9.20 is about to become dbus 1.10.0 with only trivial changes, so
a stable branch with optional user-bus support is (finally) around the
corner.


The user bus address is

... tried by default in libdbus 1.9, GLib 2.45, and sd-bus; so you don't
need to set DBUS_SESSION_BUS_ADDRESS at all, unless you need
compatibility with older versions, or reimplementations like dbus-sharp.


(Technically the same can be done with dbus 1.8.x as well, but AFAIK the
developers do not approve.)

We don't add features in stable-branches, particularly features that
change semantics, so libdbus 1.8.x does not have the necessary code
changes to make the right things for a user-bus happen by default. You
can backport them, at your own risk; or you can just parachute in the
dbus.socket and dbus.service files and not make the code changes, but
then setting DBUS_SESSION_BUS_ADDRESS appropriately is your responsibility.



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

Re: [systemd-devel] terminals not appearing

[Michał Zegan]

Seems like this does not apply. I said that terminals do not start, and 
this is random, sometimes they do. n_auto_vts = 6.


W dniu 18.08.2015 o 20:28, Philip Müller pisze:

Am 18.08.2015 um 20:24 schrieb Michał Zegan:

Hello.

I have the newest arch, systemd version 224.

The thing that I wonder about is that sometimes, when I press
ctrl+alt+f1..f6, ttys do not appear and I do not see the login prompt.
Like there is an initial tty1, but when I start a gui, it is freed.
Other ttys often just do not appear.

Sometimes the wiki helps here:

https://wiki.archlinux.org/index.php/Systemd_FAQ#How_do_I_change_the_default_number_of_gettys.3F

greez
Phil

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


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

[systemd-devel] terminals not appearing

[Michał Zegan]

Hello.

I have the newest arch, systemd version 224.

The thing that I wonder about is that sometimes, when I press 
ctrl+alt+f1..f6, ttys do not appear and I do not see the login prompt.
Like there is an initial tty1, but when I start a gui, it is freed. 
Other ttys often just do not appear.

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

Re: [systemd-devel] network configuration

[Michał Zegan]

Well, actually, are things like ip rules never used?
It could be a specific use case, but is this a category of never used 
stuff, or legacy stuff? I do not use them myself, but I am curious.


W dniu 16.08.2015 o 15:09, Lennart Poettering pisze:

On Fri, 14.08.15 19:50, Michał Zegan (webczat_...@poczta.onet.pl) wrote:


Actually what is a procedure for more complicated network
configuration, where you do not have something in networkd?

Well, we try to cover a good chunk of the usecases, but we want be
conservative when exposing options, to make this not more complex and
overwhelming than it already is. For example, options people never
actually use or that are clearly legacy don't need to be exposed.

Lennart



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

Re: [systemd-devel] possible kernel crash on bootctl install, can anyone confirm?

[Michał Zegan]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

May be, I asked systemd folks to confirm because this may or may not
be specific to something systemd does internally when modifying them.
I didn't get anything on efibootmgr, and I also didn't try again to
use bootctl install, I just created entries with efibootmgr.

W dniu 2015-08-14 o 19:45, Mantas Mikulėnas pisze:
> On Fri, Aug 14, 2015 at 8:42 PM, Michał Zegan 
> mailto:webczat_...@poczta.onet.pl>>
> wrote:
> 
> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1
> 
> Hello.
> 
> I was trying to install archlinux with linux 4.1, systemd-224 on
> the uefi machine. At the end of system installation, I issued
> bootctl install command from within chroot, but the command has
> failed because I did not have access to efi variables. After that,
> I have done: mount -t efivarfs efivarfs
> /mnt/sys/firmware/efi/efivars (the mountpoint path may be wrong but
> you get the idea) And, after the next bootctl install, the system
> froze. I am blind and didn't ask anyone what happened, but I
> believe that the kernel panicked. Is this related to mounting
> efivarfs two times and modifying variables, or what? I do not have
> any vm to test it on, well. Can anyone confirm that something like
> that happens either normally or when mounting efivarfs twice?
> 
> 
> This might be a bug in 4.1's EFI variables handling... A few people
> in #archlinux, including myself, have noticed crashes if the
> efivars are accessed after hibernate & resume (on first try,
> efibootmgr segfaults; on second try, the kernel panics). I haven't
> gotten around to reporting it yet.
> 
> -- Mantas Mikulėnas mailto:graw...@gmail.com>>
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBAgAGBQJVzi30AAoJEHb1CzgxXKwYhsgP/34RqtNYRJkQ3KKbvo9UXIZh
uzvaGQMW31GBHONxcwJRltk9aRYa3gkqJBNcpZTKXgH/jsjc997fMR7nXlKyZ6gX
8AbGDTmutxXM6/LsLzSO4KXCDBOXYgG8Gfzai9U+i08t8oktHeMTgFpZyq/Jv2jq
Y4HhK9PiqdInNt+voteUzR0Q6DpmndLqQDjpJrApxKz59wN5wQYejm4+CoqcXOMs
bAT6nbKC2oDFs9SOVP1qVNx5oY/jb07gQfMLlTe3wu06/6EfEK4G5Pzj20JVWJtf
sTXXXyx7Fm/ykhLi3Yw6yypBnneQh9a35SLOCCDScVWshS+bc8hiGJap4kQV0mnh
utTuRXe6ns9KlOkuI56+1KMohw7FWcC46d/V2R6wiZKT2fTEfiAVIJlR5NGctrqw
vkZOc7Pa4SQhn/a/V26R51RirpeWT0CHvib5BIFpd57wgeTUQo+AH68DdStnLj/V
EPE/tbetlduIvLyDWVRpFMVmd826Jf0eNmZL5VnqVtHPV71b/0qu6R4anDxZ5EtQ
nJ/3WenYINXUanVj5cepz2Ta/e9Kpm/abTWE/l/yC+rE42s8x6aQYd4BYOqp7K1m
7ElALMIbsHckjQGizXB5gB82HPHBkbHIXw+XA47QwV9Bv2DmB4E4asiBIYZRle1i
ZfxfwaIl8eY7EZoG/9YS
=M2UL
-END PGP SIGNATURE-
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] network configuration

[Michał Zegan]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Actually what is a procedure for more complicated network
configuration, where you do not have something in networkd?

W dniu 2015-08-14 o 19:33, Lennart Poettering pisze:
> On Sun, 09.08.15 18:23, Michał Zegan (webczat_...@poczta.onet.pl)
> wrote:
> 
>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1
>> 
>> Actually everything should be settable that can be done with
>> ip-route and ip-address and stuff... And ip-rule, by the way. 
>> But, no. Source= parameter in route sections is for source based 
>> routing without adding rules, not to set a preferred source ip 
>> address. Checked/tested.
> 
> We generally try to avoid exposing every possible option, but only
> the ones that people really use and make sense to support. What
> you suggest here probably does make sense to add, hence please file
> an RFE bug in github, and we'll eventually add it. Even better:
> send a patch!
> 
> Thanks,
> 
> Lennart
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBAgAGBQJVzipJAAoJEHb1CzgxXKwYdtMP/3FsU/o5/GWiWZ7KGPgJMgC5
lAd2O5NjdCIXjwxH6yaCvrDrKGMPVqRUWpqusTMxhgXSId+7MkFuGseJG4+mEYY5
KtxrqIIzZDsrhAra6FduzBifiTnD/N51+uds1r5g4yU0oQDNb5opKjO6uClwpo6K
Eth2ebTFMqe2ijGMfScEm02P5l9VvWY8u7pdAXqffjVNlLkLAO+8VdWFLljJhjqc
SGEJhX42E9+67x6vS7tYigFEcM1H6PftvOeayAlK/A9NVcRSHo9YnrRFW+Tcig2F
lur9dP2/ZVW06DpJWxx4kDvOuKqw5hnM/O+0Xck6mCauGgF8yEoemgsoRWjEOCBB
jsHEdlCLWoAPgDQQ6ywwEZ25e2TDkA/53hfrg8lA4o5Hn0oYS+sy6C39v64uJVgD
S+8+CRQjzjtGF2Xxu6x3GTRvlhdAKb/jSIC6qCQ7AaHzOqN6yZQ7Bo8rp1mu/eCx
jb+JR4P/ext+PX93Q91YqOwmv6sqnCrxLwdUn0qHRyyr0OzLpw7EDz6fIhZkg494
MifKvgCGqwA6Q8u9kZFwOLgyemkQ0fa6A+33YqcmgaUmKcFsrXjGVWeeL6iohlCV
Iua85N2Ogl/LfeE5NWp+kFP6e1DgLFO2J4/KVdF3mYfzkNvNCHFrCa3AQYHBAJDp
qQ7T8ihJcM3EAmLDWypm
=YHEv
-END PGP SIGNATURE-
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] possible kernel crash on bootctl install, can anyone confirm?

[Michał Zegan]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello.

I was trying to install archlinux with linux 4.1, systemd-224 on the
uefi machine.
At the end of system installation, I issued bootctl install command
from within chroot, but the command has failed because I did not have
access to efi variables.
After that, I have done:
mount -t efivarfs efivarfs /mnt/sys/firmware/efi/efivars (the
mountpoint path may be wrong but you get the idea)
And, after the next bootctl install, the system froze. I am blind and
didn't ask anyone what happened, but I believe that the kernel panicked.
Is this related to mounting efivarfs two times and modifying
variables, or what? I do not have any vm to test it on, well. Can
anyone confirm that something like that happens either normally or
when mounting efivarfs twice?
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBAgAGBQJVziiQAAoJEHb1CzgxXKwY9MkP/0lCTt80maAOrDpIaidioNC6
i+Iio0IzKEe4JV1hEUl7ZDKZdG0d44JMTNBgoOhKCRucXmWUsCuG52B8CukqDKoj
/mWbkVB2rcoejMKGBdly9uaSBehtOeneouDP+FN6erckvGzS1y643n49ZnSv1vrr
Q6nY/DpJyNfmMwv+dWYB3CKTXASRY6GTbLUrwOd39GDZNRexgAIvduClc89qeAu4
sPWgs1zbaHdJPDtFxkrDazHTasRq1tDUTgFYZM0TC9aKsTBoLZQ06XjlwdieZ+ZN
L/AE51xDfA2t/xSE0ImXJy9gYOglJiRV1rvJdAiQKtwBSHe9JrOhYDH6p0p80T14
sHTML3V/PMUlzrAfIcQ6AhBtouLuNBxEV9YzF4D5Mf4e3A7p8pJZec8BW+ey4Yvq
0Q0rG8W3VlYM0/ySP7mI1UAJPrslNig0OFEod2ABri3zP1k0IEQ+zIFCf+F2PrKE
Ps0L3+wuQeyNkGfwP1dNECUyqj5XWKgmqPR4xSD5vuneJJMiRKQj9YFPV+ajkgjD
y0FPQunB09zq4fziTrz0bT3cqPgPiyRvodLuCUvQ3LHUALP8UHO0ONVQ0joYuFCH
9U1lzsktkLtDJFfINAOkX5dV0jO/mtDFqiFwv8/2REe/FU0ncLqJfxymWhs53iXj
NGKXXSykQ7dW6s1J7BBy
=M3na
-END PGP SIGNATURE-
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] network configuration

[Michał Zegan]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Actually everything should be settable that can be done with ip-route
and ip-address and stuff...
And ip-rule, by the way.
But, no. Source= parameter in route sections is for source based
routing without adding rules, not to set a preferred source ip
address. Checked/tested.

W dniu 2015-08-09 o 18:21, Tomasz Torcz pisze:
> On Sun, Aug 09, 2015 at 05:58:40PM +0200, Michał Zegan wrote:
>> 
>> It seems that systemd-networkd can not handle any kind of
>> advanced network configurations, that is: It cannot handle policy
>> routing and additional routing options like setting a src
>> address,
> 
> What about this: [Route] Section Options
> 
> Source= The source prefix of the route. […]
> 
>> It does not ensure address ordering (if I have two addresses on 
>> interface, which is first and which is second?)
> 
> You can file enhancement request on GitHub.  I guess you want FLAG
> from "man ip-address" to be settable
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBAgAGBQJVx36TAAoJEHb1CzgxXKwYn0AQAKk5SEwpZ7D0XOLMLMUOi/Ih
s5tMdWMlChtqzfIdVZio6ntoezl4OfsTAqmuO/r7Q2/9aNik/iwCreNTi8pAF3CL
u8IM7IFpwvj+yW900MCpkwaop6FN2oefKUo4B+hn6Vz2bxM8IA2AGOce9acfGmFW
IFbqYp1gTCakynIHYRbTinKemWtSGxdM+d3eOFq1HDX77NPZlvYRF/wp7L0R23L8
2HFESnU2yKvzAzTDyULleNb67X7C/0w20i4nBFyJzFLnNOD1rIfpYDz+MjrYHJIT
kRySiX5Jhxc4Ae92EJoibsD7uSch8BQ2mjvC42eegZySDJxaAKnnuVcRbdWRwoqv
Osl/0XN4a4bt6e/D3q+tGSe922XiL4vhWxCPJUJ1OC2PHUeSPOXJEmCcffBm5D7f
WrRuqMNivpUPm54BGEHVezDwHXMRWoUWI8c4JtCNjT+6Cja0Dl8L2aG20zLJOPvN
cKxWDZgpMWjYZdbAV6WIq7/Re4FH3/QgAIlEgAuRlH8/Oj8nH+H2CXoYZnUv4F4b
Pn2FIZyUSEYKe6vpVUsVrHMvR8p8s0eJsS1puSLEVExI4Bz8pNINUBgmDNMUoL6E
wNseLnkVFSXURAaxSbUy6/ifflEYVdy3DLMEgCch4EajBpyRPY0RJyTgXji8OewM
l8UPy4ysPOg9Hpg4QWVK
=Czl4
-END PGP SIGNATURE-
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] network configuration

[Michał Zegan]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello.

It seems that systemd-networkd can not handle any kind of advanced
network configurations, that is:
It cannot handle policy routing and additional routing options like
setting a src address,
It does not ensure address ordering (if I have two addresses on
interface, which is first and which is second?)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBAgAGBQJVx3iuAAoJEHb1CzgxXKwYD1sQAJpG+BSlLEU6S5yP3Ibnkm2e
arA8I90lvgQmf4HGQ01kDehTZX790eDiwDBPd1WN4TnjJ2W5sZCOwVV5SKxIOVzj
sz2tI+0FIMJPnqmrLT9S9HBdvcjAWVrYVBWwgwW1ZkDsfJjwsZFdbY1rZcZzbTK+
Hg+teipEbXsvgIThWfUgjp0wTgruoR/IHqZD/bowdkfl61G6rYfsNSln+nacxqyK
pFSLsut9xxJOhmuafLagRUmCyzkXONiQtGbBmcBYWvygfoiDxKwUhjtgUSLoqKFe
71hnHhkSO8m42Y3rbgdW7ZV1OK/iDd15wkIX0EBIn+okpB09+XXujFT5tftdysK+
XTk47+0kJT/pYQ6QiMnth0yCbTOHeU+1WxnhVnAzvvSxQe3q33F2c5wqgQJQJ3nr
0yeV+wwr1po9JCMANFzoVkDD6XQkEg1in06Y789K780wU8OqllOfhxKYOAGOXKQR
oNW8jEeHs8413HD0rWKuGfhgOvleuEj5As2TP7+QFYui5Q5vgkQz9gIjekmpEZLt
Oex8u61NM+O5oko/yW8nkibXtboBpogMoZd6kEBkpFPL2oPiREIB9u+GXKN5QzUT
clXREAj8+iZq/Qft3edfmBLfhHrapzTqT47v6Bx6TaBDYBcpwPgzh6FqawwNqNuk
djUSD7Tc6mk0J/y9X9RE
=sLom
-END PGP SIGNATURE-
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel