Re: [systemd-devel] Some Questions About Systemd and Dbus-daemon

[Lennart Poettering]

On Mo, 30.03.20 21:28, 海阔天空 (858293...@qq.com) wrote:

> Hi everyone,
>
>
> I have some questions and I'd like to know if you can help to answer them.
>
>
> 1. What is the relationship among systemd、dbus(libdbus,dbus-daemon)
> and dbus-broker?

dbus-broker and dbus-daemon are two different implementations of the
same thing: a D-Bus message broker daemon. Pick one.

systemd needs a D-Bus message broker to operate sanely. (in very
limited setups, most early boot envs, you can get away with no dbus
broker, but it's not realistic in anything non-trivial).

> 2. Does systemd rely on dbus-broker(dbus-daemon) or vice versa?

Yes. systemd as the dbus broker if your choice have a symbiotic
relationship: systemd starts the dbus daemon, and connects to it as
one of its first clients, and dbus daemon uses systemd to activate
services if needed.

> 3. Is org.freedesktop.DBus generated first or is dbus-broker started
> first?

org.freedesktop.DBus is a synthetic service that is impemented by the
broker daemon of your choice, internally, as part of the D-Bus
protocol. it always exists as long as the broker is running. See dbus spec.

> 4. Does org.freedesktop.DBus rely on dbus-broker or vice versa?

It's an implementation detail of a dbus broker daemon. it is how the
broker daemon exposes its own APIs to clients.

> 5. What is the usage of dbus.socket?

It's the socket unit that encapsulates the AF_UNIX socket clients use
to communicate with the dbus broker daemon.

> 6. If I use systemd and dbus-broker only, does this mean that I can
> abandon dbus(libdbus,dbus-daemon) instead of rely on it?

yes. Pick either dbus-daemon or dbus-broker. They do the same thing.

Note that some other apps link to libdbus though, hence it's unlikely
you can totally give up on the codebase of libdbus/dbus-daemon.

> 7. I'd love to know the relationship of systemd and dbus, also the
> internals of systemd. Is there any materials you can share?

Well, there are the sources of systemd. It's very low-level stuff,
there are no explicit docs about this.

Lennart

--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Stateless system - Centos8 and overlayfs on root

[Lennart Poettering]

On Fr, 27.03.20 10:17, Preston L. Bannister (pres...@bannister.us) wrote:

> Looking for a sanity check from the folk how know more of systemd than do
> I. Not looking for someone else to solve my problem, but could use a clue.
>
> Trying to figure out how to get an overlayfs root mounted early in boot.
>
> Building an embedded system that must not store any sensitive data when
> powered down. Found this was referred to on this list more recently as a
> "stateless" system. (And Tobias Hunger seems to have the most to say. :) )
> We are using Centos8, with systemd 239. Starting point is a vanilla Centos8
> server installation to a small (8 or 32GB) flash volume.
>
> Had the (possibly) clever notion of using an overlayfs as the root mount,
> with a tmpfs as the upper, and the usual persistent volume as the
> lower.

Current systemd versions support this natively, just boot with
"systemd.volatile=overlay" on the kernel cmdline. Doubt this is in
centos8 yet, though.

Note that overlayfs is a weird fs, it has strange, non-posixy
semantics (inode nrs a fucked). It generally doesn't work as well as
people want it to work, and while you might get away with using it for
small, well-defined scenarios it's not suitable for complex, general
purpose systems to run as root fs.

"systemd.volatile=overlay" is a nice tool for testing and development,
and maybe some very specific setups, but it's not really something i'd
want to deploy in production in big scale.

> The  initial round of configuration and test would just be against a stock
> Centos8 install. Once fully configured and tested, would add a default boot
> menu item to boot with root mounted as an overlayfs, with the fully
> configured root volume as the read-only lower.
>
> Updates would be accomplished by booting from the original boot menu entry.
> (This is slightly complicated by the fact the target systems' computers do
> not have a console - but figure I can script altering the default
> boot.)

I doubt overlayfs is good enough to make this workable. In particular
not in the old version included in rhel8...

> BASE=/run/overlay_root
> OVERLAY=$BASE/merged
> ROOT_MOUNT=$OVERLAY/mnt/root
> mount -t tmpfs root-base $BASE ; mkdir $BASE/{lower,upper,work,merged}
> mount --bind / $BASE/lower
> mount -t overlayfs root-overlay $OVERLAY
> -olowerdir=$BASE/lower,upperdir=$BASE/upper,workdir=$BASE/work
> for d in boot dev proc run sys ; do mount --bind /$d $OVERLAY/$d ; done
> mkdir $ROOT_MOUNT ; mount --bind / $ROOT_MOUNT

systemd/pid1 will mount proc/run/sys/dev/… on its own after "systemctl
switch-root", no need to do that yourself.

> 
> This all seems to work. The overlayfs prevents writes to persistent media
> in usual places. Have a path to write to persistent media. The special
> directories (that do not work from mounts to lower on an overlayfs) work as
> expected.
>
> What I do not have as yet is a means to get the overlayfs root mounted
> early in boot.
> 1.  Does not look like /etc/fstab can create the overlayfs.
> 2.  Tried the "systemd.volatile=yes" kernel command line, w/o luck.
> Substantial commits between 239 and 245 around this.
> 3.  See systemd "pivot_root" and "switch_root", but not yet puzzled out
> usage.

Look what src/volatile-root/volatile-root.c in current systemd
versions is doing. It's relatively straight-forward. You can do
something similar with a shell script.

Lennart

--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Stateless system - Centos8 and overlayfs on root

[Tobias Hunger]

Hi,

You said no data is to be stored when powered down. What do you need
the overlay for then? Just mount to a tmpfs as '/' and centos as
'/usr', which is something that systemd supports out of the box. You
will need at least some files in /etc for this to work, and I just
have the initrd untar some file that I store on the /usr partition
into / to get everything into place.

You can also set up the root filesystem as an overlayfs in the initrd
if you want to go down that route.

https://gitlab.com/cleanroom/cleanroom/-/blob/master/cleanroom/commands/create_initrd.py
has the code I use to create an initrd for my systems (using
mkinitcpio from arch linux, but I am sure similar things are possible
with dracut).

Check lines 111 and following for a systemd unit that extracts a
tarball in the initrd before switching over to the real root.

I use simple filesystem images (containing an EFI, a squashfs for root
and a dm-verity partition for the root) in my setup. The contents of
the EFI partition is copied to the system EFI partition for this to
work. The other two partitions can be used in several forms:
 * dd-ing them all onto separate partitions (works out of the box;-)
 * dd-ing them into separate LVM volumes (lines 132 following in the
script linked above)
 * dropping the image file with a certain name into a folder (lines
152 following and 168 following)

I am pretty sure you can hook into the same places as I do for the
image file magic to make your overlayfs work... but then Fedora is
probably using dracut, so things might be a bit different. But then
dracut apparently also uses systemd in the back, so the boot up
process should be somewhat similar.

Best Regards,
Tobias

PS: Feel free to drop me a mail if you have questions about this topic
that you think are not appropriate for the wider audience on the
mailing list.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Dynamic .timer scheduling

[Lennart Poettering]

On Di, 28.01.20 10:46, Johannes Ernst (johannes.er...@gmail.com) wrote:

> Is there a best practice for scheduling .timers based on what happened in a 
> previous run?
>
> Pseudocode:
>
> while( true ) :
> delta = runService();
> sleep( delta );
>
> I can think of …
>
> 1) run the job frequently, but skip the bulk of its execution most of the 
> time (e.g. decrementing a counter saved somewhere)
> 2) have the job modify the .timer file at the end of each run (sounds … not 
> so great)
>
> There isn’t anything systemd “native” for that, right?

Consider just creating a transient timer unit via the D-Bus API from
your service code. Alternatively, use systemd-run for that, which can
do that for you from the cmdline.

Lennart

--
Lennart Poettering, Berlin
___
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

[Lennart Poettering]

On Di, 28.01.20 22:48, nerdopolis (bluescreen_aven...@verizon.net) wrote:

> Hi
>
> Sorry if this is the wrong place for this. I can't seem to find a system-user
> mailing list for this purpose on freedesktop.
>
> So I am curious about what CanMultiSession=no means, as I am able to start a
> Weston session on a secondary seat (eg seat1 if I set up the hardware with 
> udev
> or seat-pci-pci-_xx_xx_x if I use pci-bridge-seat devices on QEMU.
>
> These seats, since they don't have TTYs I guess say CanMultiSession=no which 
> is
> my understanding, however, I can start a second instance of Weston, and switch
> in between them fine, and Weston seems to respond to the sessions switching, 
> so
> I am not quite sure what is missing? Is it something else related to security?
> Or the kernel?
>
> Because as far as I can tell, I can start multiple sessions on these seats.

Hmm, so it currently just lets you know if the seat has VTs (which
only seat0 has effectively, if the VT subsys is enabled in the
kernel).

In the old days we only supported session switching on seat0, since it
was based exclusively on VTs. Later on David Hermann added support for
session switching without VTs, at which point the boolean was wired to
mean "has VTs". Maybe that was a mistake, dunno, and it should just
have returned true for all seats at that point...

Lennart

--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd-makefs with very slight data corruption ?

[Lennart Poettering]

On Mi, 12.02.20 19:19, Xogium (cont...@xogium.me) wrote:

> Hi,
> I am wondering about how to best implement a mechanism to recreate a specific
> filesystem in case of the slightest data corruption done to it. From what I 
> read
> in systemd-makefs manpage, the tool will not trigger if it can detect that a
> filesystem is already present. However I'm thinking that in some case, the 
> data
> can get corrupted, yet the filesystem still is reported as ext4 to makefs.
> Perhaps I understood wrong, in which case, could I somehow order 
> systemd-makefs
> to be ran only if either systemd-fsck fails, or if mounting fails ? This
> filesystem can easily get corrupted due to power loss, and isn't important for
> the entire system to work, however it would be nicer if this could be detected
> and delt with accordingly.

This is currently not supported. Consider filing an RFE issue on
github asking for this, this appears to make sense to me. I mean
systemd-fsck could just do what systemd-makefs does depending on the
exit code of /sbin/fsck...

Lennart

--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Antw: [EXT] Infinite loop at startup on var fsck failure

[Lennart Poettering]

On Mi, 26.02.20 10:39, Michael Biebl (mbi...@gmail.com) wrote:

> Am Mi., 26. Feb. 2020 um 10:13 Uhr schrieb Ulrich Windl
> :
> >
> > >>> Vito Caputo  schrieb am 25.02.2020 um 01:01 in
> > Nachricht
> > <7343_1582589314_5e546582_7343_4690_1_20200225000143.nowls5peec5sx...@shells.gnu
> >
> > eneration.com>:
> > > Hello list,
> > >
> > > Today I experienced an unclean shutdown due to battery dying unexpectedly,
> > > and it left my /var in a state requiring a manual fsck to repair errors.
> >
> > I wonder: Shouldn't be a fsck just be a journal reply these days? For ext 
> > >=3
> > this should be quite fast. ReiserFS was rather slow several years ago (it 
> > did
> > replay too much IMHO), but haven't used it the last five years.
> >
> > >
> > > The normal startup process failed and dropped me to a rescue shell after
> > > asking for my root password.  But I was unable to immediately run fsck
> > > manually, because systemd was endlessly trying to fsck /var.
> >
> > That's not a problem of fsck.
>
>
> I suspect that the real problem is, that fsck failed to fix the file
> system, so as a result, systemd tried repeatedly to start the fsck job
> for /var as var.mount was pulled in as a dependency (e.g. for
> journald).

The question is: why *repeatedly* though? i.e. why does it keep doing
that if nothing else happens? journald should not trigger that all the
time...

Also, there's actually a safety condition in place, the start limit
logic: after a service has been attempted to be started too often
within a time window we refuse starting it again...

So I am a bit puzzled about this. Some logs would be great to have
about this...

Lennart

--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] show journalctl while stopping?

[Lennart Poettering]

On Do, 23.01.20 10:32, Roger Pack (rogerdpa...@gmail.com) wrote:

> Forgive me if this is too naive, but would it be possible for
> systemctl to "immediately start outputting logs" (journalctl type
> output) while it is in the middle of running a command?  Ex: while
> running "systemctl stop my_server" it could show the logs so we could
> see what is going on?  I do miss that from the /etc/init.d days and
> feel so blind with systemctl now.

This has been on the TODO list for a while, but it wasn't trivial to
implement for most of the time, because of races: the log stream we
want to show and the stream of unit state changes are independant of
each other and fully asynchronous hence we never knew if all log
messages via the journal were already processed when we got notified
about the unit being fully down or fully up, i.e. we wouldn't know how
much longer to show logs before being done.

This has mostly been resolved in journald now, there's a way to sync
on the log stream, i.e. we could now issue the start or stop command
to PID 1, and then wait for it complete, and then issue a sync request
to journald that lets us know when all log messages enqueued up to
that point are fully processed, and then exit, so that we wouldn't
miss anything anymore. Now it's just a matter of putting this all
together.

So yes, it's on the TODO list, has always been there, and we are
inching closer to actually delivering it properly.

Lennart

--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Best practices for starting unit only if network is online

[Lennart Poettering]

On Mi, 05.02.20 13:23, Paul Menzel (pmenzel+systemd-de...@molgen.mpg.de) wrote:

> Dear systemd folks,
>
>
> fwupd ships the service unit `fwupd-refresh.service` with the ordering below
> [1].
>
> After=network.target network-online.target systemd-networkd.service
> NetworkManager.service connman.service
>
> I would have thought ordering after `network-online.target` would be enough.
> Are there best practices for ensuring that the network is working?

Well, who knows what "online" means... fwupd should really start
independently of all of this and watch network state on its own and
retry whenever state changes. IIRC glib even has an API for it.

These targets should only really be used for stuff that really really
needs the network, and where it's intended the boot process shall be
delayed for, for example if you mount /var or so from NFS. And maybe
for naive shell scripts that can't be bothered to do things properly,
but fwupd doesn't qualify...

fwupd.target should not list the various network management solutions,
that is unnecssary, and ordering after network.target should be
sufficeint to achieve the same, in a generic fashion. i.e. network
managers should order themselves before network.target, so that
ordring yourself after that automatically orders you after all
implementations at once...

Lennart

--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Ask some questions about overlay+/dev/mtdblock?

[Lennart Poettering]

On Mo, 02.03.20 16:21, www (ouyangxua...@163.com) wrote:

> Dear all,
>
>
> Systemd is used in the embedded system. and some mounting information is as 
> follows:
>
>
> dev on /dev type devtmpfs (rw,relatime,size=221372k,nr_inodes=55343,mode=755)
> sys on /sys type sysfs (rw,relatime)
> proc on /proc type proc (rw,relatime)
> tmpfs on /run type tmpfs (rw,nosuid,nodev,mode=755)
> /dev/mtdblock4 on /run/initramfs/ro type squashfs (ro,relatime)
> /dev/mtdblock5 on /run/initramfs/rw type jffs2 (rw,relatime)
> cow on / type overlay 
> (rw,relatime,lowerdir=run/initramfs/ro,upperdir=run/initramfs/rw/cow,workdir=run/initramfs/rw/work)
> tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
>
>
> I have a question, why can overlayfs directly save the information in block4 
> and block5 (such as the running information of SYSTEMd) after I uninstall 
> block4 and block5 with umount command？
> Who knows why, or gives some advice?

It's a feature of overlayfs that it keeps its own references to the
underlying file systems, and they can be unmounted while the overlayfs
itself stays accessible.

if you don't want that, unmount the overlayfs too?

Lennart

--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] crash with SECLABEL{selinux}="some info" syntax into udev rule

[Lennart Poettering]

On Do, 05.03.20 16:26, Valerii Chernous -X (vchernou - GLOBALLOGIC INC at 
Cisco) (vcher...@cisco.com) wrote:

>
>
> Hi Team,
>
> I have issue with SECLABEL into systemd udevadm 243 and I see that mainline 
> also have this issue.
> It look like Yu forgot initialize data into commit:
> 25de7aa7b90 (Yu Watanabe 2019-04-25 01:21:11 +0200
> 924)

Please post this on github as PR, thank you!

https://github.com/systemd/systemd/pulls

Lennart

--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Redirect logs from script to systemd's StandardOutput file

[Lennart Poettering]

On Do, 12.03.20 14:40, Ani A (aniruddh...@gmail.com) wrote:

> Hello,
>
> I am on Ubuntu 18.04.2, and I have systemd version 237. I have some common 
> tasks
> which need to happen prestart and poststop which I have moved to a
> script. All unit
> files look like:
>
> StandardOutput=file:/var/log/my-.log
> ExecStartPre=/path/to/helper.sh -t prestart -u 
> ExecStopPost=/path/to/helper.sh -t poststop -u 
> ExecStart=/path/to/my/exe
>
> where  is the name of the systemd unit file.
>
> I use systemd's directive to log stdout to file, and in the prestart
> and poststop actions also
> I try to write some logs to the same file with shell echo, like:
>
> echo "..." >> /var/log/my-.log
>
> The logs that is written by the script does not appear in the log file!
> Is there anything wrong here (missing something) ?

Please provide the full unit file.

Lennart

--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] DynamicUser and root:root/0640 configuration in /etc

[Lennart Poettering]

On Fr, 31.01.20 13:35, Igor Gnatenko (i.gnatenko.br...@gmail.com) wrote:

> Hello,
>
> I am writing systemd service for one software and I found out very
> nice thing that you don't have to create users just for the service
> and it can be done via DynamicUser in runtime.
>
> However, the software has configuration file in /etc/foo where
> sensitive credentials are stored so the /etc/foo is owned by root:root
> and /etc/foo/config is owned same way and has 640 permissions.

Hmm, but if the service is supposed to run unprivileged, how is it
supposed to be able to access that?

> If I use DynamicUser, it can't read /etc/foo/config due to
> permissions. I have tried to set ConfigurationDirectory=foo, but that
> does not change permissions on those files... After all I found
> SupplementaryGroups=root fixes the problem, but I think this destroys
> whole purpose of DynamicUser.
>
> Am I doing something wrong? Any suggestions how to deal with this?

Hmm, well, you need to somehow make sure your service's UID can access
these files, if you use such restrictive access rights under some
other user's UID, this cannot work of course...

You could have an ExecStartPre= line that copies the stuff from
$CONFIGURATION_DIRECTORY to $STATE_DIRECTORY, that uses the "!"
marker, so that it runs with full privs, and chowns the copy. That way
every time the service is started you make a copy that is properly
owned.

In the long run we should probably have some sane per-service
credential system, maybe via the kernel keyring, or passed memfds or
so, but so far this hasn't materialized...

Lennart

--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Infinite loop at startup on var fsck failure

[Lennart Poettering]

On Mo, 24.02.20 16:01, Vito Caputo (vcap...@pengaru.com) wrote:

> Hello list,
>
> Today I experienced an unclean shutdown due to battery dying unexpectedly,
> and it left my /var in a state requiring a manual fsck to repair errors.
>
> The normal startup process failed and dropped me to a rescue shell after
> asking for my root password.  But I was unable to immediately run fsck
> manually, because systemd was endlessly trying to fsck /var.

Hmm, looks like a bug. It shouldn't keep retrying. Something mst
have pulled in the unit over and over again...

Any chance you can reproduce this with current systemd, and maybe
provide logs and put them into a github issue?

Or do you have logs from the case when this happened around?

Lennart

--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Reasoning behind sd_bus_error argument to sd_bus_call?

[Lennart Poettering]

On Mi, 18.03.20 12:14, Daan De Meyer (daan.j.deme...@gmail.com) wrote:

> I completely agree that for errors returned by the service, a D-Bus error
> is a lot better. However, from what I understand of sd-bus, any errors
> returned by the service are encoded in the reply returned by sd_bus_call
> and you use sd_bus_message_is_method_error and sd_bus_message_get_error on
> the reply to get the actual service error. Where does that leave the
> sd_bus_error argument of sd_bus_call?

We *either* return an error and fill in sd_bus_error (on error) *or*
we return a reply msg (on success). i.e. you won't get an
sd_bus_message object from sd_bus_call() at all on error, hence
nothing you could look into with sd_bus_message_get_error().

Lennart

--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Configuration option to set the ownership of coredump files

[Lennart Poettering]

On Do, 27.02.20 21:19, P.R.Dinesh (pr.din...@gmail.com) wrote:

> Do we have a configuration option to change the ownership of core dump
> files generated by systemd-coredump?
>
> Mainly I would like to set the ownership group of the coredumps to a custom
> group.
>
> I am using systemd version 243.

What are you trying to achieve precisely?

Why ownership? You could just use ACLs do allow your group access to
the dir the coredumps are in...

Lennart

--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] making journald logs persistent on raspberry pi

[Lennart Poettering]

On Fr, 24.01.20 15:32, Dave Howorth (syst...@howorth.org.uk) wrote:

> It's quite common on the Raspberry Pi to make /var/log a tmpfs, in
> order to reduce the number of writes to the SD card that is the pi's
> main storage. That's quite acceptable for most logs but I'd like to
> make journald's logs persistent so I'll be able to investigate any
> problems that occur whilst booting or shutting down more easily.

Hmm, if you want volatile logging, use /run/log/...

It sounds strange to me, first making /var/log/... volatile, which is
kinda where the stuff goes that is supposed to be persistent and then
tryng to exclude stuff there again...

i.e. journald's Storage= setting most just allows you to choose
between /var/log/… and /run/log/… as data store.

Lennart

--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Portable service binding a system port

[Lennart Poettering]

On Fr, 07.02.20 11:05, François (francois+syst...@kubler.org) wrote:

> Hi,
>
> I’m finally answering my own question - well at least partially.
>
> I managed to identify the culprit : the `PrivateUsers=yes` directive.
>
> If I override it with a drop-in and set it to `no`, it works as expected and 
> I can successfully bind to port 53.
>
> But I still don’t understand why, especially since it’s part of the
> default profile.

Ideally unbound would support socket activation, so that PID 1 can
bind the socket and pass it in pre-bound.

PrivateUsers=yes means userns, and only processes that have
CAP_NET_BIND_SERVICE in the host user ns can bind on ports <
1024. PrivateUsers= user namespace do not have that, and hence cannot
bind the port on the host.

Portable service profiles are best combined with socket activation to
limit the privileged surface...

Lennart

--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Antw: [EXT] Re: show journalctl while stopping?

[Ulrich Windl]

>>> Lennart Poettering  schrieb am 31.03.2020 um 14:56
in
Nachricht
<2402_1585659382_5E833DF6_2402_244_1_20200331125612.GB27547@gardel-login>:
> On Do, 23.01.20 10:32, Roger Pack (rogerdpa...@gmail.com) wrote:
> 
>> Forgive me if this is too naive, but would it be possible for
>> systemctl to "immediately start outputting logs" (journalctl type
>> output) while it is in the middle of running a command?  Ex: while
>> running "systemctl stop my_server" it could show the logs so we could
>> see what is going on?  I do miss that from the /etc/init.d days and
>> feel so blind with systemctl now.
> 
> This has been on the TODO list for a while, but it wasn't trivial to
> implement for most of the time, because of races: the log stream we
> want to show and the stream of unit state changes are independant of
> each other and fully asynchronous hence we never knew if all log
> messages via the journal were already processed when we got notified
> about the unit being fully down or fully up, i.e. we wouldn't know how
> much longer to show logs before being done.

I don't know the internals, but most systems having problems to trace the
state transitions correctly only have "stopped"§ and "started" states, lacking
"stopping" and "starting".
For the log you'd capture everything between "stopped" and "started"
("started" and "stopped", respectively), meaning once the state ist "started",
"starting" has completed. (Similar for a failure). The other direction is
analog.

> 
> This has mostly been resolved in journald now, there's a way to sync
> on the log stream, i.e. we could now issue the start or stop command
> to PID 1, and then wait for it complete, and then issue a sync request
> to journald that lets us know when all log messages enqueued up to
> that point are fully processed, and then exit, so that we wouldn't
> miss anything anymore. Now it's just a matter of putting this all
> together.
> 
> So yes, it's on the TODO list, has always been there, and we are
> inching closer to actually delivering it properly.
> 
> Lennart
> 
> ‑‑
> Lennart Poettering, Berlin
> ___
> systemd‑devel mailing list
> systemd‑de...@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] question about a poweroff issue

[Lennart Poettering]

On Mi, 26.02.20 13:50, piliu (pi...@redhat.com) wrote:

> Hi,
>
> I encountered a systemd bug during saving vmcore for kdump kernel.
>
> I got the following message:
>
> [   60.283489] systemd[1]: Started Reload Configuration from the Real Root.
> [   60.290912] systemd[1]: Reached target Initrd File Systems.
> [   60.296162] systemd[1]: Reached target Initrd Default Target.
> [   60.299343] systemd[1]: Starting dracut pre-pivot and cleanup hook...
>  Starting dracut pre-pivot and cleanup hook...
> [  OK  ] Started dracut pre-pivot and cleanup hook.
> [   60.338320] systemd[1]: Started dracut pre-pivot and cleanup hook.
> [   60.340503] systemd[1]: Starting Kdump Vmcore Save Service...
>  Starting Kdump Vmcore Save Service...
> kdump: dump target /dev/mapper/rhel_storageqe--25-root is not mounted,
> trying to mount...
> kdump: saving to
> /sysroot//mnt/kdump_multi/var/crash/127.0.0.1-2020-02-20-05:00:45/
> kdump: saving vmcore-dmesg.txt
> kdump: saving vmcore-dmesg.txt complete
> kdump: saving vmcore
> Copying data  : [100.0 %] /
>  eta: 0s
> kdump: saving vmcore complete
> Bus n/a: changing state UNSET → OPENING
> Bus n/a: changing state OPENING → AUTHENTICATING
> Bus n/a: changing state AUTHENTICATING → RUNNING
> Sent message type=method_call sender=n/a
> destination=org.freedesktop.systemd1 path=/org/freedesktop/systemd1
> interface=org.freedesktop.systemd1.Manager member=Reboot cookie=1
> reply_cookie=0 signature=n/a error-name=n/a error-message=n/a
> [   66.032946] systemd[1]: Shutting down.
> Got message type=method_return sender=org.freedesktop.systemd1
> destination=n/a path=n/a interface=n/a member=n/a cookie=1
> reply_cookie=1 signature=n/a error-name=n/a error-message=n/a
> Bus n/a: changing state RUNNING → CLOSED
> [   66.060777] printk: systemd-shutdow: 350 output lines suppressed due
> to ratelimiting
> [   66.316784] printk: systemd-journal: 13 output lines suppressed due
> to ratelimiting
> [  156.506161] qla2xxx [:08:00.1]-fffa:1: Adapter shutdown
> [  156.535660] qla2xxx [:08:00.1]-00af:1: Performing ISP error
> recovery - ha=350c9f53.
> [  156.581142] qla2xxx [:08:00.1]-fffe:1: Adapter shutdown successfully.
> [  156.612816] qla2xxx [:08:00.0]-fffa:0: Adapter shutdown
> [  156.638997] qla2xxx [:08:00.0]-00af:0: Performing ISP error
> recovery - ha=7acbb643.
> [  156.681032] qla2xxx [:08:00.0]-fffe:0: Adapter shutdown successfully.
>
>
> In the kdump script, for the final step, it calls "systemctl reboot -f".
> But it seems the system is experiencing poweroff instead of reboot.

Pass "printk.devkmsg=on" so that you can actually see the debug output
of systemd-shutdown. It might tell you what is going on.

> Further more, in kdump script, even if I placed "sleep 60" before
> "systemctl reboot -f", the extra command did not take effect, and the
> system just start to poweroff immediately. So I guess there is another
> process to launch the poweroff action, but how to know what is it?

Enable debug logging, and use "printk.devkmsg=on", then you should be
able to figure out what is going on.

https://freedesktop.org/wiki/Software/systemd/Debugging/#index2h1

Lennart

--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] sd_notify protocol definition

[Lennart Poettering]

On Di, 03.03.20 10:26, Łukasz Niemier (luk...@niemier.pl) wrote:

> Is there documentation for sd_notify protocol? I am working on
> pure-Erlang implementation of sd_notify (and few other systemd
> facilities) and I am looking for better description than reading C
> code which can be a little confusing without deeper knowledge of
> systemd helper functions around iocvec. Especially ucred and fds
> parts, as rest I have mostly implemented.

The sd_notify() man page says everything there is to say really under
NOTES:

"These functions send a single datagram with the state string as
payload to the AF_UNIX socket referenced in the $NOTIFY_SOCKET
environment variable. If the first character of $NOTIFY_SOCKET is
"@", the string is understood as Linux abstract namespace
socket. The datagram is accompanied by the process credentials of
the sending service, using SCM_CREDENTIALS."

There isn't much more to know.

How to use sendmsg() and iovecs you find described in the respective
man page, but that's a Linux/libc/UNIX API, not a systemd one...

The nice thing about NOTIFY_SOCKET is really that its so simple it
barely even is a protocol...

Lennart

--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Creating a roaming USB home area using homectl

[Lennart Poettering]

On So, 08.03.20 22:07, Matthew Wardrop (mpward...@gmail.com) wrote:

> Greetings all,
>
> When I heard news of systemd-homed I was excited, since it was my
> understanding I'd be able to ferry only my external hard drive between home
> and work during my bicycle commute, and be able to forget about user id
> issues/etc. I tried to set it up, but must be missing something.
>
> On one machine I ran:
> $ sudo homectl create mawardrop --storage=luks -G docker -G wheel -G input
> --image-path=/dev/sdc --shell=/usr/bin/zsh
> (where /dev/sdc was my external hard drive).
>
> Everything works well locally. I can log in, and out, and the luks image
> successfully mounts and unmounts; but when I attempt to login in on a
> different machine also configured with systemd-homed, I come across two
> issues.
>
> 1) In order for `homectl list` to show my new home folder, I need to
> restart the homed service after plugging in the hard drive. That means I
> need to have it plugged in on machine boot, or log in as a different user
> and restart the service, for it to show up in in the login manager.

Hmm, this is a bug. This should just work... homed subscribes to udev
events to see everything plugged in. Can you file a bug about this.

> 2) Even once visible, it appears as "unfixated". Any operations on the home
> area such as `authenticate` or `activate` result in the error: "Operation
> on home mawardrop failed: Failed to execute operation: Key has been
> revoked".

homed doesn't allow just anyone to login. It signs user records with a
cryptographic key, and only allows users signed by a key known locally
to log in.

This needs better documentation, but the essence is that homed uses

a private key stored in /var/lib/systemd/home/local.private to sign
records with, and accepts all records signed by public keys matching
/var/lib/systemd/home/*.public. If you create a local user and
/var/lib/systemd/home/local.private does not exist yet a new key is
automatically generated and stored there, and its public key stored in
/var/lib/systemd/home/local.public.

This means, if you want users created on machine quux to be able to
log into machine waldo, make sure to copy quux's
/var/lib/systemd/home/local.public file to waldo, maybe into a file
/var/lib/systemd/home/quux.public.

> Am I just too early to the game, in that multi-machine setups are not yet
> supported? Or is there something obvious I am missing?

They are supported, just underdocumented ;-)

Lennart

--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Read-only /etc, machine-id with an overlay - journald failing

[Lennart Poettering]

On Mi, 26.02.20 09:44, Andreas Kempe (andreas.ke...@actia.se) wrote:

> Hello everyone,
>
> I'm working in a project with an embedded Linux system based on
> Openembedded using Systemd version 241 as our init process. We're
> using a read-only /etc. To facilitate development, we want to use a
> writeable overlay on /etc, but we ran into an issue.
>
> When we start, Systemd detects that there is no machine-id file
> present in /etc so it generates and mounts a /etc/machine-id. When our
> mount unit then applies the overlay on /etc, it hides the mounted
> file. Journald later fails to start because /etc/machine-id isn't
> visible through the overlay.

So when you swap out /etc you really should so so atomically, and
ensure that at no point in time stuff (i.e. mounts) go missing while
you shift things around. In particular not the machine-id.

Hence, the code that replaces /etc with an overlayfs, why doesn't it
bind mount /etc/machine-id into the new overlayfs before moving it
into place? i.e. first mount the overlayfs to some tmpdir, bind mount
/etc/machine-id into it, then use mount --move to move the fully
prepped overlayfs along with all submounts to /etc. That way noone
will notice anything changing.

Lennart

--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] sd-daemon documentation clarification

[Lennart Poettering]

On Mo, 02.03.20 13:38, Łukasz Niemier (luk...@niemier.pl) wrote:

> > AFAIK both stdout and stderr even get attached to the same journal pipe by 
> > default, so they should also be interpreted in the same way.
> >
> > The description of SyslogLevelPrefix= in systemd.exec(5) also says: "This 
> > only applies to log messages written to stdout or stderr.”
>
> THX, I must have missed that. This mean that the `sd-daemon`
> documentation page should be updated to contain that information as
> well.

https://github.com/systemd/systemd/pull/15283

Lennart

--
Lennart Poettering, Berlin
___
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

[Lennart Poettering]

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

Re: [systemd-devel] How does systemd (pid1) connect to system DBus?

[Lennart Poettering]

On Di, 04.02.20 17:34, Uoti Urpala (uoti.urp...@pp1.inet.fi) wrote:

> On Mon, 2020-02-03 at 19:01 +, Dimitri John Ledkov wrote:
> > I see that systemd pid1 manager is available on the system DBus.
> >
> > But when/how does it connect to it?
>
> unit_notify() calls manager_recheck_dbus(), which connects to the bus
> if dbus.service is running.

Correct, we connect to dbus the instant dbus.service is up, and
terminate when it goes down. dbus.service is magic hence from PID1's
PoV. Something similar happens wit journald and logging.

Lennart

--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Antw: Re: Antw: [EXT] Infinite loop at startup on var fsck failure

[Lennart Poettering]

On Mi, 26.02.20 10:55, Ulrich Windl (ulrich.wi...@rz.uni-regensburg.de) wrote:

> > I suspect that the real problem is, that fsck failed to fix the file
> > system, so as a result, systemd tried repeatedly to start the fsck job
> > for /var as var.mount was pulled in as a dependency (e.g. for
> > journald).
>
> The exit code should help:
>The exit code returned by fsck is the sum of the following conditions:
> 0- No errors
> 1- File system errors corrected
> 2- System should be rebooted
> 4- File system errors left uncorrected
> 8- Operational error
> 16   - Usage or syntax error
> 32   - Fsck canceled by user request
> 128  - Shared library error

We check the exit code.

Lennart

--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Is there a way to uninstall the file system first and then stop all services?I

[Lennart Poettering]

On Do, 27.02.20 20:39, www (ouyangxua...@163.com) wrote:

> Dear all,
>
>
> In systend, the order of power off is: first stop all services, and
> then uninstall the file system to oldroot. In special applications,

What do you mean "uninstall the file system to oldroot"? do you mean
the switch-root operation we optionally do during shutdown if an
initrd is around that has support for that? Or what do you mean?

I cannot really parse what you are trying to say.

> if the systemd need to stop most services first (need to keep some
> services communicating with the outside world over the network),
> then uninstall the file system to oldroot, then perform special
> operations(update the system), and then stop other services, then
> turn off the system. What should I do if I want to achieve such a
> function?Are there any good suggestions?Or how do you modify the
> code for systemd?
>
> Or is there a way to uninstall the file system first and then stop all 
> services?

Services that access the file systems cannot continue running if their
files/mounts/file systems are gone. Not sure I follow?

Lennart

--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Recommended shutdown method

[Lennart Poettering]

On Mi, 04.03.20 19:48, jay.bur...@fujitsu.com (jay.bur...@fujitsu.com) wrote:

> All,
>
> I have a debate going on over which is the best way to recommend to
> a development organization how to design a service shutdown. There are two
> camps.
>
>
> 1.   Use the ExecStop with an additional process that needs to ipc to the 
> services
>
> main pid and wait for a response.
>
> 2.   Use the SigTerm that systemd sends to the main pid which can use a 
> "quit" flag
>
> that the main process will use to shutdown.
>
>
> I know this is kind of an large issue but now that systemd is more widespread 
> is there
> any momentum in either method? If so could someone point me to examples or
> documentation?

Just use SIGTERM, it's the standard way to do that, simple and
safe. See daemon(7) man page.

Lennart

--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] sd-bus signal callback return value

[Lennart Poettering]

On Di, 24.03.20 21:43, Stanislav Angelovič (angelovi...@gmail.com) wrote:

> Hi folks,
>
> Please, what is the difference in sd-bus behavior when my D-Bus signal
> callback returns a zero return value versus a positive return value?

positive means "I processed the message, stop processing it further".

negative means "This message did not match my criteria, pass it to any
other callback that might be interested.

Basically, an incoming msg can match against multiple handlers, in
particular if you combine multiple instances of sd_bus_add_filter()
and sd_bus_add_match(). sd-bus will call them in the order you
registered them in, and will pass the incoming signal to each one in
turn as long as each returns 0. It stops when one returns > 0.

In most cases you want to return 0, to allow everyone who wants have a
look at the message. You'd return > 0 only if you want actively filter
a message so that noone else can see it, maybe to hide stuff from
other parts of the program if that's your kind of thing.

> And what's the difference between those return values in D-Bus method
> callback, D-Bus async method reply callback, D-Bus property get callback,
> and D-Bus property set callback?

it's always the same: whether to traverse the installed handlers
further.

Note that for method call handlers you typically want to return > 0
btw, because if you return 0 and sd-bus reaches the end of the list of
registered handlers it assumes noone was interested and synthesizes a
"NoSuchMethod" error reply.

> Which shall I return in normal cases? Zero?

when handling signals: zero. when handling incoming method calls: one.

Lennart

--
Lennart Poettering, Berlin
___
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] Stateless system - Centos8 and overlayfs on root

[Preston L. Bannister]

On Tue, Mar 31, 2020 at 1:10 AM Lennart Poettering 
wrote:

> On Fr, 27.03.20 10:17, Preston L. Bannister (pres...@bannister.us) wrote:
>
> > Had the (possibly) clever notion of using an overlayfs as the root mount,
> > with a tmpfs as the upper, and the usual persistent volume as the
> > lower.
>
> Current systemd versions support this natively, just boot with
> "systemd.volatile=overlay" on the kernel cmdline. Doubt this is in
> centos8 yet, though.
>

I can confirm that adding "systemd.volatile=yes" on the kernel cmdline with
Centos 8 results in failed boot. Some obscure error related to initramfs
that I have not tried to typify. Also Centos 8 has systemd 232, and it
looks like "systemd.volatile=overlay" handed later in systemd.


Note that overlayfs is a weird fs, it has strange, non-posixy
> semantics (inode nrs a fucked). It generally doesn't work as well as
> people want it to work, and while you might get away with using it for
> small, well-defined scenarios it's not suitable for complex, general
> purpose systems to run as root fs.
>
> "systemd.volatile=overlay" is a nice tool for testing and development,
> and maybe some very specific setups, but it's not really something i'd
> want to deploy in production in big scale.
>

OK - had not hear that before. Thanks. Did see some odd behavior, but
assumed (and still) the fault was mine.



> Look what src/volatile-root/volatile-root.c in current systemd
> versions is doing. It's relatively straight-forward. You can do
> something similar with a shell script.
>

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

Re: [systemd-devel] Ordering after udev applied rules to `/dev/dri/card0`

[Lennart Poettering]

On Do, 19.03.20 20:24, Andrei Borzenkov (arvidj...@gmail.com) wrote:

> 19.03.2020 19:47, Paul Menzel пишет:
> > Dear systemd folks,
> >
> >
> > I am using Debian Sid/unstable with systemd 245.2 and Weston 8.0.0.
> >
> > I amtrying to start a graphical desktop as soon as possible. Currently,
> > I use Weston, but unfortunately accessing `/dev/dri/card0` it gets a
> > permission denied error. The Weston service unit is ordered after
> > `systemd-logind.service`.
> >
> > Weston now fails to start, because it gets a permission denied error
> > accessing `/dev/dri/card0` [1][2].
> >
> >     drmModeSetCrtc(backend->drm.fd, output->crtc_id,
> > scanout_state->fb->fb_id, 0, 0, connectors, n_conn, >mode_info);
> >
> > Right before Weston starts, the permission and ownership are like below.
> >
> >     $ ls -l /dev/dri:
> >     insgesamt 0
> >     crw--- 1 root root 226,   0 Mär 19 17:29 card0
> >     crw--- 1 root root 226, 128 Mär 19 17:29 renderD128
> >
> > After udev applied the rules, it looks like below, meaning users in
> > group `video` are allowed to access the device.
> >
> >     $ ls -l /dev/dri
> >     insgesamt 0
> >     drwxr-xr-x  2 root root 80 Mär 19 17:29 by-path
> >     crw-rw+ 1 root video  226,   0 Mär 19 17:29 card0
> >     crw-rw+ 1 root render 226, 128 Mär 19 17:29 renderD128
> >
> > Is there a way to order a service in such a way, that it’s guaranteed
> > that udev rules to devices were applied?
> >
>
> After=device should work. udev announces device after all rules have
> been processed.

After= only orders, but this doesn't pull the device unit into the job
queue. To do that, you need to add Wants= on the device unit as well.

Lennart

--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Ordering after udev applied rules to `/dev/dri/card0`

[Lennart Poettering]

On Do, 19.03.20 17:47, Paul Menzel (pmenzel+systemd-de...@molgen.mpg.de) wrote:

> Dear systemd folks,
>
>
> I am using Debian Sid/unstable with systemd 245.2 and Weston 8.0.0.
>
> I amtrying to start a graphical desktop as soon as possible. Currently, I
> use Weston, but unfortunately accessing `/dev/dri/card0` it gets a
> permission denied error. The Weston service unit is ordered after
> `systemd-logind.service`.
>
> Weston now fails to start, because it gets a permission denied error
> accessing `/dev/dri/card0` [1][2].
>
> drmModeSetCrtc(backend->drm.fd, output->crtc_id,
> scanout_state->fb->fb_id, 0, 0, connectors, n_conn, >mode_info);
>
> Right before Weston starts, the permission and ownership are like below.
>
> $ ls -l /dev/dri:
> insgesamt 0
> crw--- 1 root root 226,   0 Mär 19 17:29 card0
> crw--- 1 root root 226, 128 Mär 19 17:29 renderD128
>
> After udev applied the rules, it looks like below, meaning users in group
> `video` are allowed to access the device.
>
> $ ls -l /dev/dri
> insgesamt 0
> drwxr-xr-x  2 root root 80 Mär 19 17:29 by-path
> crw-rw+ 1 root video  226,   0 Mär 19 17:29 card0
> crw-rw+ 1 root render 226, 128 Mär 19 17:29 renderD128
>
> Is there a way to order a service in such a way, that it’s guaranteed that
> udev rules to devices were applied?
>
> A small script applying permissions and ownership manually in
> `ExecStartPre=` seems to work around the (graphics) issue.
>
> If it cannot be solved with ordering, what would you suggest?
>
> [1]: https://gitlab.freedesktop.org/wayland/weston/issues/382
> [2]: 
> https://gitlab.freedesktop.org/wayland/weston/-/blob/master/libweston/backend-drm/kms.c#L741

Ideally Weston would just wait for devices assigned to the seat it
shall run on to appear to make this all safe. The thing is that we
don't know if a DRM device will show up or not. on some systems DRM
might show up, but on others (servers, containers, embedded devices,
…) it might never, since they have no actual graphics hw that can do
DRM. hence ordering a service after a device appearing means your
system will only boot up on machines that actually have a DRM device,
and not those anymore that do not...

What you could do is write a udev rule for your drm device that uses
the SYSTEMD_WANTS property to pull in has-drm.target, and then hook
your weston service into that with a Requisite=multi-user.target or
so. That way weston gets pulled in only if DRM shows up and when DRM
shows up, but not before and not on systems that do not have it, and
boot is not delayed for it...

If you develop your stuff for a very specific device only, and do not
attempt to build an OS that can boot on generic systems, then you
could also just change your weston service to do
"Wants=dev-dri-card0.device" + "After=dev-dri-card0.device". and thus
leave weston in the initial transaction and time out if DRM never
shows up...

Lennart

--
Lennart Poettering, Berlin
___
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

[Lennart Poettering]

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
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd-timesyncd - use unprivileged ports

[Lennart Poettering]

On Mi, 11.03.20 17:34, Jędrzej Dudkiewicz (jedrzej.dudkiew...@gmail.com) wrote:

> Hi,
>
> I have quite a few devices running Linux in client's network - so I
> have no control over it. It seems that all privileged UDP ports are
> blocked I have to use unprivileged port. I'd like to use
> systemd-timesyncd to synchronize time, thought I can't find a way to
> force it to use unprivileged port. Is there any way to do it?

There's not, currently, the port nr is hardcoded. It might be OK to
make the port nr configurable though, via an env var. You could then
set the env var via a drop-in for systemd-timesyncd.service that uses
Environment=. Patch should be simple, look for resolve_getaddrinfo()
in timesyncd-manager.c. Consider prepping a patch and posting as
github PR, we'll the review/merge it.

Lennart

--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Bizarre issue with logins and cgroups?

[Lennart Poettering]

On Sa, 28.03.20 14:02, Ryan (rym...@gmail.com) wrote:

> I don't yet have a small test for this yet, so here's all the information
> I've found while I get that ready:
>
> I have a side project  that revolves around using
> systemd-nspawn to run pet containers. One feature I'm trying to use it for
> is booted containers, where the following happens:
>
> - During container boot, a service is run that creates an account inside
> the container corresponding to the outside user. This service depends on
> multi-user.target, as well as console-getty (which is overridden to enable
> autologin).
> - The service inside signals the outside world when it's done that the
> container is ready for login.
> - Once the signal is received outside, the host uses nsenter to enter the
> container namespace, then runs
>
>   runuser -s /bin/bash -- - "$THE_USER_NAME" some-command

Use systemd-run for this.

nsenter inserts an outside process into the container, outside of all
supervision, outside of any sensible cgroup and so on. This shouldn't
be done for long-running stuff that is supposed to actually properly
join the container.

> Here's the bizarre part: runuser just hangs forever. I went into debugging
> it further, and found it was hanging waiting for a response from
> systemd-logind while executing the PAM config. With verbose logging for
> logind enabled, I observed the following:

Your client lives outside of the supervision of systemd inside the
container, it's a foreign process, even if it suddenly appears in the
same PID ns... i.e. its PPID is 0, and not 1, because it is
foreign. Just don't do this. systemd-run exists for a reason: it
inserts only a tiny very short-living process into the container that
then talks to systemd inside of the container and tells it to do
something, and then just hands over to that. This means the long
running process is actually running from the context of the user
inside it and all is good.

Lennart

--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] location of user-1000.journal

[Lennart Poettering]

On Do, 19.03.20 16:05, Chris Murphy (li...@colorremedies.com) wrote:

> Hi,
>
> I'm wondering if user journals are better being located in ~/.var by
> default? In particular in a systemd-homed context when ~/ is
> encrypted.

Unfortunately the entire system's log stream is coming primarily
through a single AF_UNIX socket, which is /dev/log. The back-end of
that is privileged (i.e. systemd-journald) since it deals with
privileged log messages primarily. if we'd implement what you are
asking for we'd have privileged code write to unpriv-owned directories
which is generally problematic for security reasons, because this
enables unpriv code to make privileged code do stuff in its own
territory. For example it could fuse mount something there, and then
make journald block on it and thus freeze the whole log stream. THis
is highly problematic.

Hence, this is far from easy to implement (i.e. it would require a
second component that runs unpriv and subscribes to the unpriv user's
log stream asynchronously, to avoid any such potential lockups), and I
am not sure it's worht the trouble? This is syslog after all, i.e. not
user facing stuff, hence probably fine if not in the user's home dir?

Lennart

--
Lennart Poettering, Berlin
___
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] making journald logs persistent on raspberry pi

[Dave Howorth]

On Tue, 31 Mar 2020 14:48:48 +0200
Lennart Poettering  wrote:
> On Fr, 24.01.20 15:32, Dave Howorth (syst...@howorth.org.uk) wrote:
> 
> > It's quite common on the Raspberry Pi to make /var/log a tmpfs, in
> > order to reduce the number of writes to the SD card that is the pi's
> > main storage. That's quite acceptable for most logs but I'd like to
> > make journald's logs persistent so I'll be able to investigate any
> > problems that occur whilst booting or shutting down more easily.  
> 
> Hmm, if you want volatile logging, use /run/log/...

I suppose you have some time now to revisit this old thread :)
But thanks for answering.
 
> It sounds strange to me, first making /var/log/... volatile, which is
> kinda where the stuff goes that is supposed to be persistent and then
> tryng to exclude stuff there again...

The problem is that almost all existing systems, services, whatever
send their logs by default to /var/log and each may or may not have a
different mechanism to redirect their logs to /run/log/. Plus each
individual user's machines may have a variety of different software
installed.

So if one wants a general means to guarantee reducing writes to the SD
card, it's easier to change how /var/log is stored than to provide a
facility that changes the log locations of every application on every
person's machine, where one doesn't even know what all those
applications are.

> i.e. journald's Storage= setting most just allows you to choose
> between /var/log/… and /run/log/… as data store.

Indeed, but that doesn't help in this scenario. Fortunately Mantas
provided a nice answer back in January :)

Cheers, Dave

> Lennart
> 
> --
> Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd-timesyncd - use unprivileged ports

[Mantas Mikulėnas]

On Tue, Mar 31, 2020, 22:40 Reindl Harald  wrote:

>
>
> Am 31.03.20 um 20:32 schrieb Jędrzej Dudkiewicz:
> > but I understand that
> > systemd-timesyncd always uses unprivileged source port?
> what else?
>

NTP has a "Symmetric Active" mode, where both peers use port 123 as source
*and* destination.

(It even seems that old NTPv1 actually determined the mode based on nothing
else but sport)
___
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

[Kevin P. Fleming]

The simple service unit I posted later in the thread (which invokes
hwclock) works great for me.

On Tue, Mar 31, 2020 at 1:29 PM Michał Zegan  wrote:
>
> 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
> >
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd-timesyncd - use unprivileged ports

[Jędrzej Dudkiewicz]

Lennart,

I suppose that what you wrote concerns UDP port on the server
providing system that systemd-timesyncd uses to synchronize time? This
is not a problem, from the point of view of the system where
systemd-timesyncd is running privileged remote port is not a problem,
I have problems if source UDP port (so one created by
systemd-timesyncd) is problematic, but I understand that
systemd-timesyncd always uses unprivileged source port?

Thanks for an answer,

JD

On Tue, Mar 31, 2020 at 4:57 PM Lennart Poettering
 wrote:
>
> On Mi, 11.03.20 17:34, Jędrzej Dudkiewicz (jedrzej.dudkiew...@gmail.com) 
> wrote:
>
> > Hi,
> >
> > I have quite a few devices running Linux in client's network - so I
> > have no control over it. It seems that all privileged UDP ports are
> > blocked I have to use unprivileged port. I'd like to use
> > systemd-timesyncd to synchronize time, thought I can't find a way to
> > force it to use unprivileged port. Is there any way to do it?
>
> There's not, currently, the port nr is hardcoded. It might be OK to
> make the port nr configurable though, via an env var. You could then
> set the env var via a drop-in for systemd-timesyncd.service that uses
> Environment=. Patch should be simple, look for resolve_getaddrinfo()
> in timesyncd-manager.c. Consider prepping a patch and posting as
> github PR, we'll the review/merge it.
>
> Lennart
>
> --
> Lennart Poettering, Berlin



-- 
Jędrzej Dudkiewicz

I really hate this damn machine, I wish that they would sell it.
It never does just what I want, but only what I tell it.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd-timesyncd - use unprivileged ports

[Reindl Harald]

Am 31.03.20 um 20:32 schrieb Jędrzej Dudkiewicz:
> but I understand that
> systemd-timesyncd always uses unprivileged source port?
what else?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Bizarre issue with logins and cgroups?

[Ryan]

Thank you so much!! I spent ages trying to figure this out, and somehow
that never occurred to me. When I first did nsbox, there was no concept of
booted containers, so I just used nsenter for everything, then when I added
this I had never considered moving to machinectl at that point.

On Tue, Mar 31, 2020 at 10:31 AM Lennart Poettering 
wrote:

> On Sa, 28.03.20 14:02, Ryan (rym...@gmail.com) wrote:
>
> > I don't yet have a small test for this yet, so here's all the information
> > I've found while I get that ready:
> >
> > I have a side project  that revolves around using
> > systemd-nspawn to run pet containers. One feature I'm trying to use it
> for
> > is booted containers, where the following happens:
> >
> > - During container boot, a service is run that creates an account inside
> > the container corresponding to the outside user. This service depends on
> > multi-user.target, as well as console-getty (which is overridden to
> enable
> > autologin).
> > - The service inside signals the outside world when it's done that the
> > container is ready for login.
> > - Once the signal is received outside, the host uses nsenter to enter the
> > container namespace, then runs
> >
> >   runuser -s /bin/bash -- - "$THE_USER_NAME" some-command
>
> Use systemd-run for this.
>
> nsenter inserts an outside process into the container, outside of all
> supervision, outside of any sensible cgroup and so on. This shouldn't
> be done for long-running stuff that is supposed to actually properly
> join the container.
>
> > Here's the bizarre part: runuser just hangs forever. I went into
> debugging
> > it further, and found it was hanging waiting for a response from
> > systemd-logind while executing the PAM config. With verbose logging for
> > logind enabled, I observed the following:
>
> Your client lives outside of the supervision of systemd inside the
> container, it's a foreign process, even if it suddenly appears in the
> same PID ns... i.e. its PPID is 0, and not 1, because it is
> foreign. Just don't do this. systemd-run exists for a reason: it
> inserts only a tiny very short-living process into the container that
> then talks to systemd inside of the container and tells it to do
> something, and then just hands over to that. This means the long
> running process is actually running from the context of the user
> inside it and all is good.
>
> Lennart
>
> --
> Lennart Poettering, Berlin
>


-- 
Ryan (ライアン)
Yoko Shimomura, ryo (supercell/EGOIST), Hiroyuki Sawano >> everyone else
https://refi64.com/
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Infinite loop at startup on var fsck failure

[Vito Caputo]

On Tue, Mar 31, 2020 at 03:32:04PM +0200, Lennart Poettering wrote:
> On Mo, 24.02.20 16:01, Vito Caputo (vcap...@pengaru.com) wrote:
> 
> > Hello list,
> >
> > Today I experienced an unclean shutdown due to battery dying unexpectedly,
> > and it left my /var in a state requiring a manual fsck to repair errors.
> >
> > The normal startup process failed and dropped me to a rescue shell after
> > asking for my root password.  But I was unable to immediately run fsck
> > manually, because systemd was endlessly trying to fsck /var.
> 
> Hmm, looks like a bug. It shouldn't keep retrying. Something mst
> have pulled in the unit over and over again...
> 
> Any chance you can reproduce this with current systemd, and maybe
> provide logs and put them into a github issue?
> 
> Or do you have logs from the case when this happened around?
>

No logs, since it was /var that needed the fsck, nothing persisted from the
rescue and I was in a cafe at the time trying to boot my laptop to work
on something else.  Regrettably I didn't take the time to copy the volatile
journals somewhere else, I was too annoyed at the time.

What I'm hearing is that this isn't a known fixed issue, which is concerning.
If I get a chance I'll poke at a repro, but it's pretty low on the priority
list at the moment.

Thanks for the response!

Regards,
Vito Caputo
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel