Re: [systemd-devel] 回复: Is it possible to send a string to the journal of one specific systemd unit

2021-10-22 Thread Mantas Mikulėnas
This option was added with util-linux v2.25 in 2014. If you're using an
older version or the Busybox `logger` instead, well, it won't have that.

The alternative is to write your own C tool that uses libsystemd and calls
sd_journal_send
<https://manpages.debian.org/testing/libsystemd-dev/sd_journal_send.3.en.html>()
with the correct fields (libsystemd is definitely going to be present), or
a Python tool that uses systemd.journal.send(). (Or maybe call libsystemd
through python ctypes or whatever other FFI mechanism is available.)



On Fri, Oct 22, 2021 at 4:32 PM DHAIY DHAIY  wrote:

> Thanks a lot Mantas.
> But in my sytem, logger does not have "--journal".
> Are you aware of other tools from bash which can be used?
>
> BR
> ------
> *发件人:* Mantas Mikulėnas 
> *发送时间:* 2021年10月22日 18:45
> *收件人:* DHAIY DHAIY 
> *抄送:* systemd-devel@lists.freedesktop.org <
> systemd-devel@lists.freedesktop.org>
> *主题:* Re: [systemd-devel] 回复: Is it possible to send a string to the
> journal of one specific systemd unit
>
> If you have root privileges (i.e. UID 0), then yes, you can send a journal
> message with the "OBJECT_SYSTEMD_UNIT=myservice.service" field and
> journalctl will automatically look for that.
>
> In C, specify the field when calling sd_journal_sendv(); in bash you can
> use `logger --journal`:
>
> (echo "OBJECT_SYSTEMD_UNIT=sshd.service";
>  echo "MESSAGE=Hello world!") | sudo logger --journal
>
> On Fri, Oct 22, 2021 at 11:43 AM DHAIY DHAIY  wrote:
>
> Saying we have a systemd unit named "myservice".
>
> we can use *journalctl -u myservice* to inspect the logs generated by
> myservice.
>
>
> But is there a way to insert one string from command-line into myservice's
> journal so that it can be seen by *journalctl -u myservice* later?
>
> --
> *发件人:* DHAIY DHAIY
> *发送时间:* 2021年10月22日 16:40
> *收件人:* systemd-devel@lists.freedesktop.org <
> systemd-devel@lists.freedesktop.org>
> *主题:* Is it possible to send a string to the journal of one specific
> systemd unit
>
>
> Saying we have a systemd unit named "myservice".
>
> we can use *journalctl -u myservice* to inspect the logs generated by
> myservice.
>
>
> But is there a way to insert one string from command-line into myservice's
> journal so that it can be seen by *journalctl -u myservice* later?
>
>
>
> --
> Mantas Mikulėnas
>


-- 
Mantas Mikulėnas


Re: [systemd-devel] 回复: Is it possible to send a string to the journal of one specific systemd unit

2021-10-22 Thread Mantas Mikulėnas
If you have root privileges (i.e. UID 0), then yes, you can send a journal
message with the "OBJECT_SYSTEMD_UNIT=myservice.service" field and
journalctl will automatically look for that.

In C, specify the field when calling sd_journal_sendv(); in bash you can
use `logger --journal`:

(echo "OBJECT_SYSTEMD_UNIT=sshd.service";
 echo "MESSAGE=Hello world!") | sudo logger --journal

On Fri, Oct 22, 2021 at 11:43 AM DHAIY DHAIY  wrote:

> Saying we have a systemd unit named "myservice".
>
> we can use *journalctl -u myservice* to inspect the logs generated by
> myservice.
>
>
> But is there a way to insert one string from command-line into myservice's
> journal so that it can be seen by *journalctl -u myservice* later?
>
> --
> *发件人:* DHAIY DHAIY
> *发送时间:* 2021年10月22日 16:40
> *收件人:* systemd-devel@lists.freedesktop.org <
> systemd-devel@lists.freedesktop.org>
> *主题:* Is it possible to send a string to the journal of one specific
> systemd unit
>
>
> Saying we have a systemd unit named "myservice".
>
> we can use *journalctl -u myservice* to inspect the logs generated by
> myservice.
>
>
> But is there a way to insert one string from command-line into myservice's
> journal so that it can be seen by *journalctl -u myservice* later?
>
>

-- 
Mantas Mikulėnas


Re: [systemd-devel] D-feet displays an error message when using sd-bus

2021-10-19 Thread Mantas Mikulėnas
On Tue, Oct 19, 2021, 18:29 yves baumes  wrote:

> Hello,
>
> First I am not sure it is the correct place to ask questions about lib
> sd-bus. Is it? Here is my issues:
>
> I am trying to use the lib sd-bus, following this blog post:
> http://0pointer.net/blog/the-new-sd-bus-api-of-systemd.html .
>
> I am able to launch my own service on the *user* bus.
> When I launch it on the *system* bus, problems appear.
> First I had a permission denied issue, and to correct it I had to create a
> configuration file in /etc/dbus-1/system.d/net.poettering.Calculator.conf .
> As stated in
> https://stackoverflow.com/questions/32828468/sd-bus-api-sd-bus-request-name-returns-permission-denied
> .
> Thus the executable launches perfectly (no more 'permission denied'
> errors).
>

This is normal as the system bus is "deny everything by default", to make
sure unprivileged users can't impersonate a service.


> Now I am trying to inspect the service with D-feet. The service is well
> listed on the left pane: net.poettering.Calculator, but when I click on it,
> I get an error window stating :
> 'net.poettering.Calculator: g-dbus-error-quark:
> GDBus.Error:org.freedesktop.DBus.Error.AccessDenied: Rejected send message,
> 1 matched rules; type="method_call", sender=":-1.1996" (uid=1000
> pid=3110822 comm="/usr/bin/python3 /usr/bin/d-feet" label"unconfined")
> interface="org.freedesktop.DBus.Introspectable" member="Introspect" error
> name ="(unset)" requested_reply="0" destination=net.poettering.Calculator"
> (uid=0 pid=3110595 comm="./-bus-service" label="unconfined")(9)' .
>

This also means you need to allow things in the dbus-daemon policy. Not
only does the service need permissions to claim a name, but everyone also
needs permissions to send it messages (and receive replies).

In many cases you can copy a basic policy that just allows everything from
any UID to your service (possibly still limited by interface), like how
UDisks2.conf does it.


Re: [systemd-devel] PIDFile creation logic

2021-10-19 Thread Mantas Mikulėnas
On Tue, Oct 19, 2021, 08:45 Andrei Borzenkov  wrote:

> On 18.10.2021 23:08, Silvio Knizek wrote:
> > Am Montag, dem 18.10.2021 um 12:43 -0700 schrieb Kenneth Porter:
> >> I just installed the new-to-EPEL ndppd service and am seeing this in my
> log:
> >>
> >> Oct 17 21:10:08 saruman systemd: Can't open PID file
> >> /var/run/ndppd/ndppd.pid (yet?) after start: No such file or directory
> >>
>
> That is just an information. May be it could be downgraded to debug, at
> least initially.
>
> >> Examining the source, I see that the pidfile is created by the child
> >> process, not the parent. I'm guessing that systemd is expecting the
> pidfile
> >> to exist when the parent exits? (I want to file the issue on the
> upstream
> >> program and want to make sure I understand how this should work.)
> >>
> >> Source in question. Note how daemonize() forks and exits and main()
> invokes
> >> daemonize and then creates the pidfile. I'm thinking that daemonize()
> >> should create the pidfile before it invokes exit().
> >>
> >> 
> >>
> > Hi,
> >
> > just don't demonize and don't use a PIDFile= at all. systemd is
> > actually quite apt in figuring out which process is the right main one.
>
> It is not about "main process". It is about notifying systemd that your
> service is ready and systemd can proceed with After dependencies.
> Without PIDFile your service is "ready" as soon as it forked. This most
> likely is not correct.
>

Not quite as soon as it forked, but as soon as the parent exits.

This doesn't depend on pidfiles, and in general seems to be something that
services get right more often than pidfile creation. Initialize, fork, exit
in parent.


Re: [systemd-devel] firmware times reported were incorrect.

2021-10-13 Thread Mantas Mikulėnas
Looks like boot-timestamps.c first tries to read the ACPI FPDT table (it
seems acpi-fpdt.c uses the "OS Loader StartImage Start" and
"ExitBootServices Exit" fields), but if that's unavailable, then it uses
timestamps stored by systemd-boot in EFI variables
(/sys/firmware/efi/efivars/LoaderTime*). The latter seems to be estimating
it from RDTSC (src/boot/efi/util.c).

On Wed, Oct 13, 2021 at 3:05 PM jiansong Xu  wrote:

> *This is bios from oracle, we noticed that the firmware times reported
> were incorrect.*
>
> *Startup finished in** 59min 7.944s** (firmware) + 33.051s (loader) +
> 4.428s*
> *(kernel) + 1min 18.870s (initrd) + 44.494s (userspace) = 1h 1min 48.789s*
>
>
>
> *May I ask what is the source of the **firmware** ?  is it read from acpi
> table? *
>
>
>


-- 
Mantas Mikulėnas


Re: [systemd-devel] Prefix for direct logging

2021-09-28 Thread Mantas Mikulėnas
On Tue, Sep 28, 2021, 06:07 Arjun D R  wrote:

> Thank you Mantas for the details.
> How do you currently get the logs "every few seconds"?
> > Actually we have a script that will be triggered every 10 seconds. That
> script will run "journalctl -u " and redirect the output to the
> respective log file. We will run journalctl for around 40-50 services for
> every 10 seconds and redirect it to the respective log files. That may be a
> bad idea, but this is how we are collecting logs as of now. We need to
> separate the logs for every service and that's why we ended up with this
> implementation.
>

So replace it with 40-50 instances of continuously running `[stdbuf -o0]
journalctl -f -u `.

Although syslogd might be easier, since then you'd only need one process
doing the monitoring. (I know both syslogds can access journal fields like
_SYSTEMD_UNIT, but I don't know how, so usually I just filter by the
traditional "program name" and it does the job.)

You could also have a custom daemon that reads from `journalctl -f -o json`
and writes to the appropriate text log...


>
> Ah, ok so StandardOutput:file: will allow the service to open
> the fd and directly connect it to the service stdout.
>

Yes, so if you want timestamps they have to be provided by your service,
pretty much like how most services implement direct logging to files.
(Probably the only advantage of StandardOutput is that the service doesn't
need permissions to /var/log...)

>


Re: [systemd-devel] Prefix for direct logging

2021-09-27 Thread Mantas Mikulėnas
On Mon, Sep 27, 2021 at 1:11 PM Arjun D R  wrote:

> Hi Folks,
>
> Currently we are using systemd-journald for service logging. We run
> journalctl for a bunch of services and redirect those to the custom log
> files for every few seconds. This takes up the CPU for that particular
> time period since we have lot of IO operations as well. We came to know
> that systemd version v236+ supports direct logging
> (StandardOutput:file:) to the custom log file by the service. I
> would like to use that facility but we don't get the prefix that we used to
> get when using the journal.
>
> Is there a way to prepare a custom patch locally to add the necessary
> prefix to the stdout before writing to the custom log file? Is that a good
> idea? Any other suggestions?
>

Probably not easily, as it's not systemd that is writing to the log file –
it's your service process itself that directly gets a FD for the log file
as its stdout. It's not specifically a "direct logging" feature, but rather
just an equivalent to `myservice > log_file`.

How do you currently get the logs "every few seconds"? Instead of repeated
grabbing, have you tried using `journalctl --follow` to monitor logs
continuously? This should use far less I/O than repeated `journalctl |
tail` which is what it sounds like you're doing. (Wrap in `stdbuf -o0` if
necessary.)

Alternatively, set up the traditional rsyslogd or syslog-ng – writing to
custom log files is basically what they *do*, and both of them are capable
of receiving logs from journald (either by directly monitoring .journal
files or by having the messages forwarded via socket).

-- 
Mantas Mikulėnas


Re: [systemd-devel] Xorg or Wayland Environment

2021-09-19 Thread Mantas Mikulėnas
On Sun, Sep 19, 2021 at 4:48 PM Ed Greshko  wrote:

> On 19/09/2021 21:39, Michael Biebl wrote:
>
> A useful command in this context is
>
> systemctl --user show-environment
>
>
> OK, that was helpful.  But leads to another question.
>
> How to run the service only if KDE_FULL_SESSION=true?
>

To be sure, do you mean "if" or "when"?

You could check using [Unit] ConditionEnvironment=, sure, but if the actual
problem is that the unit is started too early, this won't help -- it won't
actually get delayed "until KDE_FULL_SESSION becomes true", it just won't
be run at all.

You said that the service runs at the login screen -- I'm not sure how this
can happen if your service is installed into plasma-core.target.wants/ (and
*not* in default.target.wants nor basic.target.wants)...

-- 
Mantas Mikulėnas


Re: [systemd-devel] Xorg or Wayland Environment

2021-09-19 Thread Mantas Mikulėnas
On Sun, Sep 19, 2021 at 4:05 AM Ed Greshko  wrote:

> Not a everyday systemd service writer
>
> I've written a user service file to start an app on login.  It works well
> for Xorg with Environment=DISPLAY=:0.
>
> But I've found that under Wayland the DISPLAY=:1 after a logout of Xorg
> and login to a
> Wayland session.
>
> What would be the proper way to get the DISPLAY environment varible use it
> as opposed
> to "hard" coding it?
>

The proper way is to have *the desktop environment* upload DISPLAY (and
whatever else is relevant, such as XAUTHORITY or WAYLAND_DISPLAY or
XDG_SESSION_TYPE) into systemd --user, so that it would be automatically
available to your service *without *doing anything special.

For example, gnome-session does this for GNOME (it calls systemd's
UnsetAndSetEnvironment in gsm-util.c), and
/etc/X11/xinit/xinitrc.d/50-systemd-user.sh handles the bare minimum for
other Xorg-based desktops (when startx is used).

If KDE integrates with systemd --user in any way (i.e. if it actually has a
"plasma-core.target" that you mention), I'd really expect it to do the same
before it tries to start its own targets, otherwise they would be kind of
useless.

-- 
Mantas Mikulėnas


Re: [systemd-devel] when mount is delayed - start unit which depends on it - ?

2021-09-18 Thread Mantas Mikulėnas
On Fri, Sep 17, 2021 at 2:40 PM lejeczek  wrote:

> Hi guys.
>
> I'm trying to have unit to start...
> well,
> I have a luks device which waits for manual passphrase
> input, when that happens 'systemd' mounts, without user
> intervention(which is great), that luks device.
> fstab:
> /dev/mapper/luks.devs /devs   ext4
> noatime,nobarrier,noatime,x-systemd.device-timeout=2,nofail 1 2
> and now I'll have many units/services which depend on that
> mount, because they need to get to paths to get their
> configs & other bits.
>
> Question - how do I make such a unit to re/start when
> 'systemd' does the mount? Naturally, ideally without any
> ways external to 'systemd'.
>

If units need this mount, then *actually* make them depend on this mount –
as in, "Requires=devs.mount" and "After=devs.mount" in each service's
[Unit].

-- 
Mantas Mikulėnas


Re: [systemd-devel] Filter/Parse NETLINK_KOBJECT_UEVENT Messages

2021-09-13 Thread Mantas Mikulėnas
On Tue, Sep 14, 2021 at 4:08 AM Ryan McClue 
wrote:

> I understand this is slightly off-topic, but I'm completely new to BPF.
> Analyzing libudev source and Internet I understand the general idea.
> However, I don't understand how information/what information is passed to
> the filter from the socket. For example, in my case the socket payload,
> i.e. buf_str =
> *add@/devices/pci:00/:00:14.0/usb1/1-2/1-2.4/1-2.4:1.0/input/input38/event14*
> 1. How do I pass this string to the *sock_filter/sock_fprog* structures?
>

As far as I know – you don't. Once you attach the filter to the socket, it
automatically gets invoked with each packet's payload as the input
(whatever counts as "input" for BPF, I'm not entirely sure), and you don't
need to pass anything anywhere manually.

Note that this is not eBPF but the traditional cBPF that's used e.g. by
tcpdump/libpcap.


> 2. Is a correct way of filtering these to implement string parsing to
> check for '/event' sub-string in EPF bytecode?
>

See sd_device_monitor_filter_update() in
src/libsystemd/sd-device/device-monitor.c (nowadays, sd-device has all the
interesting code, while libudev is a thin wrapper around it).

-- 
Mantas Mikulėnas


Re: [systemd-devel] Filter/Parse NETLINK_KOBJECT_UEVENT Messages

2021-09-13 Thread Mantas Mikulėnas
(Added list back again)

On Mon, Sep 13, 2021 at 1:55 PM Ryan McClue 
wrote:

> Thank you for the response Mantas.
> If I change the nl_groups to 2, it prints libudev a handle of times and I
> then get a segfault.
> In regards to this picking up all devices: if I add/remove my Bose
> speakers connected with a stereo jack cable, this does not appear in the
> messages. Can this be detected?
>
>
Speakers aren't seen as a standalone device (the audio jack is really just
an audio jack, not a device bus). You should be able detect when speakers
are connected, but you'll do this through audio mixer events from ALSA (I'm
not sure how PulseAudio does it, but something /dev/snd/control*), or
alternatively through evdev (there's a /dev/input/event* node which
produces SW_HEADPHONE_INSERT) – but not through device uevents.

-- 
Mantas Mikulėnas


Re: [systemd-devel] Filter/Parse NETLINK_KOBJECT_UEVENT Messages

2021-09-13 Thread Mantas Mikulėnas
On Mon, Sep 13, 2021 at 12:29 PM Ryan McClue 
wrote:

> Currently, I'm listening to NETLINK_KOBJECT_UEVENT messages with the
> following code:
>
> union UeventBuffer {
>   struct nlmsghdr netlink_header;
>   char raw[8192];
> };
>   int sock = socket(PF_NETLINK, SOCK_RAW | SOCK_NONBLOCK,
> NETLINK_KOBJECT_UEVENT);
>
>   struct sockaddr_nl addr = {};
>   addr.nl_family = AF_NETLINK;
>   addr.nl_groups = 1 << 0;
>   bind(sock, (struct sockaddr *), sizeof(addr));
>
>   UeventBuffer buf = {};
>   struct iovec iov = {};
>   iov.iov_base = 
>   iov.iov_len = sizeof(buf);
>
>   struct msghdr msg = {};
>   struct sockaddr_nl src_addr = {};
>   msg.msg_name = _addr;
>   msg.msg_namelen = sizeof(src_addr);
>   msg.msg_iov = 
>   msg.msg_iovlen = 1;
>
>   int bytes = recvmsg(sock, , 0);
>   char *buf_str = buf.raw;
>   // parse this buf_str ...
>
> I have a few questions to clarify my understanding and to make this more
> robust:
> 1. If I add an Xbox One controller, which evtest shows to be
> /dev/input/event14 I get a whole host of messages, e.g:
> *add@/devices/pci:00/:00:14.0/usb1/1-2/1-2.4/1-2.4:1.0*
>
> *add@/devices/pci:00/:00:14.0/usb1/1-2/1-2.4/1-2.4:1.0/input/input38*
>
> *add@/devices/pci:00/:00:14.0/usb1/1-2/1-2.4/1-2.4:1.0/input/input38/event14*
>
> *add@/devices/pci:00/:00:14.0/usb1/1-2/1-2.4/1-2.4:1.0/input/input38/js0*
> *bind@/devices/pci:00/:00:14.0/usb1/1-2/1-2.4/1-2.4:1.0*
> *add@/devices/pci:00/:00:14.0/usb1/1-2/1-2.4/1-2.4:1.1*
> *add@/devices/pci:00/:00:14.0/usb1/1-2/1-2.4/1-2.4:1.2*
> *bind@/devices/pci:00/:00:14.0/usb1/1-2/1-2.4*
> *add@/devices/pci:00/:00:14.0/usb1/1-2/1-2.2*
> *change@/devices/pci:00/:00:14.0/usb1/1-2/1-2.2*
> Why so many?
>

It represents the actual device and subsystem layering in Linux – first
there's a USB device (on hub 1-2 port 4), then USB interfaces on that
device (1.0 to 1.2), then an input-layer device (input38), then two
different /dev nodes exposed by it (generic evdev and what I *think* is
legacy joydev? Not sure if it's "legacy" or "still current".)

They are necessary; for example, the 1st event that informs systemd-udevd
about the low-level USB device is what causes the correct device driver
module to be loaded in the first place.


> Can I filter them to just get the ones ending with /input/inputXX/eventXX?
>

It seems you're supposed to use BPF filters via SO_ATTACH_FILTER; at least
that's what libudev does.


> 2. Currently this only picks up input devices. How would I listen to /snd
> devices, /hid devices, etc.? I assume some change to nl_groups, however
> what should this be and where is this documented?
>

There's just one group for all events.

(If I remember correctly, group 1 has all events straight from the kernel,
group 2 is the same events augmented and retransmitted by udev. Normally
programs want the latter. Both have the same events and include all
devices, though.)


> 3. Currently, I'm manually parsing the *buf_str* to extract the command
> and device. Are there some supplied macros that parse this information in a
> more robust way? (as is the case for RTNETLINK)
>

Well, systemd supplies a whole libudev library, so I would generally
recommend using that – *instead of* manually working with netlink... (Or
more recently sd-device, but I don't think libudev is likely to be going
*poof* anytime soon, especially if you're looking for compatibility with
older systems or eudev-using distros.)

Start with udev_monitor_new_from_netlink() and
use udev_monitor_filter_add_match_*() to filter by subsystem, devtype, or
some arbitrary property, then you'll receive events already parsed. That's
3 lines of code in comparison to your 30.

-- 
Mantas Mikulėnas


Re: [systemd-devel] Unable to boot Linux distribution ISO files that have systemd services

2021-09-01 Thread Mantas Mikulėnas
On Wed, Sep 1, 2021 at 2:40 PM EpicLemon99 
wrote:

> I am unable to boot up ISO files of Linux distributions that use systemd.
> My computer is a HP Pavilion TG01-2856no, it is recent hardware. The boot
> gets stuck when it tries to start systemd services, such as Network Time
> Synchronization.
>
> For example, there are the messages I get when trying to boot up the Arch
> Linux ISO: https://imgur.com/a/oKGjZk7
>
> Booting it with the kernel argument init=/bin/bash however works.


Boot it with the 'systemd.debug-shell' option and take a look (via tty9) at
what systemd-udevd is doing. I'm guessing that one of its worker processes
tried to interact with a device (e.g. read information from /sys or do some
active probing), but due to either hardware issue or driver bug, the
syscall got stuck in the kernel and never returned. So check
/proc/PID/stack of the udev worker processes, I guess?

(The same issue might be occurring even on installed systems, only they
don't *wait* for udev to finish handling every single device
(systemd-udev-settle), so the process might just remain hung in background.)

-- 
Mantas Mikulėnas


Re: [systemd-devel] why log_set_prohibit_ipc() is set in journald

2021-08-27 Thread Mantas Mikulėnas
On Fri, Aug 27, 2021, 08:52 Nishant Nayan 
wrote:

> I have just started to learn journald and in its main function (in
> journald.c) I encountered a function call "log_set_prohibit_ipc(true);"
> In systemd source, I can see the declaration in src/basic/log.h:/*
>
> If turned on, then we'll never use IPC-based logging, * i.e. never log to
> syslog or the journal. We'll only * log to stderr, the console or kmsg
> */void log_set_prohibit_ipc(bool b);
>
> I did not get this because Journald not writing to journal itself by
> default is strange, isn't it?
> What is the reason behind it?
>

My understanding is that the point isn't to prevent logging to journal, but
to prevent logging *through IPC* specifically, i.e. make sure journald
doesn't try to create loopback connections to its own sockets. The journald
daemon is single-threaded, so if it tries to connect to itself, it'll
deadlock.

But also if journald wants to log a critical error (e.g. running out of
space or something like that), then it can't really *rely* on journal still
working...

Afaik, messages written to kmsg will be imported back into the journal
anyway, but that happens asynchronously so it's fine.

>


Re: [systemd-devel] How does journald talks to other services?

2021-08-23 Thread Mantas Mikulėnas
On Mon, Aug 23, 2021, 11:19 Nishant Nayan 
wrote:

> I was using logger command to see if the logs goes to journal, and it
> does, it goes both in /var/log/messages (owned by syslog) and journal, how
> is it happening? Is it because journal listens to /dev/log ?
>

Journald listens to /dev/log and writes messages to its .journal files.
Then a syslog daemon (rsyslogd or syslog-ng) receives the same messages
*from* journald, in one of two ways, and writes them to /var/log/messages:

a) The syslog daemon directly reads messages with full metadata from
.journal files (e.g. in rsyslogd this is the imjournal module);

or b) The syslog daemon listens on a completely separate socket in /run,
and journald forwards all messages to that socket (without metadata) using
the traditional syslog protocol.

The following is from systemd-journald.socket
> [Socket]
> ListenStream=/run/systemd/journal/stdout
> ListenDatagram=/run/systemd/journal/socket
> ListenDatagram=/dev/log
>
> Also can we edit 'systemd-journald.socket ' so as to not listen to
> /dev/log ? Just for seeing its behaviour.
> I tried by commenting out and removing 'ListenDatagram=/dev/log' and
> restarted the socket and journal service, but the logger log is still
> displayed in journal
>

Technically that should work? But don't use it for other reasons except
testing, I'd say...

Did you systemctl daemon-reload?

Is /dev/log a real socket or a symlink? (In later systemd versions it's a
symlink and the real socket is in /run.)

If it's a real socket, does it get re-created after 'rm'?


>
>
> Nishant
>
> On Fri, 20 Aug 2021 at 16:43, Mantas Mikulėnas  wrote:
>
>> On Fri, Aug 20, 2021 at 2:11 PM Mantas Mikulėnas 
>> wrote:
>>
>>> On Fri, Aug 20, 2021 at 2:10 PM Nishant Nayan <
>>> nayan.nishant2...@gmail.com> wrote:
>>>
>>>> Regarding the below point :
>>>> c) The service prints to stdout/stderr, but systemd attaches the
>>>> service's stdout/stderr to a pipe which is read by journald (using
>>>> sd_journal_stream_fd(3) from libsystemd). See [Service] StandardOutput= in
>>>> systemd.service(5).
>>>>
>>>> I did not see StandardOutput field in [Service] sections of a service
>>>> file, for example sshd.service, but its logs are visible in journalctl.
>>>> Is it by default piped to journal and we need to explicitly mention it
>>>> (StandardOutput=)  only when we want to redirect it somewhere else?
>>>>
>>>
>>> StandardOutput=journal is the default setting.
>>>
>>
>> And, actually, sshd doesn't write its messages to stdout anyway – it uses
>> syslog() via /dev/log; most daemons do.
>>
>> --
>> Mantas Mikulėnas
>>
>


Re: [systemd-devel] How does journald talks to other services?

2021-08-20 Thread Mantas Mikulėnas
On Fri, Aug 20, 2021 at 2:11 PM Mantas Mikulėnas  wrote:

> On Fri, Aug 20, 2021 at 2:10 PM Nishant Nayan 
> wrote:
>
>> Regarding the below point :
>> c) The service prints to stdout/stderr, but systemd attaches the
>> service's stdout/stderr to a pipe which is read by journald (using
>> sd_journal_stream_fd(3) from libsystemd). See [Service] StandardOutput= in
>> systemd.service(5).
>>
>> I did not see StandardOutput field in [Service] sections of a service
>> file, for example sshd.service, but its logs are visible in journalctl.
>> Is it by default piped to journal and we need to explicitly mention it
>> (StandardOutput=)  only when we want to redirect it somewhere else?
>>
>
> StandardOutput=journal is the default setting.
>

And, actually, sshd doesn't write its messages to stdout anyway – it uses
syslog() via /dev/log; most daemons do.

-- 
Mantas Mikulėnas


Re: [systemd-devel] How does journald talks to other services?

2021-08-20 Thread Mantas Mikulėnas
On Fri, Aug 20, 2021 at 2:10 PM Nishant Nayan 
wrote:

> Regarding the below point :
> c) The service prints to stdout/stderr, but systemd attaches the service's
> stdout/stderr to a pipe which is read by journald (using
> sd_journal_stream_fd(3) from libsystemd). See [Service] StandardOutput= in
> systemd.service(5).
>
> I did not see StandardOutput field in [Service] sections of a service
> file, for example sshd.service, but its logs are visible in journalctl.
> Is it by default piped to journal and we need to explicitly mention it
> (StandardOutput=)  only when we want to redirect it somewhere else?
>

StandardOutput=journal is the default setting.

-- 
Mantas Mikulėnas


Re: [systemd-devel] Mobile broadband modems support in systemd-networkd

2021-08-20 Thread Mantas Mikulėnas
On Thu, Aug 19, 2021 at 10:46 PM Bruce A. Johnson <
bjohn...@blueridgenetworks.com> wrote:

> I am trying to integrate an MBIM cellular modem (Sierra Wireless MC7455)
> into my project, and while there seem to be plenty of people doing the
> same thing, all of the references seem to point to using ModemManager to
> set up the connection and NetworkManager to manage the IP config
> (address, gateway, and DNS). I'd like to avoid having to add
> NetworkManager to my build, since I've been getting along nicely with
> systemd-networkd for my Ethernet and Wi-Fi interfaces (using iwd to
> manage the Wi-Fi connection). Is there any work afoot to get
> systemd-networkd to set up the IP address info in concert with
> ModemManager, or do I have to force NetworkManager to play nicely with
> systemd-networkd?
>

Wouldn't e.g. `mbimcli` configure IP on its own?

-- 
Mantas Mikulėnas


Re: [systemd-devel] How does journald talks to other services?

2021-08-20 Thread Mantas Mikulėnas
On Fri, Aug 20, 2021 at 12:31 PM Nishant Nayan 
wrote:

> Hi,
> My query is how does systemd-journald talk to other services so that
> it stores their logs/output in journal files, which could be displayed
> using journalctl utlity.
>

Journald doesn't talk to services, services talk to journald:

a) The service uses the standard syslog(3) call to send basic messages
through the /dev/log socket, where journald (or a traditional syslogd) is
listening.

b) The service uses sd_journal_print(3) from libsystemd to send structured
messages through /run/systemd/journal/socket (systemd-journald.socket).
Some frameworks, such as GLib, have their own implementations of this
protocol without needing libsystemd.

c) The service prints to stdout/stderr, but systemd attaches the service's
stdout/stderr to a pipe which is read by journald (using
sd_journal_stream_fd(3) from libsystemd). See [Service] StandardOutput= in
systemd.service(5).

d) Journald also reads kernel messages (dmesg) from the /dev/kmsg device.
Programs can actually write to /dev/kmsg to generate dmesg messages and
journald will capture them.

-- 
Mantas Mikulėnas


Re: [systemd-devel] [EXT] Re: Q: "Industry Standard" unit files

2021-08-03 Thread Mantas Mikulėnas
On Tue, Aug 3, 2021 at 1:28 PM Ulrich Windl <
ulrich.wi...@rz.uni-regensburg.de> wrote:

> >>> Mantas Mikulenas  schrieb am 03.08.2021 um 11:44 in
> Nachricht
> :
> > On Tue, Aug 3, 2021, 11:36 Ulrich Windl <
> ulrich.wi...@rz.uni-regensburg.de>
> > wrote:
> >
> >> Hi!
> >>
> >> I'm not into socket units, but maybe one one is could have a look at the
> >> unit files shown in https://serverfault.com/q/1070757/407952. Those
> files
> >> are from a commercial product (Backup Software)
> >> I wonder if these look OK, or (what I think) are quite incomplete.
> >>
> >
> > Looks mostly OK to me.
> >
> >>
> > A dependency on network is not needed for sockets with wildcard binds
> (i.e.
> > just port, no specific IP address). These will always succeed.
> >
> > The service doesn't need a general network dep either, if you've
> received a
> > connection then the network is usually already up.
> >
> > Dependency on local-fs is implied in DefaultDependencies, *I think,* so
> you
> > don't need to explicitly add it. Although maybe
> > RequiresMountsFor=/var/opt/omni would be useful.
> >
> > I wouldn't expect the vendor to include a dep on remote-fs by default.
> It's
> > up to the admin to decide this – locally adding dependencies is quite a
> bit
> > easier than locally removing unwanted ones (I really wish unit files had
> a
> > -= operator, but.) Having things depend on NFS when they don't actually
> > need it is annoying.
> >
> > On the other hand, I would *remove* some options – that PIDFile= is
> > redundant in general, and just outright makes no sense for a templated@
> > service to use a non-templated pidfile path. The KillMode=process is also
> > somewhat dubious.
> >
> > PartOf=omni.service doesn't seem like it would work, as an Accept=yes
> > socket will indeed use omni@.service (one instance per connection, not a
> > single long-running daemon – this very much looks like a direct
> conversion
> > from inetd-based service to systemd). I'd remove it here.
> >
> > Similarly, the WantedBy= in omni@.service is nonsensical – inetd
> > per-connection services can't be started on boot, there's no connection
> to
> > attach them to... This kind of service has to be started by the socket,
> not
> > through `systemctl enable`.
>
> Thanks for having a look! So it seems not as broken as I was afraid.
> You are right that the service was written for inetd originally, and one of
> the problems found with systemd is that the process ends with varying exit
> codes (mostly 1 and 3) that systemd considers to be not successful.
>

The mapping of exit codes can be overridden -- if the process itself
considers 1 and 3 to be successful, then "SuccessExitStatus=0 1 3" would
help.

Prefixing the command with a "-" (as in "ExecStart=-/opt/foo") is also an
option, if you want to ignore *all* exit codes; many inetd-converted
services do this to avoid accumulating failed instances (e.g. after botnet
probes).

-- 
Mantas Mikulėnas


Re: [systemd-devel] Q: "Industry Standard" unit files

2021-08-03 Thread Mantas Mikulėnas
On Tue, Aug 3, 2021, 11:36 Ulrich Windl 
wrote:

> Hi!
>
> I'm not into socket units, but maybe one one is could have a look at the
> unit files shown in https://serverfault.com/q/1070757/407952. Those files
> are from a commercial product (Backup Software)
> I wonder if these look OK, or (what I think) are quite incomplete.
>

Looks mostly OK to me.

>
A dependency on network is not needed for sockets with wildcard binds (i.e.
just port, no specific IP address). These will always succeed.

The service doesn't need a general network dep either, if you've received a
connection then the network is usually already up.

Dependency on local-fs is implied in DefaultDependencies, *I think,* so you
don't need to explicitly add it. Although maybe
RequiresMountsFor=/var/opt/omni would be useful.

I wouldn't expect the vendor to include a dep on remote-fs by default. It's
up to the admin to decide this – locally adding dependencies is quite a bit
easier than locally removing unwanted ones (I really wish unit files had a
-= operator, but.) Having things depend on NFS when they don't actually
need it is annoying.

On the other hand, I would *remove* some options – that PIDFile= is
redundant in general, and just outright makes no sense for a templated@
service to use a non-templated pidfile path. The KillMode=process is also
somewhat dubious.

PartOf=omni.service doesn't seem like it would work, as an Accept=yes
socket will indeed use omni@.service (one instance per connection, not a
single long-running daemon – this very much looks like a direct conversion
from inetd-based service to systemd). I'd remove it here.

Similarly, the WantedBy= in omni@.service is nonsensical – inetd
per-connection services can't be started on boot, there's no connection to
attach them to... This kind of service has to be started by the socket, not
through `systemctl enable`.

>


Re: [systemd-devel] How to restart my socket activated service safely ?

2021-07-27 Thread Mantas Mikulėnas
On Tue, Jul 27, 2021 at 10:10 AM Francis Moreau  wrote:
>
> Hello,
>
> During my application update, I want to restart my service which is
> activated by a socket but want to be sure that no request sent to my
> service will be missed. I also want to restart the socket too so
> systemd uses the latest version of the socket unit file.
>
> If I restart the socket when the service is still running then I get
> an error message: "rotor.socket: Socket service rotor.service already
> active, refusing."
>
> If I stop the service first and restart the socket then there's a
> short time frame where requests can be lost.

The old socket has to be unbound before a new one can be put in its
place. Trying to keep the service alive (holding the old listener fd)
would just result in systemd not being able to bind a new socket with
the same address... (And even if that was possible, the old service
wouldn't be able to handle requests arriving on the new socket
anyway.)

So whenever you restart a socket, there will *always* be a short time
frame where the old socket is closed but the new one is not yet
bound/listening. But as soon as the new one is listening, it'll start
queuing the requests even if the service isn't yet running (since it's
a socket-activated service after all) and the number of lost requests
should be minimal.

-- 
Mantas Mikulėnas
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Does systemctl unmask enables a service also?

2021-07-17 Thread Mantas Mikulėnas
On Sat, Jul 17, 2021, 22:23 Debraj Manna  wrote:

> Hi
>
> I have read this article
>  and it appears to
> me that unmasking and starting a service should also enable it back. But on
> trying it does not appear to happen like that
>
> ubuntu@vrni-platform:~$ sudo systemctl status flinkjobs.service
> ● flinkjobs.service - Flinkjobs Service
>Loaded: loaded (/usr/lib/systemd/system/flinkjobs.service; *disabled*;
> vendor preset: enabled)
>

Well, in your case it wasn't actually enabled in the first place...
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Does After=systemd-udevd.service make my service run after the services started by udev rules?

2021-07-13 Thread Mantas Mikulėnas
On Tue, Jul 13, 2021 at 3:46 PM Manuel Wagesreither 
wrote:

> Hi all,
>
> when I have an udev rule with an ENV{SYSTEMD_WANTS}+="my.service", and
> another.service with After=systemd-udevd.service, can I at system boot rely
> on my.service to be already run when another.service starts?
>

No, rule processing is completely separate from udevd's startup. All rules,
even those for devices that are detected "on boot", are run in response to
kernel uevents (either real or faked by systemd-udev-trigger), all of which
happens in udev's main event loop after it has already declared "ready".

-- 
Mantas Mikulėnas
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Mounting a new device to a mount point with an old (auto-generated) but inactive mount unit triggers an immediate unmount

2021-07-08 Thread Mantas Mikulėnas
On Thu, Jul 8, 2021 at 10:12 AM Christian Rohmann <
christian.rohm...@frittentheke.de> wrote:

> Hey Silvio,
> On 07/07/2021 20:04, Silvio Knizek wrote:
>
> after touching /etc/fstab you're supposed to run `systemctl daemon-
> reload` to re-trigger the generators. This is in fact a feature to
> announce changes in configuration files to systemd. See
> man:systemd.generator for more information.
>
> Thanks for the quick reply and the kind hint to the (right) documentation.
>
>
> I am then just wondering why the issue referred to (
> https://github.com/systemd/systemd/issues/1741) is still open?
> Are there still further plans to make systemd properly recognize that the
> inactive unit (pointing to a mount point that is used in a new and active
> unit) actually is superseeded and unmounting it makes now sense as that
> hits the new, working, active mount.
>

I *think* this was supposed to improve with v249:

https://github.com/systemd/systemd/pull/19322
https://github.com/systemd/systemd/issues/19983

In any case I'd suggest then is to somehow give a warning to the user as
> with changes to the systemd units:
>   "Warning: myfancyservice.service changed on disk. Run 'systemctl
> daemon-reload' to reload units."
>

systemd can't make non-systemd tools (such as `mount`) display warnings.

-- 
Mantas Mikulėnas
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Restricting swap usage for a process managed via systemd

2021-07-04 Thread Mantas Mikulėnas
Looks like your Ubuntu version is using the "hybrid" cgroup mode by
default. Cgroup v2 is indeed *enabled* in your kernel, but not necessarily
*in use* – in the hybrid mode, systemd still mounts all resource
controllers (cpu, memory, etc.) in v1 mode and only sets up its own process
tracking in the v2 tree. See `findmnt`.

You could boot with the systemd.unified_cgroup_hierarchy=1 kernel option to
switch everything to cgroups v2, but if you're using container software
(docker, podman) make sure those are cgroups v2-compatible.

On Sun, Jul 4, 2021 at 10:36 AM Debraj Manna 
wrote:

> Hi
>
> I am trying to restrict the swap usage of a process using MemorySwapMax as
> mentioned in the doc
> <http://manpages.ubuntu.com/manpages/bionic/man5/systemd.resource-control.5.html>
>  with
> Ubuntu 18.04.
>
> Environment
> 
>
> ubuntu@vrni-platform:/usr/lib/systemd/system$ uname -a
> Linux vrni-platform 4.15.0-143-generic #147-Ubuntu SMP Wed Apr 14 16:10:11 
> UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
>
> ubuntu@vrni-platform:/usr/lib/systemd/system$ systemctl --version
> systemd 237
> +PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP 
> +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN2 +IDN 
> -PCRE2 default-hierarchy=hybrid
>
> My systemd unit file looks like below
>
> [Unit]
> Description=My service
> After=network.target
> StartLimitIntervalSec=0
> [Service]
> Type=simple
> Restart=always
> RestartSec=1
> User=support
> MemoryMax=2000M
> KillMode=process
> MemoryAccounting=true
> OOMScoreAdjust=1000
> MemorySwapMax=1M
> ExecStart=/usr/bin/java -cp /home/support -XX:NativeMemoryTracking=summary 
> -Xmx1m MemoryConsumer 100 200 1
>
> MemoryMax is working as expected but MemorySwapMax seems to be not taking 
> effect and I am seeing the process, MemoryConsumer still using swap more than 
> the one specified in MemorySwapMax,
>
> MemorySwapMax documentation states "This setting is supported only if the 
> unified control group hierarchy is used and disables MemoryLimit=."
>
> As mentioned here <https://unix.stackexchange.com/a/471495/364181> I can see 
> cgroup v2 enabled on my setup.
>
> ubuntu@vrni-platform:/tmp/tuk$ sudo mount -t cgroup2 none /tmp/tuk
> ubuntu@vrni-platform:/tmp/tuk$ ls -l /tmp/tuk/
> total 0
> -r--r--r--  1 root root 0 Jul  2 17:13 cgroup.controllers
> -rw-r--r--  1 root root 0 Jul  2 17:13 cgroup.max.depth
> -rw-r--r--  1 root root 0 Jul  2 17:13 cgroup.max.descendants
> -rw-r--r--  1 root root 0 Jun 30 14:42 cgroup.procs
> -r--r--r--  1 root root 0 Jul  2 17:13 cgroup.stat
> -rw-r--r--  1 root root 0 Jul  2 17:13 cgroup.subtree_control
> -rw-r--r--  1 root root 0 Jul  2 17:13 cgroup.threads
> drwxr-xr-x  2 root root 0 Jun 30 14:42 init.scope
> drwxr-xr-x 87 root root 0 Jul  2 15:05 system.slice
> drwxr-xr-x  7 root root 0 Jun 30 15:22 user.slice
> ubuntu@vrni-platform:/tmp/debraj$ sudo umount /tmp/tuk
>
> Can someone suggest what configuration I am missing?
>
>
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
>


-- 
Mantas Mikulėnas
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [systemd]: sd-sync lead to kernel panic

2021-06-30 Thread Mantas Mikulėnas
On Wed, Jun 30, 2021 at 10:09 AM www  wrote:

> Dear all,
>
> systemd version: v234
> kernel version: 5.1.5
>
> My embedded system uses systemd. Occasionally kernel panic appears in this
> system. It is found that it is related to sd-sync in systemd. How to
> analyze this and why?
> What causes this problem? Or can you see that sd-sync has a problem
> processing that file or service?
> If you have any ideas or opinions, or need any specific information,
> please let me know.
>
> Thank you.
>
> [ 1664.582102] Unable to handle kernel paging request at virtual address
> 7f8bba1c
> [ 1664.589350] pgd = fb46e47e
> [ 1664.592062] [7f8bba1c] *pgd=
> [ 1664.595666] Internal error: Oops: 8005 [#1] ARM
> [ 1664.600558] CPU: 0 PID: 14730 Comm: (*sd-sync*) Not tainted
> 5.1.5-yocto-s-dirty-fd96c2b #1
>

When shutdown.target is invoked, systemd forks a 'sd-sync' background
process which does literally one thing: it issues a global sync() to begin
flushing all filesystems to disk. There is no specific file involved here,
sync() handles all mounted filesystems at once.

Check what happens if you run `/usr/sbin/sync` from shell, since it does
exactly the same thing. In general there should be nothing special about
systemd calling sync(), it's purely a kernel problem. The only difference
that I can think of is that systemd begins the sync() while all services
are shutting down and still actively writing to files...

-- 
Mantas Mikulėnas
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] /var/lib/machines

2021-06-26 Thread Mantas Mikulėnas
On Sat, Jun 26, 2021, 14:06 Johannes Köhler 
wrote:

> Hi systemd maintainer, again!
>
> with my last post i got a hint to
> follow the netiquette. My netiquette
> with now, was: read manpages and html
> searches before asking stupid questions... :)
>
> So to say, i am happy about private messages for adding
> concrete rules to that basic...
>
> During my tour through systemd there spawned
> some new questions:
>
> _systemd-nspawn_
>
> I think i realized: nspawn is using a machine and an
> image to create a virtual machine container, to run
> as process or thread within systemd.
>
> 1. Can i use systemd-nspawn like QEMU?
>

nspawn creates a container – *not* a virtual machine. It is much more like
LXC or runC than qemu.

Containers only virtualize certain things, such as filesystem or process
tree, but they still share the host kernel, and the host will see each
individual process running inside a container.

(Usually containers even share the host filesystem, like fancy chroots,
although I think nspawn also supports using loop-mounted disk images.)


> 2. When iam installing an systemd linux distribution
> does this result in an systemd container with my
> linux installation (kernel, filesystem, etc.)?
>

Containers don't virtualize the kernel. But they *do* have their own init,
so if the guest distro comes with systemd then your container will run
systemd.

Further, - runs systemd-nspawn service
> before my linux kernel image is running?
> (because: my .host is a machine and an image, also)
>

No. As mentioned, nspawn containers are not virtual machines, they're just
fancy chroots that are created using "namespace" features in the host
kernel. So they cannot possibly run before the kernel.

And the ".host" isn't really a container at all – it's only a convenience
shortcut in systemd's tools (to allow things like 'machinectl shell'), but
it doesn't mean that the host is virtualized in any way.


> _/var/lib/machines_
>
> When trying to mount a btrfs subvolume as user home directory
> on boot, i got an html howto describing this by using
> the service var-lib-machines.mount. Later, i realized i
> can use mounts in /etc/fstab with btrfs subvolumes directly.
>
> 1. What is the /var/lib/machines directory for?
> In the documentation of systemd it gets described with
> the "usecase" to keep machine images?


It's the default location that's used for `machinectl start` and
systemd-nspawn@.service.

What is doing
> the service var-lib-machines.mount? Like I told, i used it
> to mount a btrfs subvolume to my linux filesystem (home)
> during boot sequence. Since that, the service is starting
> on boot because it is still enabled but for mounting
> my home subvolume while fstab is doing the same...
>

.mount units are not services; they literally represent actual mounts.

* If you manually mount something, systemd shows a virtual .mount unit for
it.

* If you create a real .mount unit and start it, systemd mounts the thing
that's described in the .mount unit. That's all it does.

>
As for fstab... Fstab isn't actually doing anything on its own. During
boot, all your fstab entries are *converted* to .mount units and *those*
are used to actually mount things. So it is normal to see fstab entries
duplicated to .mount units.



> https://cloudnull.io/2017/12/btrfs-subvolume-mounts-yes-you-can/
>
> Is that a useless howto?
>
> THX and sincerely
> -kefko
>
>
> --
> Wonderful vim doku:
> "When a mapping triggers itself, it will run forever"
> ___
> 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] Alias for SMTP providers [ie. mutually exclusive service alternatives]

2021-06-16 Thread Mantas Mikulėnas
On Wed, Jun 16, 2021 at 10:43 AM Lennart Poettering 
wrote:

> On Di, 15.06.21 02:03, Kenneth Porter (sh...@sewingwitch.com) wrote:
>
> > What happens if I list multiple services in a Wants= and After= clause
> that
> > are mutually exclusive (eg. sendmail/postfix/exim? How can I say "This
> unit
> > needs to send mail" without knowing which is enabled?
>
> What does "needs to send mail" even mean? That /usr/sbin/sendmail can
> be called to queue a message? That you can talk to localhost:25?
>
> A well behaving MTA actually make /usr/sbin/sendmail work without the
> main mail daemon to be up. The mail is then only enqueued, but not
> dispatched, but that'll be done once the service is fully up.
>

Hmm, I was going to post the same at first, but it doesn't really work in
reverse -- if you want to send mail on shutdown and if the goal of
After=postfix is "run my ExecStop before postfix gets stopped", then
ability to queue doesn't help all that much.

-- 
Mantas Mikulėnas
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Why are core dumps named vgcore.*?

2021-06-15 Thread Mantas Mikulėnas
On Tue, Jun 15, 2021 at 9:04 AM Ulrich Windl <
ulrich.wi...@rz.uni-regensburg.de> wrote:

> Hi!
>
> I'm developing a program that dumps core on some failed assertions. I
> noticed that the core dumps are created in the user directory as
> vgcore..


This doesn't sound like a coredumpctl-managed core dump at all. In fact it
sounds like the dump was created in userspace by Valgrind. (Systemd-managed
core dumps would always go to /var/lib/systemd/coredump, not to the cwd.)


> Where does the name vgcore come from?
>

I used codesearch.debian.net to track it down to valgrind's m_coredump
component.


> And is it OK to remove just those files, or does coredumpctl store
> additional infos?
>

Most likely coredumpctl doesn't have *any* information about this dump,
since it didn't go through the kernel or systemd in the first place.

But in general, coredumpctl is fine with missing/removed coredump files --
that's part of the normal operation; actual dumps are cleaned out much
faster than the corresponding journal entries. You'll probably already see
some of them marked "missing" in the list.

-- 
Mantas Mikulėnas
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] What is the recommended way of announcing a TCP port?

2021-06-14 Thread Mantas Mikulėnas
If you only care about processes on the same system – why not put the
actual socket in /run, as an AF_UNIX socket? That's mostly what /run is for.

On Tue, Jun 15, 2021, 04:18 John Ioannidis  wrote:

> I have an instanced service that gets started and stopped by another
> service: *alice.service *runs the equivalent of *systemsctl start
> alice@foo.service, systemctl start alice@bar.service, systemctl stop
> alice@cat.service*, and so on.
> Each of the instanced services runs a little http service so its status
> can be monitored, metrics scraped, etc. The tcp port on which that service
> runs is just whatever the kernel allocated. I want to export that port
> number so other processes can find it and use it, for example, by doing the
> equivalent of *systemctl list-units | grep alice@ *so they find which
> instances are actually running, and then going about finding the
> corresponding ports.
>
> I can think of a number of ad hoc ways:
>
> * they can write the port number in a file like /run/alice/foo.port,
> /run/alice/bar.port, and whoever is interested can go read those files, in
> the same way that we use .pid files.
> * They can use systemd-notify to export it as "Status"
> * Using a service discovery mechanism would be an overkill, especially
> since whatever is actually talking to those ports is on the same host as
> the services themselves, but that's also a possibility.
>
> Is there a systemd-native way of accomplishing this? It would be nice if
> it were possible to have user-defined properties that could be set with 
> *systemctl
> set-property*, but that is not the case.
>
> Thanks
>
> /ji
> ___
> 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] systemd.socket man pages update suggestion

2021-06-12 Thread Mantas Mikulėnas
On Thu, Jun 10, 2021 at 9:44 PM Ted Toth  wrote:

>  SELinuxContextFromNet=
>Takes a boolean argument. When true, systemd will attempt to
>figure out the SELinux label used for the instantiated
>service from the information handed by the peer over the
>network. Note that only the security level is used from the
>information provided by the peer. Other parts of the
>resulting SELinux context originate from either the target
>binary that is effectively triggered by socket unit or from
>the value of the SELinuxContext= option. This configuration
>option only affects sockets with Accept= mode set to "yes".
>Also note that this option is useful only when MLS/MCS
>SELinux policy is deployed. Defaults to "false".
>
> Add:
> One or more of the associated service files
> StandardInput/StandardOutput/StandardError options should be set to
> socket for this option to work.
>

IMHO that is a bit odd. I don't really see the reason why the option
wouldn't work with any Accept=yes service and would require stdin
specifically...

-- 
Mantas Mikulėnas
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Script in system-sleep that makes an HTTP post

2021-06-11 Thread Mantas Mikulėnas
perror doesn't define exit statuses. It defines syscall return codes and
libc function errno values, which usually have nothing to do with the exit
code of the whole process.

Aside from the convention that "non-zero = failure", you have to look at
the docs of the whole program (e.g. if it's a shell script and the last
thing it did was call `curl` then the exit status is defined by curl).

I don't think system-sleep hooks are the right place to do network calls.
They're run at the last possible point, right before systemd tells the
kernel to suspend, but after it has informed userspace.

Hooking into sleep.target or using dbus to listen for the "PrepareForSleep"
signal might work better. Though I'm not sure how to make sure you get to
process the signal before NetworkManager does the same thing.

On Fri, Jun 11, 2021, 18:05 Doug Koobs  wrote:

> Hello all,
>
> tldr: Is there way I can use systemd to run scripts in
> /usr/lib/systemd/system-sleep at suspend before disabling the network?
>
> I've put a script in /usr/lib/systemd/system-sleep that makes an HTTP
> post to an IFTTT webhook when it's passed "pre" as $1. The script is
> successful if I run it manually, but when systemd runs it when I suspend
> the laptop, running "journalctl -b -u systemd-suspend.service" reports:
>
>  /usr/lib/systemd/system-sleep/outlet.sh failed with exit status 6.
>
> perror defines exit status 6 as: OS error code   6:  No such device or
> address
>
> This sounds like a network problem. If I disable networking and manually
> run the script, I get:
>
>  curl: (6) Could not resolve host: maker.ifttt.com
>
> My assumption is that systemd disables networking before the
> system-sleep scripts are run. Is there way I can use systemd to run the
> script before disabling the network?
>
> Thanks!
>
> Doug
>
> ___
> 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] Fwd: syntax checker

2021-06-02 Thread Mantas Mikulėnas
On Wed, Jun 2, 2021 at 12:10 PM Johannes Köhler <
koehler.johan...@googlemail.com> wrote:

> Currently, iam searching for documentation about using the
> systemd journal (instead of kmesg, syslog etc.) in a
> volatile manner. In presise, i want to connect journalctl
> to /var/run/log ramfs...
>

That's already the default if /var/log doesn't exist. To ensure /run is
always used, you should set "Storage=volatile" in journald.conf.

-- 
Mantas Mikulėnas
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Adding USB ID to hwdb/usb.ids

2021-06-01 Thread Mantas Mikulėnas
On Wed, Jun 2, 2021, 08:04 Greg KH  wrote:

> On Tue, Jun 01, 2021 at 09:38:37PM +0200, Michael Biebl wrote:
> > Am Di., 1. Juni 2021 um 20:44 Uhr schrieb Greg KH <
> gre...@linuxfoundation.org>:
> > > Works for me!  Make sure you are not trying to connect to 'https'.
> >
> > No https? Why?
>
> Because why would serving up text files about this topic requires https?
>

Because browsers are starting to default to "https:" if not specified
otherwise, and visitors now have to scratch heads and jump through hoops to
access those text files. If you don't do HTTPS, at least shut off the HTTPS
listener completely or make it redirect to the HTTP version, instead of
just leaving visitors stare at a 503 page that's pretty much
indistinguishable from "the CGI backend gave up five reboots ago".
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] DHCP6 client failing when /etc is mounted as overlayfs

2021-06-01 Thread Mantas Mikulėnas
On Tue, Jun 1, 2021, 19:42 Alessandro Tagliapietra <
tagliapietra.alessan...@gmail.com> wrote:

> Thanks for helping Mantas,
>
> What I saw is:
>  - before first boot /etc/machine-id is empty (and I think that's expected)
>  - right after boot, /etc/machine-id isn't writable because the root fs is
> mounted as readonly from fstab
>  - after the /etc overlay is mounted /etc/machine-id should still be the
> one from the underlying filesystem and at this point is also writable,
> however it's still empty
>
> During boot I see:
>
> [3.577477] systemd[1]: Initializing machine ID from random generator.
> [3.584284] systemd[1]: Installed transient /etc/machine-id file.
>
> however /etc/machine-id shouldn't be writable at that point, what should I
> do?
>

If it's not writable at that point, systemd will *mount* a temporary
writable file on top of it, and will generate an ID that's temporary for
that boot.

It's possible that your overlay goes on top of that and provides its own
empty machine-id file again...

Make our overlay mount unit depend on whatever service is generating
> machine-id and make sure our mount happens before the generation of
> machine-id?
>

That might work, and would allow the machine-id and thus the DUID to be
persistent.

As an alternative you could tell networkd to use DUID-LLT (?), which
doesn't need the machine-id and just uses the MAC address, but there may be
other things which use the machine-id anyway...


> Thanks
>
> --
> Alessandro Tagliapietra
>
>
> On Tue, Jun 1, 2021 at 12:13 AM Mantas Mikulėnas 
> wrote:
>
>> On Tue, Jun 1, 2021 at 10:07 AM Alessandro Tagliapietra <
>> tagliapietra.alessan...@gmail.com> wrote:
>>
>>> Hello everyone,
>>>
>>> I'm using yocto to create a custom linux image for a raspberry pi.
>>> We have an "agent" that writes /etc/systemd/network/20-eth.network when
>>> the final user wants to have a static IP address and we remove the file
>>> when they switch back to DHCP.
>>>
>>> After creating/deleting the file above we run `networkctl reload &&
>>> networkctl reconfigure eth0`.
>>> We mount the overlayfs with a custom .mount unit.
>>>
>>> We've noticed that DHCP works fine if systemd-networkd starts before we
>>> mount the overlayfs but it doesn't if systemd-networkd is
>>> restarted/reconfigured after the folder is mounted or started after the
>>> overlay .mount unit.
>>>
>>> Every interface DHCP fails with:
>>>
>>> DHCPv6 CLIENT: Failed to set DUID-EN: No medium found
>>> eth0: DHCP6 CLIENT: Failed to set DUID: No medium found
>>>
>>
>> My guess is that it's related to /etc/machine-id somehow becoming
>> inaccessible, since networkd's DUID-EN (DUIDType=vendor) is based on that.
>>
>> --
>> Mantas Mikulėnas
>>
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] DHCP6 client failing when /etc is mounted as overlayfs

2021-06-01 Thread Mantas Mikulėnas
On Tue, Jun 1, 2021 at 10:07 AM Alessandro Tagliapietra <
tagliapietra.alessan...@gmail.com> wrote:

> Hello everyone,
>
> I'm using yocto to create a custom linux image for a raspberry pi.
> We have an "agent" that writes /etc/systemd/network/20-eth.network when
> the final user wants to have a static IP address and we remove the file
> when they switch back to DHCP.
>
> After creating/deleting the file above we run `networkctl reload &&
> networkctl reconfigure eth0`.
> We mount the overlayfs with a custom .mount unit.
>
> We've noticed that DHCP works fine if systemd-networkd starts before we
> mount the overlayfs but it doesn't if systemd-networkd is
> restarted/reconfigured after the folder is mounted or started after the
> overlay .mount unit.
>
> Every interface DHCP fails with:
>
> DHCPv6 CLIENT: Failed to set DUID-EN: No medium found
> eth0: DHCP6 CLIENT: Failed to set DUID: No medium found
>

My guess is that it's related to /etc/machine-id somehow becoming
inaccessible, since networkd's DUID-EN (DUIDType=vendor) is based on that.

-- 
Mantas Mikulėnas
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] socket activation socket state

2021-05-28 Thread Mantas Mikulėnas
On Fri, 28 May 2021 at 21:27, Ted Toth  wrote:

> When a socket service runs is there a way to determine the socket
> state? If the socket file contains:
> Accept=true
>
> does systemd call accept with the socket before execing the service in
> which case I don't have to call accept?


Yes, with Accept=yes (similar to inetd’s “nowait”) systemd itself will
accept connections and will start a separate instance of your templated
service per connection.

With Accept=no you get the listening socket instead and a single
non-templated service handles everything.

Is there a way to
> differentiate a socket with Accept set to true versus one without
> Accept or with it set to false? I've read the sd_is_socket man page
> but it's not clear to me if it can answer the question I posed.


Normally a service would just expect to be given one or the other... But I
think you can use this getsockopt(SO_ACCEPTCONN) to check:
https://stackoverflow.com/q/10260600

You could also just try calling accept() on it, I guess...



>
> Ted
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
>
-- 
Mantas Mikulėnas
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] On the IRC situation

2021-05-25 Thread Mantas Mikulėnas
Hi,

As you might've heard, the freenode IRC network is suddenly under new
ownership. Neither the process nor the result are making many people
comfortable, so the old staff collectively packed up and left to start a
new network in its place, with many channels either following them to the
new place (#ubuntu and the OG #gentoo included) or to somewhere else that
is not freenode.

The #systemd regulars have pretty much already moved the channel to this
new network on their own, so I have registered it there as well (as a
"community" since I'm ~not really~ a representative). So if there are no
objections I'll make a PR to update systemd's README files to "s/
freenode.org/libera.chat/g" sometime later.

-- 
Mantas Mikulėnas (grawity)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Alias for template/instance service unit

2021-04-22 Thread Mantas Mikulėnas
On Thu, Apr 22, 2021 at 9:18 PM Hans Gruber  wrote:

> Hello,
>
> I am having problems with the aliases and "Alias=' directive related to
> the template service unit.
>
> According to
> https://www.freedesktop.org/software/systemd/man/systemd.unit.html
>
> > "A template instance may only be aliased by another template instance,
> and the instance part must be identical. A template may be aliased by
> another template (in which case the alias applies to all instances of the
> template). As a special case, a template instance (e.g. "alias@inst.service")
> may be a symlink to different template (e.g. "template@inst.service"). In
> that case, just this specific instance is aliased, while other instances of
> the template (e.g. "alias@foo.service", "alias@bar.service") are not
> aliased. Those rule preserve the requirement that the instance (if any) is
> always uniquely defined for a given unit and all its aliases."
>
> I have exactly these two cases and requirements and cannot find example.
>
> >  "A template may be aliased by another template (in which case the alias
> applies to all instances of the template)"
>
> eg: How to create an alias using `Alias=` for a service template core@.service
> which will have maybe 8 or 16 instances (eg: core@cpu01.service
> core@cpu02.service ..) which will apply to all instances when enabled
> using eg allcores@.service.
>

I think you're misunderstanding what "applies to all instances" means. It
does not give you a super-unit that controls all instances in unison --
rather, it gives you a template alias that will provide an alias for *each
instance individually*.

But one instance is still aliased to one instance. For example, if you
alias foo@.service => bar@.service, then you automatically get
foo@cpu1.service => bar@cpu1.service, and so on. That's what template
aliases do.

If you want to control multiple instances at once, you might be looking for
two other features:
1. Custom target units, which allow you to *start* all instances at once;
2. Wildcard support in `systemctl` commands, which allows you to see the
status of all loaded instances at once (systemctl status "foo@*.service").

-- 
Mantas Mikulėnas
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] "Correct" way to obtain DHCP lease info?

2021-04-22 Thread Mantas Mikulėnas
On Thu, Apr 22, 2021 at 6:17 PM Bruce A. Johnson <
bjohn...@blueridgenetworks.com> wrote:

> Silvio, thanks for the suggestion. I'm not concerned with keeping the
> lease forever; the system actually experiences a topology change as it's
> switched from one network to another, and I can catch that from the DBus
> events that occur. The problem we're trying to solve is to contact some
> address that we're sure exists on the network, without knowing anything
> about that network. The default gateway was an obvious choice, but someone
> wants to cover the case of there being a private LAN with no gateway. The
> only other choice I could see is the DHCP server that issues the lease.
>
Hmm, don't you also have the case of there being a private LAN with no
gateway and no DHCP? Or possibly the case of a DHCP relay. And since you
don't know anything about the network, you also don't know whether the
address will respond to your communication attempts (other than ARP) -- it
might be pingable but it might be not.

I'm curious about what brought this problem into existence in the first
place. Why *is* it necessary to contact a random address within the
network? (If it's to check that the physical interface is working, then
just the fact that you somehow acquired a lease would be enough. no?)

-- 
Mantas Mikulėnas
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] systemd-resolve SERVFAIL on lookups found by upstream DNS server

2021-04-17 Thread Mantas Mikulėnas
On Fri, Apr 16, 2021 at 7:41 PM Francesco Belladonna 
wrote:

> Greetings,
> I’ve been trying to debug why systemd-resolve is not able to perform nslookup
> static-exp1.licdn.com.
> Altering /etc/resolv.conf to point directly to the DNS server (or my
> router in this case) solves the problem, which seems to suggest the problem
> is isolated to systemd-resolve.
> The problem is identical on both my laptops which are running 2 different
> O.S. (Kubuntu 18.04 and Fedora 33).
> The entire DNS configuration is provided by the router acting as DHCP
> server.
>
> The system I’m performing my tests is Kubuntu, where the systemd version
> is:
>
> systemd --version
> systemd 237
> +PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP 
> +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN2 +IDN 
> -PCRE2 default-hierarchy=hybrid
>
> SYSTEMD_LOG_LEVEL is set to debug.
> Is there any other useful tool I can use to debug this further?
> The problematic domain is static-exp1.licdn.com which is the CDN for
> LinkedIn. I have no idea why *this* specific domain is affected.
>
Most likely because it has one of those *interesting* CNAME chains:

$ rdt static-exp1.licdn.com
static-exp1.licdn.com = 2-01-2c3e-003d.cdx.cedexis.net
   2-01-2c3e-003d.cdx.cedexis.net = li-prod-static.azureedge.net
  li-prod-static.azureedge.net = li-prod-static.afd.azureedge.net
 li-prod-static.afd.azureedge.net =
star-azureedge-prod.trafficmanager.net
star-azureedge-prod.trafficmanager.net =
dual.t-0009.t-msedge.net
   dual.t-0009.t-msedge.net = t-0009.t-msedge.net
  t-0009.t-msedge.net =
Edge-Prod-LON21r3.ctrl.t-0009.t-msedge.net
 edge-prod-lon21r3.ctrl.t-0009.t-msedge.net =
standard.t-0009.t-msedge.net
standard.t-0009.t-msedge.net = 13.107.213.19,
13.107.246.19, 2620:1ec:46::19, 2620:1ec:bdf::19

(Though sometimes it's shorter, pointing at epsiloncdn instead of Azure. It
depends on where you're making the query from.)

I *think* this was fixed in git a few weeks ago. There's already an Ubuntu
bug report for the same issue:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1921636

-- 
Mantas Mikulėnas
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Q: asymmetry of ExecStop and ExecStart

2021-04-14 Thread Mantas Mikulėnas
On Wed, Apr 14, 2021 at 1:42 PM Andrei Borzenkov 
wrote:

> On Wed, Apr 14, 2021 at 1:35 PM Ulrich Windl
>  wrote:
> >
> > Hi!
> >
> > I have two services defined, one using ExecStart only, the other
> ExecStop only.
> > Then I discovered some asymmetry:
> > systemd is still starting the service with the ExecStop only, while the
> one with the ExecStart only never is stopped.
> >
> > Is that intended, or do I have some configuration error in the ExecStart
> only service?
> >
> > The units look like this:
> > # /usr/lib/systemd/system/dellcd-log-start.service
> > [Unit]
> > Description=Log Start on Dell LCD
> > Documentation=man:dellcd(1)
> > DefaultDependencies=no
> > After=local-fs.target
> > Before=sysinit.target
> > Requires=local-fs.target
> > ConditionPathExists=/usr/bin/...
> >
> > [Service]
> > Type=oneshot
> > TimeoutSec=10
> > ExecStart=/usr/bin/...
> >
>
> Type=oneshot services go from "starting" directly to "dead"; they are
> never active and so there is nothing to stop.
>

Unless they have RemainAfterExit=yes. See e.g. nftables.service or
systemd-user-sessions.service.

-- 
Mantas Mikulėnas
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] .local searches not working

2021-04-09 Thread Mantas Mikulėnas
On Sat, Apr 10, 2021, 02:02 Mantas Mikulėnas  wrote:

> On Fri, Apr 9, 2021, 22:28 Phillip Susi  wrote:
>
>>
>> Silvio Knizek writes:
>>
>> > So in fact your network is not standard conform. You have to define
>> > .local as search and routing domain in the configuration of sd-
>> > resolved.
>>
>> Interesting... so what are you supposed to name your local, private
>> domains?
>
>
> .home.arpa is reserved for that purpose by IANA (as part of the Homenet
> work, but explicitly stated that its usage is not limited to Homenet
> protocols).
>

Er, I think I mixed up IANA and IETF there. It should be the latter, I
think.



> Though if you own a public domain there's nothing wrong with using a
> subdomain of it for your private LAN, either.
>
>   I believe Microsoft used to ( or still do? ) recommend using
>> .local to name your domain if you don't have a public domain name, so
>> surely I'm not the first person to run into this?
>
>
> It could be that at some point they did. I've seen Active Directory
> domains named "university.local" (even though they *did* have a public
> domain...) But IIRC they went back on that recommendation.
>
> Why does
>> systemd-resolved not fall back to DNS if it can't first resolve the name
>> using mDNS?  That appears to be allowed by the RFC.
>>
>
> Simply falling back for each individual query is probably not desirable
> because it would also leak local hostnames for people who *do* use mDNS.
>
> Systemd-resolved could implement the "check if local. SOA exists" probe
> that AFAIK Apple does, I think there was a github thread about it...
>
> ... Actually, if you manually set an interface's search domain in resolved
> to "local", doesn't that make it start using DNS for this domain? I cannot
> test right now, but I'm *sure* I've seen something like that in resolved's
> docs.
>
>>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] .local searches not working

2021-04-09 Thread Mantas Mikulėnas
On Fri, Apr 9, 2021, 22:28 Phillip Susi  wrote:

>
> Silvio Knizek writes:
>
> > So in fact your network is not standard conform. You have to define
> > .local as search and routing domain in the configuration of sd-
> > resolved.
>
> Interesting... so what are you supposed to name your local, private
> domains?


.home.arpa is reserved for that purpose by IANA (as part of the Homenet
work, but explicitly stated that its usage is not limited to Homenet
protocols).

Though if you own a public domain there's nothing wrong with using a
subdomain of it for your private LAN, either.

  I believe Microsoft used to ( or still do? ) recommend using
> .local to name your domain if you don't have a public domain name, so
> surely I'm not the first person to run into this?


It could be that at some point they did. I've seen Active Directory domains
named "university.local" (even though they *did* have a public domain...)
But IIRC they went back on that recommendation.

Why does
> systemd-resolved not fall back to DNS if it can't first resolve the name
> using mDNS?  That appears to be allowed by the RFC.
>

Simply falling back for each individual query is probably not desirable
because it would also leak local hostnames for people who *do* use mDNS.

Systemd-resolved could implement the "check if local. SOA exists" probe
that AFAIK Apple does, I think there was a github thread about it...

... Actually, if you manually set an interface's search domain in resolved
to "local", doesn't that make it start using DNS for this domain? I cannot
test right now, but I'm *sure* I've seen something like that in resolved's
docs.

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


Re: [systemd-devel] Is it meant to be possible to set IO[Read|Write]BandwidthMax on a slice ?

2021-04-08 Thread Mantas Mikulėnas
On Thu, Apr 8, 2021 at 6:19 PM Hadrien Grasland <
hadrien.grasl...@ijclab.in2p3.fr> wrote:

> Le 08/04/2021 à 16:11, Lennart Poettering a écrit :
> > On Do, 08.04.21 12:24, Hadrien Grasland (
> hadrien.grasl...@ijclab.in2p3.fr) wrote:
> >
> >> Hi everyone,
> >>
> >> In a scenario where running benchmarks on dedicated hardware is not
> >> possible, I'm trying to momentarily cap the I/O bandwidth used by
> >> interactive user sessions while benchmarks are running, in order to
> improve
> >> the stability of said benchmark's I/O performance.
> > Is this on cgroupsv1 or cgroupsv2?
> >
> > IIRC there was some issue that the block io controller wasn't fully
> > recursive on cgroupsv1. It should work on cgroupsv2.
>
> This is on a hybrid cgroup configuration. I (perhaps mistakenly) assumed
> that modern systemd (v246) will use the cgroups v2 hierarchy in that
> case, even though cgroups v1 is still exposed for compatibility with
> older apps.
>

If e.g. the io controller is exposed through cgroups v1, as far as I know
it cannot be simultaneously used through cgroups v2, and vice versa.

(Hmm, wasn't there an option to choose which controllers to assign to v1
and which ones to v2?)

-- 
Mantas Mikulėnas
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Session-specific user services

2021-04-02 Thread Mantas Mikulėnas
On Fri, Apr 2, 2021 at 7:17 PM Arseny Maslennikov 
wrote:

> Hi everyone!
>
> Recently there's a trend for session-specific processes and services
> (and even GUI apps, via `systemd-run --scope') to run as their own user
> units on eligible systems/distros, to have a clean and controlled cgroup
> hierarchy.
>
> I've been looking at https://systemd.io/DESKTOP_ENVIRONMENTS/ and see no
> answer to the following question: how can a process, e. g. gvfs-daemon,
> know which logind-session is it run for (for example, to find out the
> seat by session ID), if it's actually in a user service unit?
> The libsystemd source for sd_pid_get_session(), which is used by gvfs as
> of today, gives a hint that function won't work in that case, since a
> user service process's /proc/self/cgroup does not contain
> "session-XXX.scope".
>

I don't think most daemons need to know this? Polkit has already changed
its policy from allowing actions for specific active session, to allowing
them for the whole uid if it owns *an* active session.

Also, part of the trend includes not running more than one graphical
session per uid. So the daemon doesn't really need to ask, if there's only
one answer. (Note that stuff like $DISPLAY gets imported into systemd
--user's environment, to make it available to the services'
environment, and you can't make $DISPLAY have two values at once.)

And if the daemon did know "its" session, that sounds like it would make it
*less* useful with two sessions, because you would have no way to run a
second instance for the other session anyway.

-- 
Mantas Mikulėnas
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] help with sockets and services and inetd-like workflows

2021-03-22 Thread Mantas Mikulėnas
I would suggest adding StandardError=journal, so that you get to see the
Python exceptions when they happen.

On Mon, Mar 22, 2021, 04:21 Matt Zagrabelny  wrote:

> Greetings,
>
> I'm running systemd 241-7~deb10u6, Debian 10 (Buster).
>
> I am attempting to have an inetd like service run, where systemd listens
> on a port (TCP 9000) and passes the data to a python3 script's STDIN.
>
> Here are my unit files:
>
> ==> /etc/systemd/system/cdr-adjunct@.service <==
> [Unit]
> Description=Call Detail Record Adjunct Processor
>
> [Service]
> ExecStart=/opt/src/cdr-adjunct/python/cdr-adjunct.py
> StandardInput=socket
> User=phone
>
> ==> /etc/systemd/system/cdr-adjunct.socket <==
> [Unit]
> Description=Socket for Call Detail Record Adjunct Processor
>
> [Socket]
> ListenStream=9000
> Accept=yes
>
> [Install]
> WantedBy=sockets.target
>
> While the mechanics work, there are, seemingly, issues in my process. I'm
> seeing over 2000 failed units for the service in question.
>
> $ sudo systemctl --state=failed
>   UNIT  LOAD
> ACTIVE SUBDESCRIPTION
> ● cdr-adjunct@0-131.212.109.135:9000-10.27.0.3:31541.serviceloaded
> failed failed Call Detail Record Adjunct Processor (10.27.0.3:31541)
> ● cdr-adjunct@1-131.212.109.135:9000-10.27.0.3:32034.serviceloaded
> failed failed Call Detail Record Adjunct Processor (10.27.0.3:32034)
> [snip ~2000 lines]
> ● cdr-adjunct@999-131.212.109.135:9000-10.27.0.3:10955.service  loaded
> failed failed Call Detail Record Adjunct Processor (10.27.0.3:10955)
>
> My python3 script processes STDIN as such:
>
> for line in sys.stdin:
>
>  #do stuff
>
> I'm a little confused as to where to look to determine why I'm seeing so
> many failed units.
>
> Any help or suggestions are very welcome.
>
> Thank you!
>
> -m
> ___
> 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] Activate netdev only on demand (e.g. for wireguard connection)

2021-03-11 Thread Mantas Mikulėnas
On Thu, Mar 11, 2021 at 12:01 PM Reindl Harald 
wrote:

>
>
> Am 11.03.21 um 06:36 schrieb Amish:
> > Hello
> >
> > So I have a wireguard setup which I use to connect to my server.
> >
> > But I do not connect to it daily, just once a in a while.
> >
> > I have setup wg0.netdev file and wg0.network file and all is working
> fine.
> >
> > But how do I set it up such that interface wg0 does not connect
> > automatically but comes up only when I run:
> >
> > #networkctl up wg0
> >
> > Effectively I want wireguard to connect/disconnect on demand
>
> given that wireguard runs directly in the kernel and has no single
> userland process what problem would you like to solve and why?
>

It might be the problem that I also have, which is that you don't always
want certain destinations to be *permanently* routed through the tunnel --
e.g. you might have a VPN for 0.0.0.0/0 ::/0 (the whole internet) but don't
actually want it to be active all the time, only when the need for it
occurs.

For example I have a tunnel through a USA server for websites that block
Europe -- it routes 0/0 because I don't know the "wanted" destinations in
advance, but at the same time I don't want the system to *default* to
sending all my traffic halfway around the world and back, so it has to be
"on demand".

People are in a hurry to suggest "openvpn is meh, use wg-quick" and then
the same people suggest "wg-quick is meh, use networkd" forgetting that A
and C don't necessarily intersect.

-- 
Mantas Mikulėnas
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Q; syslog.socket dependency

2021-03-11 Thread Mantas Mikulėnas
On Thu, Mar 11, 2021, 13:17 Ulrich Windl 
wrote:

> Hi!
>
> I have a unit that uses logger, and I want to run it after syslog is
> available. So I added syslog.socket as dependency, but it fails:
> Mar 11 12:11:02 jeos1 systemd[1]: syslog.socket: Socket service
> syslog.service not loaded, refusing.
> Mar 11 12:11:02 jeos1 systemd[1]: Failed to listen on Syslog Socket.
>
> Doesn't journald also "provide" syslog.socket?
>

Yes but no. "Syslog.socket" is specifically for internal forwarding *from*
journald to an external syslogd.

What you're looking for (the journald *input* socket that's used by other
programs) is actually "systemd-journald-dev-log.socket".

Usually there should be no need to explicitly order against it, as normal
services are already indirectly ordered after sockets.target as a whole.
You'll only need an After if you're using DefaultDependencies=no.
___
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

2021-03-01 Thread Mantas Mikulėnas
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


Re: [systemd-devel] Looking for known memory leaks triggered by stress testing add/remove/up/down interfaces

2021-02-19 Thread Mantas Mikulėnas
On Fri, Feb 19, 2021 at 4:49 PM Lennart Poettering 
wrote:

> On Fr, 19.02.21 09:28, Robert P. J. Day (rpj...@crashcourse.ca) wrote:
>
> > i guess i expected that the CVE identifier would be in the commit
> > message. anyway, time to examine ...
>
> CVEs are assigned/published long after the commits to fix the issues
> are made. We cannot retroactively change git commits, that's just not
> how this works.
>

This *could* work with git notes, it seems --grep searches them as well.

-- 
Mantas Mikulėnas
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] timedate1 permissions

2021-02-17 Thread Mantas Mikulėnas
Systemd D-Bus services use polkit for authorization when the message is
sent by someone not uid 0. Depending on which version you have, you can
write a .pkla file (Debian) or a JavaScript function (other distros) that
allows a specific action for a specific user or group.

You'll want to allow the "org.freedesktop.timedate1.set-timezone" action
(see `pkaction`). Recent versions have some documentation in `man 8 polkit`.

If the system doesn't have polkit installed, then all you have is the
hardcoded "uid == 0" check. (Polkit *is* the configuration facility for
that.)


On Wed, Feb 17, 2021 at 8:18 PM Greg Wilson-Lindberg 
wrote:

> First, I hope that I have found the proper list for this question, if not
> I'm sorry to bother you all.
>
> I'm trying to run a program that changes the timezone. Our application is
> using the dbus facility to change the time zone. It works when run as root
> but fails when run as our user. I had thought initially that the problem
> was with dbus permissions but have since found out that the fact that the
> messages are going over the dbus means that the dbus permissions are set
> correctly.
>
> So, it seems that the systemd.timedate1 utility has it's own permissions
> that is rejecting our request to change the timezone. My question at this
> point becomes, how do I change the permissions for the system.timedate1
> utility to allow my non-root user to change the time and timezone?
>
> Regards,
> Greg Wilson-Lindberg
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
>


-- 
Mantas Mikulėnas
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] timesyncd log messages galore

2021-02-11 Thread Mantas Mikulėnas
On Thu, Feb 11, 2021 at 6:07 PM Ede Wolf  wrote:

> Thanks. Indeed, stopping radvd made these messages stop appearing.
> Now I am no IPv6 guru, but having routeradvertisments is not too
> uncommon, to the best of my knowledge.
>

RAs shouldn't be extremely frequent. An hour is a common interval for
periodic RAs -- certainly not minutes or seconds.

OTOH, I am not seeing any such messages on any of my IPv6 hosts using
timesyncd. There is a burst of "network changed" messages on boot,
presumably in response to bridges and tunnels being set up, but the daemon
stays quiet afterwards. Currently it has recorded 1.988s total CPU usage
after 12 days of uptime.


> So the punchline is, that timesynd is not really usable with ipv6
> networks? Am I getting that correct?
>

No, sounds more like it's just not really usable with *your* IPv6 network.

-- 
Mantas Mikulėnas
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] systemd-resolved only returns v6 addresses

2021-01-27 Thread Mantas Mikulėnas
I was probably too hasty in saying it's the upstream resolver's fault --
it's still systemd-resolved which makes the two A and  queries and
aggregates their responses. The upstream just happens to choose different
nameservers for both, but that's normal operation.

Either way, I'd mostly blame O365 for doing weird things, but I don't have
enough DNS knowledge to say whether resolved could or should be fixed to
deal with it. (Then again it wouldn't be the first time when
systemd-resolved is rejecting responses that are otherwise entirely
valid...)

On Wed, Jan 27, 2021 at 1:27 PM Stefan Tatschner 
wrote:

> On Wed, 2021-01-27 at 13:10 +0200, Mantas Mikulėnas wrote:
> > So it is entirely possible that when resolved makes two queries, one
> > for A records and another for , it receives conflicting
> > information about the target simultaneously being an alias and not
> > being an alias (due to your upstream resolver choosing different NS
> > each time), and I wouldn't be surprised if that causes resolved to
> > reject (or just overlook) some of the returned DNS records.
>
> Thanks for the analysis! I am wondering what's the issue here:
> Is
>
> * my upstream DNS resolver broken?
> * Microsoft's DNS setup broken?
> * has systemd-resolved a bug?
>
> For the first point I will see what I can do.
>
> Stefan
>
>

-- 
Mantas Mikulėnas
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] systemd-resolved only returns v6 addresses

2021-01-27 Thread Mantas Mikulėnas
I would guess the *upstream *server used by resolved is reacting negatively
to weirdness in O365 authoritative DNS.

* outlook.office365.com is indeed an alias (CNAME) for
outlook.ha.office365.com.
* The domain ha.office365.com has two sets of nameservers: ns{1..4}-
ms-acdc.office.com and tm{1..2}.edgedns-tm.info, which don't seem to agree
with each other.
* According to the first set of nameservers, outlook.ha.office365.com is a
two-layer alias for outlook.ms-acdc.office.com and then
FRA-efz.ms-acdc.office.com.
* But according to the second set of nameservers, outlook.ha.office365.com
is *not* an alias -- those servers perform some sort of CNAME flattening
and directly return A/ records. (Though if you ask them very nicely for
CNAME records, they will actually admit that it's an alias for
fra-mvp.trafficmanager.net... which is different again.)

So it is entirely possible that when resolved makes two queries, one for A
records and another for , it receives conflicting information about the
target simultaneously being an alias and not being an alias (due to your
upstream resolver choosing different NS each time), and I wouldn't be
surprised if that causes resolved to reject (or just overlook) some of the
returned DNS records.


On Wed, Jan 27, 2021 at 12:11 PM Stefan Tatschner 
wrote:

> Heya,
>
> I was confronted with a weird problem this morning. On my location
> there is only IPv4 available. My company uses the shiny new Office365
> service for email. This morning I was not able to connect to my email
> account. The reason was systemd-resolved returning only IPv6 addresses
> for the email host:
>
> $ resolvectl query outlook.office365.com
> outlook.office365.com: 2603:1026:c0a:855::2-- link: enp3s0
>2603:1026:c0a:857::2-- link: enp3s0
>2603:1026:c0a:8b7::2-- link: enp3s0
>2603:1026:c0a:850::2-- link: enp3s0
>2603:1026:c0a:852::2-- link: enp3s0
>2603:1026:c0a:851::2-- link: enp3s0
>2603:1026:101:1::2  -- link: enp3s0
>2603:1026:c0a:854::2-- link: enp3s0
>(outlook.ha.office365.com)
>
> -- Information acquired via protocol DNS in 820us.
> -- Data is authenticated: no
>
> The `host` utility instead reports this:
>
> $ host outlook.office365.com
> outlook.office365.com is an alias for outlook.ha.office365.com.
> outlook.ha.office365.com is an alias for outlook.ms-acdc.office.com.
> outlook.ms-acdc.office.com is an alias for AMS-efz.ms-acdc.office.com.
> AMS-efz.ms-acdc.office.com has address 40.101.12.66
> AMS-efz.ms-acdc.office.com has address 52.97.250.210
> AMS-efz.ms-acdc.office.com has address 40.101.121.34
> AMS-efz.ms-acdc.office.com has address 52.97.155.114
> AMS-efz.ms-acdc.office.com has IPv6 address 2603:1026:c03:581b::2
> AMS-efz.ms-acdc.office.com has IPv6 address 2603:1026:207:177::2
> AMS-efz.ms-acdc.office.com has IPv6 address 2603:1026:207:64::2
> AMS-efz.ms-acdc.office.com has IPv6 address 2603:1026:206:4::2
>
> The problem was that systemd-resolved only returned ipv6 addresses
> although I have no ipv6 connectivity. Why does this happen? Is there an
> artificial max. addresses limit with the sorting rule ipv6 first in
> systemd-resolved?
>
> I work-arounded it with an entry in /etc/hosts for now.
>
> Stefan
>
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
>


-- 
Mantas Mikulėnas
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Why systemd-nspawn is slower than docker, podman and qemu?! how to Improve nspawn performance?

2021-01-25 Thread Mantas Mikulėnas
On Mon, Jan 25, 2021, 12:56 Badr Elmers  wrote:

> Hi,
> Why nspawn is slow compared to docker podman and even qemu?!
> CPU tasks take twice of the time it takes in docker, podman or qemu
>
> here I filled a request to improve nspawn performance which contain the
> steps and the full test result:
> https://github.com/systemd/systemd/issues/18370
>
> Do you know why systemd-nspawn is slower? how can I improve it?
>
> thank you
>
>
>
Have you tried completely *disabling* the syscall filtering and all other
seccomp-based features? Export SYSTEMD_SECCOMP=0 before running nspawn and
check if it makes any difference...
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] automount behavior with multiple IPS

2021-01-24 Thread Mantas Mikulėnas
On Sun, Jan 24, 2021, 20:58 Weatherby,Gerard  wrote:

> When systemd-automount queries an NFS server with multiple IPs, does it
> try all of the them (the default behavior of the similar autofs package) or
> just use one, or something else?
>

Systemd does not have any special handling for NFS – it will not query the
server at all; it will more or less just spawn the standard `mount` command
and let it handle the rest. If the hostname resolves to multiple addresses,
I assume that will be handled by nfs-utils' `mount.nfs` somehow.

(systemd .automount units only use autofs as the trigger for activating a
regular .mount, so everything is the same between e.g. fstab-mounted and
systemd-automounted filesystems.)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Antw: [EXT] Re: successful mount starts a service - how?

2021-01-19 Thread Mantas Mikulėnas
On Tue, Jan 19, 2021, 09:50 Ulrich Windl 
wrote:

> >>> Andrei Borzenkov  schrieb am 19.01.2021 um 06:30
> in
> Nachricht <3a365c71-004e-031e-4153-80c376d80...@gmail.com>:
> > 19.01.2021 04:00, lejeczek пишет:
> >> hi guys.
> >>
> >> I'm fiddling with it but have run out of options/ideas.
> >> What I would like to have is systemd starts a service when a device, in
> >> my case a crypt-luks device, gets mounted which mount would happen by
> >> manual 'cryptsetup open'
> >
> > I am not aware that "cryptsetup open" mounts anything. I do not even see
> > any option to specify mount point in its invocation. Please show exact
> > command you are using that "mounts" encrypted container.
>
> But it will make some device (/dev/mapper) to appear.
>

Yes, and that can be used to trigger a mount unit.

With earlier systemd versions it was actually enough to have a fstab entry
with "auto,nofail" and systemd would immediately activate such mounts as
soon as the source device appeared.

In systemd v242 this behavior was removed (and unfortunately, there is no
convenient fstab option to re-enable it), but the same type of dependency
can still be manually added using:

systemctl add-wants 'dev-mapper-luks\x2bfoo.device' foo.mount
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] service killed when usb device reloaded

2021-01-13 Thread Mantas Mikulėnas
On Wed, Jan 13, 2021, 20:17 Belisko Marek  wrote:

> Hi,
>
> I'm facing a strange issue. I have gsm modem and when modem is
> restarted (removed from usb bus and plugged back) one of services is
> restarted (with enabled systemd debug level):
>
> Jan 07 09:07:00 device systemd[1]: Received SIGCHLD from PID 166
> (systemtest).
> Jan 07 09:07:00 device kernel[174]: option1 ttyUSB4: GSM modem
> (1-port) converter now disconnected from ttyUSB4
> Jan 07 09:07:00 device systemd[1]: Child 166 (systemtest) died
> (code=killed, status=1/HUP)
>

Sounds like your process had opened /dev/ttyUSB4 at some point, and this
became its "controlling tty" (because services start without one).

The kernel always sends SIGHUP to processes when their controlling tty
disappears or loses carrier (same happens when an xterm is closed). The
signal literally means "hang up".

If your service is accessing the modem, use the O_NOCTTY flag to avoid this.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] SystemD dependency problem

2020-12-22 Thread Mantas Mikulėnas
On Tue, Dec 22, 2020 at 1:36 PM Ronald Wimmer  wrote:

> On a server running OL 7.9 with SystemD 219 we have a custom SystemD
> service we have something like
>
>
> [Unit]
> Requires=network.target docker.service
>
> [Service]
> Restart=always
> RestartSec=10
> TimeoutSec=300
> WorkingDirectory=/data/someapplication
> ExecStartPre=
> ExecStart=
> ExecStop=
> ExecStopPost=
>
> [Install]
> WantedBy=network-online.target
>
> which does not work. This service leads do several other services
> (rsyslogd, docker, network-online.target, ...) to be stuck in "start
> waiting".
>
> My question is why? Is there any obvious misconfiguration in the service
> above I am too blind to see?
>

As a special case, when a target has Wants= for some unit, it will
automatically add an After= as well. (So from your unit's point of view,
you have [Install] WantedBy=network-online.target, so you can imagine that
you automatically have a Before=network-online.target as well – unless you
explicitly specify the opposite.)

However, Docker has "After=network-online.target", so you end up creating
an ordering loop:

* yourthing.service has no After=, but it runs `docker` commands and cannot
finish until docker.service is up;
* docker.service explicitly has After=network-online.target and won't start
until that target is reached;
* but network-online.target has an implicit After=yourthing.service (as
explained above).

-- 
Mantas Mikulėnas
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Udev rules on reboot

2020-12-20 Thread Mantas Mikulėnas
On Sun, Dec 20, 2020, 21:37 Adi Ml  wrote:

> Yes. Thats exactly what I mean (what mantas said)- ATTR{authorized}="0".
> I would like to have a usb whitelist via udev and want it to be enforced on
> devices which connected pre boot too.
>
> authorized_default=0- it seems the same like
> ATTR{authorized}="0", isnt it?
>

Not quite – I guess there is a very small window of time between connection
and udev processing where the device is still authorized, before udev
removes the authorization.

So having authorized_default=0,  and then setting all allowed devices to
authorized=1  (allow only approved devices, block the rest) is probably
slightly safer technically.

(Actually maybe you should just use USBGuard instead of writing custom
rules?)

This is what I used to have a long time ago:

ACTION!="add", GOTO="deauthorize_end"
SUBSYSTEM!="usb", GOTO="deauthorize_end"

TEST=="authorized_default", ATTR{authorized_default}="0",
GOTO="deauthorize_end"

ENV{ID_VENDOR}=="Yubico", ENV{ID_MODEL}=="Yubikey_NEO*",
ATTR{authorized}="1", GOTO="deauthorize_end"

ENV{ID_VENDOR}=="Zubico", ENV{ID_MODEL}=="Zubikey_GEO*",
ATTR{authorized}="1", GOTO="deauthorize_end"

LABEL="deauthorize_end"
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Mount options for ESP, LUKS and rootfs in automatic partition discovery and mounting

2020-12-20 Thread Mantas Mikulėnas
On Sun, Dec 20, 2020 at 3:49 PM Lennart Poettering 
wrote:

> On Sa, 19.12.20 15:31, Mantas Mikulėnas (graw...@gmail.com) wrote:
>
> > > THere's an RFE issue open asking to support rootflags= on the kernel
> > > cmdline for the automatically discovered rootfs (that's the option the
> > > kernel uses on traditional rootfs mounting). I think that definitely
> > > makes sense, it just needs someone to implement things.
> > >
> > > I figure in the long run systemd-gpt-auto-generator probably needs
> > > some minimal config file where you can configure these
> > > options. Alternatively, maybe initially adding kernel cmdline params
> > > for each type of mount would suffice (i.e. building on the rootflags=
> > > idea, for the other file systems). Please file an RFE bug about this
> > > on github if that'd would work for you. (or even better, hack it up,
> > > provide a patch).
> >
> > If the admin is going to customize it anyway then maybe /etc/fstab should
> > be that config file? Instead of gpt-generator, why not make udev create a
> > "/dev/disk/by-purpose/efi" symlink and use that as the fstab device...
> > Would that technically work?
>
> That is in fact a great idea. I like. Any chance you can file an RFE
> about this?
>

Submitted: https://github.com/systemd/systemd/issues/18035

-- 
Mantas Mikulėnas
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Udev rules on reboot

2020-12-20 Thread Mantas Mikulėnas
On Sun, Dec 20, 2020 at 3:49 PM Lennart Poettering 
wrote:

> On Sa, 19.12.20 15:37, Adi Ml (maladi1...@gmail.com) wrote:
>
> > I see. so if I have a rule against a certain usb in udev, it should be
> > blocked automatically during the boot.
>
> Hmm, "blocked"? What do you mean by that? I am not following...
>

I suspect they mean something like ATTR{authorized}="0", which tells the
kernel to completely ignore that USB device.

(Though it's more common to set authorized_default=0 on all hubs, then
allow only trusted devices, like USBGuard does.)

-- 
Mantas Mikulėnas
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Mount options for ESP, LUKS and rootfs in automatic partition discovery and mounting

2020-12-19 Thread Mantas Mikulėnas
On Sat, Dec 19, 2020, 14:40 Lennart Poettering 
wrote:

> On Sa, 28.11.20 01:26, Bastien Traverse (neit...@esrevart.net) wrote:
>
> > Hello everyone,
> >
> > Is it possible to specify mount options for ESP, root and LUKS devices
> when
> > using automatic partition discovery and mounting with no fstab?
>
> There's not, currently.
>
> THere's an RFE issue open asking to support rootflags= on the kernel
> cmdline for the automatically discovered rootfs (that's the option the
> kernel uses on traditional rootfs mounting). I think that definitely
> makes sense, it just needs someone to implement things.
>
> I figure in the long run systemd-gpt-auto-generator probably needs
> some minimal config file where you can configure these
> options. Alternatively, maybe initially adding kernel cmdline params
> for each type of mount would suffice (i.e. building on the rootflags=
> idea, for the other file systems). Please file an RFE bug about this
> on github if that'd would work for you. (or even better, hack it up,
> provide a patch).
>

If the admin is going to customize it anyway then maybe /etc/fstab should
be that config file? Instead of gpt-generator, why not make udev create a
"/dev/disk/by-purpose/efi" symlink and use that as the fstab device...
Would that technically work?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [PATCH] man: add instruction on clearing file descriptors

2020-12-07 Thread Mantas Mikulėnas
I'm not sure if it's more portable. I recall FreeBSD only exposing 0–2 in
its /dev/fd by default unless you mounted a separate virtual filesystem
there. NetBSD seems to always have 64 devnodes no matter how many fds.

I don't think there's a *good* portable method (which is why closerange()
is being added) and besides that I'm not sure if that is even in scope for
this systemd-centric manpage...the whole idea is that under systemd, a
daemon shouldn't need that.

On Mon, Dec 7, 2020, 19:30 Petar Kapriš  wrote:

> In the daemon.7 manpage, I added an instruction on closing open file
> descriptors, an important step in daemon startup, showing an option to
> close them using the files in /dev/fd (a more portable alternative
> across systems to using /proc/self/fd)
> ---
>  man/daemon.xml | 11 ++-
>  1 file changed, 6 insertions(+), 5 deletions(-)
>
> diff --git a/man/daemon.xml b/man/daemon.xml
> index db95d2f75b..4bae6ebb82 100644
> --- a/man/daemon.xml
> +++ b/man/daemon.xml
> @@ -47,12 +47,13 @@
>  Close all open file descriptors except
>  standard input, output, and error (i.e. the first three file
>  descriptors 0, 1, 2). This ensures that no accidentally passed
> -file descriptor stays around in the daemon process. On Linux,
> -this is best implemented by iterating through
> -/proc/self/fd, with a fallback of
> -iterating from file descriptor 3 to the value returned by
> +file descriptor stays around in the daemon process.  On most
> +modern systems, this is best implemented by iterating through
> +/dev/fd, or
> +/proc/self/fd on Linux, with a fallback
> +of iterating from file descriptor 3 to the value returned by
>  getrlimit() for
> -RLIMIT_NOFILE. 
> +RLIMIT_NOFILE.  
>
>  Reset all signal handlers to their default.
>  This is best done by iterating through the available signals
> --
> 2.29.2
>
> ___
> 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] Timestamps in journal during suspend/resume

2020-12-01 Thread Mantas Mikulėnas
On Tue, Dec 1, 2020 at 2:31 PM Mantas Mikulėnas  wrote:

> On Tue, Dec 1, 2020 at 1:46 PM Paul Menzel <
> pmenzel+systemd-de...@molgen.mpg.de> wrote:
>
>>
>> At least to me, some of the entries with timestamps from resuming should
>> have timestamps from suspending. Is the reason, that “suspend message“
>> was only written to the journal after resume?
>>
>
> Probably because the journald process (like all other userspace processes)
> had already been frozen when those messages were written to dmesg, so it
> couldn't really receive them.
>
>
>>
>> Is there a way to access the Linux kernel timestamp from within the
>> journal?
>>
>
> Yes, as the _SOURCE_MONOTONIC_TIMESTAMP field. (It's stored in
> microseconds, while dmesg shows it in seconds.)
>
> journalctl -o json _TRANSPORT=kernel | jq -r
> '"[\(._SOURCE_MONOTONIC_TIMESTAMP | tonumber / 100)] \(.MESSAGE)"'
>

(I forgot to include the SYSLOG_IDENTIFIER field in the output, but you get
the idea.)

-- 
Mantas Mikulėnas
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Timestamps in journal during suspend/resume

2020-12-01 Thread Mantas Mikulėnas
On Tue, Dec 1, 2020 at 1:46 PM Paul Menzel <
pmenzel+systemd-de...@molgen.mpg.de> wrote:

>
> At least to me, some of the entries with timestamps from resuming should
> have timestamps from suspending. Is the reason, that “suspend message“
> was only written to the journal after resume?
>

Probably because the journald process (like all other userspace processes)
had already been frozen when those messages were written to dmesg, so it
couldn't really receive them.


>
> Is there a way to access the Linux kernel timestamp from within the
> journal?
>

Yes, as the _SOURCE_MONOTONIC_TIMESTAMP field. (It's stored in
microseconds, while dmesg shows it in seconds.)

journalctl -o json _TRANSPORT=kernel | jq -r
'"[\(._SOURCE_MONOTONIC_TIMESTAMP | tonumber / 100)] \(.MESSAGE)"'

Note that the kernel uses the monotonic clock for dmesg messages, which
does not advance at all while the system is suspended -- so trying to
convert it to realtime will often give wrong results (the same problem as
in 'dmesg -e') unless you do something smart with combining it with
journald's __REALTIME_TIMESTAMP.

-- 
Mantas Mikulėnas
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Order between systemd-networkd and udev

2020-11-30 Thread Mantas Mikulėnas
On Mon, Nov 30, 2020, 23:25 Zheng, Fam  wrote:

> Hi,
>
> Currently in systemd-networkd.service we have
>
> After=... systemd-udevd.service ...
>
> I know the point of it has been for tuntap as pointed out by comments
> above, but I do wonder what ensures the ordering of NIC drivers (as
> loaded by udevd) against networkd?
>

Networkd shouldn't ever *need* such synchronization – each interface gets
configured whenever it appears, whether it's earlier or later. Basically
all interfaces are hotplug interfaces.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Mounting / as writable without in `/etc/fstab`

2020-11-26 Thread Mantas Mikulėnas
On Mon, Nov 23, 2020 at 5:23 PM Paul Menzel <
pmenzel+systemd-de...@molgen.mpg.de> wrote:

> Dear systemd folks,
>
>
> Is an entry for / in `/etc/fstab` still needed, or is there a systemd
> way of doing it?
>

That *is* the systemd way -- the fstab entry will be read by
systemd-remount-fs(8) and the new mount options applied.


>
> Installing Debian bullseye/testing with the Debian Installer, it creates
> a GPT and `/etc/fstab`. [...]
> Commenting out the entries for `/`, the root partition is mounted as
> read-only.
>
>  $ findmnt /
>  TARGET SOURCE FSTYPE OPTIONS
>  /  /dev/nvme0n1p2 ext4   ro,relatime
>
> Shouldn’t it be mounted as writable?
>

No, if you had it initially mounted with 'ro' and did not leave any
instructions for remounting, then it won't be remounted...


>
>  $ sudo /lib/systemd/systemd-remount-fs
>  $ findmnt /
>  TARGET SOURCE FSTYPE OPTIONS
>  /  /dev/nvme0n1p2 ext4   rw,relatime,errors=remount-ro
>
> The log says:
>
>  [2.320133] systemd[179]:
> /usr/lib/systemd/system-generators/systemd-gpt-auto-generator succeeded.
>
> I can work around it changing `ro` to `rw` on the Linux command line,
> but I thought, it is possible without that.
>

I would say that having the initramfs directly mount the filesystem as rw
is the *preferred method*, not a workaround... Of course it depends on how
your distro's initramfs wants to work, but at least that's what Arch does
-- since fsck is run from the initramfs, there's not much point in later
mounting it ro at all.

-- 
Mantas Mikulėnas
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] How to turn off the ntp time synchronization in default when power on

2020-11-24 Thread Mantas Mikulėnas
On Tue, Nov 24, 2020, 21:43 An Liu  wrote:

> HI
>
> timedatectl set-ntp false
>
>
> what is the diff between this and
> systemctl disable ntp
>

The timedatectl command controls only systemd's own NTP client
(systemd-timesyncd.service). It doesn't care about other NTP clients such
as ntp.service or chrony.service.

Other than that, there is not much difference – they both just
enable/disable services.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] state of journal-upload and journal-remote?

2020-11-22 Thread Mantas Mikulėnas
On Sun, Nov 22, 2020 at 12:42 PM Florian Klink  wrote:

> Hey,
>
> I'm wondering about the current state of journal-upload and journal-remote.
>
> Traffic on this list about it has gotten pretty silent, there has been
> bug reports opened in 2018 about this being somewhat broken:
>
> https://github.com/systemd/systemd/issues/9858
> (and search for other issues).
>
> All in all this seems somewhat buggy, underdocumented, and given most
> people do log forwarding these days by running some other daemons,
> specific to their environment, which query the journal for logs and
> forward them on their own, without using any of the
> journal-upload/journal-remote stuff…
>

I'm less sure about the HTTP bits, but I think journal-remote can be useful
on its own, as it also takes input from stdin (doing the opposite of
`journalctl -o export`)...

-- 
Mantas Mikulėnas
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] systemd.automount issue: Failed to initialize automounter: Operation not permitted

2020-11-16 Thread Mantas Mikulėnas
Automounts themselves are established by a magic kernel-level mount
(specifically they're "autofs" mounts), which requires root privileges.

Your systemd --user instance runs unprivileged, as your own UID, and
doesn't have the privilege to mount autofs (or anything else that isn't
FUSE).

On Tue, Nov 17, 2020, 00:01 Wolter HV  wrote:

>
>
> Hello,
>
> I'm trying to mount an sshfs share using systemd only, on a user level.
> Unfortunately, I get the following error message on journalctl:
>
> Failed to initialize automounter: Operation not permitted
>
> I get that error message on journalctl after I try to start my automount
> via the command
>
> systemctl --user start home-anonymous-mountpoint.automount
>
> Please find the full log and unit files below.
>
> However, if I run instead
>
> systemctl --user start home-anonymous-mountpoint.mount
>
> then the mount works fine.
>
> This is the detailed log:
>
> --- LOG ---
> [REDACTED] systemd: home-anonymous-mountpoint.automount: Failed to
> initialize automounter: Operation not permitted
> [REDACTED] systemd: home-anonymous-mountpoint.automount: Failed with
> result 'resources'.
>Subject: Unit failed
>Defined-By: systemd
>Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
>
>The unit UNIT has entered the 'failed' state with result 'resources'.
> [REDACTED] systemd: Failed to set up automount remotelocation at
> remotehost.
>Subject: A start job for unit UNIT has failed
>Defined-By: systemd
>Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
>
>A start job for unit UNIT has finished with a failure.
>
>The job identifier is 272 and the job result is failed.
> --- EOF ---
>
> These are my unit files:
>
> --- ~/.config/systemd/user/home-anonymous-mountpoint.automount ---
> [Unit]
> Description=remotelocation at remotehost
>
> [Automount]
> Where=/home/anonymous/mountpoint
> TimeoutIdleSec=600
>
> [Install]
> WantedBy=default.target
> --- EOF ---
>
> --- ~/.config/systemd/user/home-anonymous-mountpoint.mount ---
> [Mount]
> What=remoteuser@remotehost:/srv/sshfs/remotelocation
> Type=fuse.sshfs
> Options=IdentityFile=/home/anonymous/.ssh/keys/remotehost-remoteuser.id_rsa
> TimeoutSec=10
> --- EOF ---
>
> (Crossing my fingers so this message doesn't get garbled or force-wrapped.)
>
> Regards,
>
> Wolter HV
>
>
> ___
> 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] Journald retaining logs for only 10 days

2020-11-14 Thread Mantas Mikulėnas
On Sat, Nov 14, 2020, 20:17 Mantas Mikulėnas  wrote:

> On Sat, Nov 14, 2020 at 11:31 AM Nikolaus Rath  wrote:
>
>> Hello,
>>
>> I just discovered that on one of my systems journald only retains log
>> entries for about 10 days:
>>
>> # journalctl | head -1
>> -- Logs begin at Wed 2020-11-04 15:57:13 UTC, end at Sat 2020-11-14
>> 09:28:19 UTC. --
>>
>> I do not understand what could cause this, because I have no retention
>> limit configured, and the logs take up way less space than I have
>> reserved:
>>
>> # journalctl --disk-usage
>> Archived and active journals take up 320.0M in the file system.
>>
>> # journalctl > alllogs
>> # ls -lh alllogs
>> -rw-r--r-- 1 root root 27M Nov 14 09:24 alllogs
>>
>
> That just shows the 'MESSAGE' field -- it does not show any other fields
> that each entry will have stored, such as the unit name which generated the
> message; the program's command line; and apparently even the original
> unparsed packet that was received through /dev/log. Try `journalctl -o
> export` to get a closer idea of what the messages in systemd-journal look
> like.
>
> For example, on one of my servers, a plain `journalctl -a` outputs 260 MB
> of data, but `journalctl -o export` is 1.9 GB. (Which is still not quite
> the same as 2.4 GB of *.journal files, but there's always going to be some
> discrepancy due to how a binary database allocates space.)
>

One specific reason is that journal files are indexed – you can search them
by any field value, without needing to do a full linear grep. (This is how
"systemctl status" shows just one unit's logs, for example.) The indexes
are stored along with the data, so the .journal files will be larger than
the corresponding "-o export" dump.

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


Re: [systemd-devel] Journald retaining logs for only 10 days

2020-11-14 Thread Mantas Mikulėnas
On Sat, Nov 14, 2020 at 11:31 AM Nikolaus Rath  wrote:

> Hello,
>
> I just discovered that on one of my systems journald only retains log
> entries for about 10 days:
>
> # journalctl | head -1
> -- Logs begin at Wed 2020-11-04 15:57:13 UTC, end at Sat 2020-11-14
> 09:28:19 UTC. --
>
> I do not understand what could cause this, because I have no retention
> limit configured, and the logs take up way less space than I have
> reserved:
>
> # journalctl --disk-usage
> Archived and active journals take up 320.0M in the file system.
>
> # journalctl > alllogs
> # ls -lh alllogs
> -rw-r--r-- 1 root root 27M Nov 14 09:24 alllogs
>

That just shows the 'MESSAGE' field -- it does not show any other fields
that each entry will have stored, such as the unit name which generated the
message; the program's command line; and apparently even the original
unparsed packet that was received through /dev/log. Try `journalctl -o
export` to get a closer idea of what the messages in systemd-journal look
like.

For example, on one of my servers, a plain `journalctl -a` outputs 260 MB
of data, but `journalctl -o export` is 1.9 GB. (Which is still not quite
the same as 2.4 GB of *.journal files, but there's always going to be some
discrepancy due to how a binary database allocates space.)

-- 
Mantas Mikulėnas
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] How to dynamically retrieve my service name?

2020-11-10 Thread Mantas Mikulėnas
You can call org.freedesktop.systemd1.Manager.GetUnitByPID() to directly
get the D-Bus object path based on your PID.

There is also the magic path "/org/freedesktop/systemd1/unit/self" which
always gives properties of the same service (or scope) that you're in.

Finally, it is possible to call sd_pid_get_unit() from sd-login.h to get
your unit name (straight from /proc//cgroup, with no D-Bus yet), then
call .Manager.GetUnit() to translate the name into an object path.



On Tue, Nov 10, 2020 at 6:28 PM Etienne Doms  wrote:

> Hello,
>
> My service needs to behave a bit differently when it has been
> automatically because of a software fault. I use the
> "Restart=on-failure", and I understand that I can read the "NRestarts"
> property which is incremented whenever the service is restarted.
>
> The thing is, inside my service, I have no idea if I'm foobar.service,
> barfoo.service, etc. and I believe I should be agnostic of that.
>
> Is there a way to dynamically retrieve
> /org/freedesktop/systemd1/unit/foobar_2eservice, so that I can ask
> org.freedesktop.systemd1 the NRestarts property value of the
> org.freedesktop.systemd1.Service interface?
>
> Maybe I'm just over-engineering and should just hardcode
> "foobar.service" inside my service, but it feels a bit odd to me...
> Maybe also I understand nothing about D-Bus, sorry about that.
>
> Thank you for your support.
>
> Best regards,
> Etienne Doms
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
>


-- 
Mantas Mikulėnas
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] ssh.service in rescue.target

2020-11-06 Thread Mantas Mikulėnas
On Fri, Nov 6, 2020, 23:31 Phillip Susi  wrote:

>
> Lennart Poettering writes:
>
> > Are you running systemd? If so, please get rid of "killproc". It will
> > interfere with systemd's service management.
>
> I see.. apparently Ubuntu still has it around.  How does systemd handle
> it?  For instance, if a user logged in and forked off a background
> process, how does systemd make sure it gets killed when isolating to
> rescue.target?  Does it decide that it is still connected to ssh.service
> and so won't kill it when isolating?  I'd like to make sure anything
> like that is killed and maybe restart sshd if needed.
>

No, user processes are moved to their own cgroup and unit (usually
session-XX.scope nested under user-UID.slice) as soon as sshd calls
pam_systemd during login.

(This includes also the sshd "worker" process which handles that
connection, which is the one calling PAM.)

You can see the "contents" of sshd.service in its `systemctl status`, and
you can run `systemd-cgls` to get a tree of all cgroups and which processes
they contain.

I don't exactly know in which conditions the session scopes (or the whole
user slice) are stopped. But in any case, stopping a unit should kill all
processes with no "leftovers".
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] ssh.service in rescue.target

2020-11-06 Thread Mantas Mikulėnas
On Fri, Nov 6, 2020, 18:38 Phillip Susi  wrote:

>
> Lennart Poettering writes:
>
> > What is "killprocs"?
> >
> > Is something killing services behind systemd's back? What's that
> > about?
>
> It's the thing that kills all remaining processes right before shutdown
> that we've had since the sysvinit?


But it was only needed *for* sysvinit. Systemd can already kill processes
by itself.

(The final cleanup before poweroff is done by systemd-shutdown; however,
isolating does not reach this final stage – isolate only stops some units
and starts other units.)

I'm not sure if you're saying that the distro has re-added some redundant
sysvinit stuff to the shutdown process?


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


Re: [systemd-devel] DisplayPort display non-persistent device naming

2020-10-29 Thread Mantas Mikulėnas
It could be either, but these names are assigned by the kernel – not by
udev.

On Thu, Oct 29, 2020, 22:53 Marcin Kocur  wrote:

> Hello,
>
> this is the output of turning off and on my display (using power button):
>
>
> [mk@linux ~]$ udevadm  monitor
> monitor will print the received events for:
> UDEV - the event which udev sends out after rule processing
> KERNEL - the kernel uevent
>
> KERNEL[79.909185] change
> /devices/pci:00/:00:08.1/:08:00.0/drm/card0 (drm)
> KERNEL[79.909318] remove
> /devices/pci:00/:00:08.1/:08:00.0/i2c-3/i2c-dev/i2c-3 (i2c-dev)
> KERNEL[79.909385] remove
> /devices/pci:00/:00:08.1/:08:00.0/i2c-3 (i2c)
> KERNEL[79.909564] remove
> /devices/pci:00/:00:08.1/:08:00.0/drm/card0/card0-DP-2/drm_dp_aux1
>
> (drm_dp_aux_dev)
> KERNEL[79.909599] remove
> /devices/pci:00/:00:08.1/:08:00.0/drm/card0/card0-DP-2 (drm)
> KERNEL[79.909733] remove
> /devices/pci:00/:00:08.1/:08:00.0/drm/card0/card0-DP-3/drm_dp_aux2
>
> (drm_dp_aux_dev)
> KERNEL[79.909756] remove
> /devices/pci:00/:00:08.1/:08:00.0/drm/card0/card0-DP-3 (drm)
> KERNEL[79.909882] change
> /devices/pci:00/:00:08.1/:08:00.0/drm/card0 (drm)
> UDEV  [79.912218] remove
> /devices/pci:00/:00:08.1/:08:00.0/i2c-3/i2c-dev/i2c-3 (i2c-dev)
> UDEV  [79.912301] change
> /devices/pci:00/:00:08.1/:08:00.0/drm/card0 (drm)
> UDEV  [79.912708] remove
> /devices/pci:00/:00:08.1/:08:00.0/i2c-3 (i2c)
> UDEV  [79.913400] remove
> /devices/pci:00/:00:08.1/:08:00.0/drm/card0/card0-DP-2/drm_dp_aux1
>
> (drm_dp_aux_dev)
> UDEV  [79.913832] remove
> /devices/pci:00/:00:08.1/:08:00.0/drm/card0/card0-DP-3/drm_dp_aux2
>
> (drm_dp_aux_dev)
> UDEV  [79.913875] remove
> /devices/pci:00/:00:08.1/:08:00.0/drm/card0/card0-DP-2 (drm)
> UDEV  [79.914230] remove
> /devices/pci:00/:00:08.1/:08:00.0/drm/card0/card0-DP-3 (drm)
> UDEV  [79.914814] change
> /devices/pci:00/:00:08.1/:08:00.0/drm/card0 (drm)
> KERNEL[85.337964] add
> /devices/pci:00/:00:08.1/:08:00.0/i2c-3/i2c-dev/i2c-3 (i2c-dev)
> KERNEL[85.337996] add
> /devices/pci:00/:00:08.1/:08:00.0/i2c-3 (i2c)
> UDEV  [85.340976] add
> /devices/pci:00/:00:08.1/:08:00.0/i2c-3/i2c-dev/i2c-3 (i2c-dev)
> UDEV  [85.342384] add
> /devices/pci:00/:00:08.1/:08:00.0/i2c-3 (i2c)
> KERNEL[85.482056] add
> /devices/pci:00/:00:08.1/:08:00.0/drm/card0/card0-DP-3 (drm)
> KERNEL[85.482116] add
> /devices/pci:00/:00:08.1/:08:00.0/drm/card0/card0-DP-3/drm_dp_aux1
>
> (drm_dp_aux_dev)
> KERNEL[85.482215] change
> /devices/pci:00/:00:08.1/:08:00.0/drm/card0 (drm)
> KERNEL[85.482231] add
> /devices/pci:00/:00:08.1/:08:00.0/drm/card0/card0-DP-4 (drm)
> KERNEL[85.482308] add
> /devices/pci:00/:00:08.1/:08:00.0/drm/card0/card0-DP-4/drm_dp_aux2
>
> (drm_dp_aux_dev)
> KERNEL[85.482386] change
> /devices/pci:00/:00:08.1/:08:00.0/drm/card0 (drm)
> KERNEL[85.482415] change
> /devices/pci:00/:00:08.1/:08:00.0/drm/card0 (drm)
> UDEV  [85.483698] add
> /devices/pci:00/:00:08.1/:08:00.0/drm/card0/card0-DP-3 (drm)
> UDEV  [85.485053] add
> /devices/pci:00/:00:08.1/:08:00.0/drm/card0/card0-DP-3/drm_dp_aux1
>
> (drm_dp_aux_dev)
> UDEV  [85.486553] change
> /devices/pci:00/:00:08.1/:08:00.0/drm/card0 (drm)
> UDEV  [85.487973] add
> /devices/pci:00/:00:08.1/:08:00.0/drm/card0/card0-DP-4 (drm)
> UDEV  [85.489186] add
> /devices/pci:00/:00:08.1/:08:00.0/drm/card0/card0-DP-4/drm_dp_aux2
>
> (drm_dp_aux_dev)
> UDEV  [85.490094] change
> /devices/pci:00/:00:08.1/:08:00.0/drm/card0 (drm)
> UDEV  [85.491090] change
> /devices/pci:00/:00:08.1/:08:00.0/drm/card0 (drm)
>
>
> The monitor was visible in xrandr as DP-2, after power off and on it's
> visible as DP-3 (DP-2 is still there "disconnected").
>
> It's troublesome for:
>
> - GUI display configurators
>
> - scripting
>
> - for Xorg configuration which stops to work:
>
> Section "Monitor"
>  Identifier  "DP-2"
>  Option  "Primary" "true"
> EndSection
>
> Is this a bug or a feature?
>
> --
> Pozdrawiam / Greetings
> Marcin Kocur █
>
> ___
> 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] systemctl reboot/halt with non-privilege user

2020-10-28 Thread Mantas Mikulėnas
On Wed, Oct 28, 2020, 13:40 An Liu  wrote:

> Hi, folks,
>
> I used to type systemctl reboot with non-privileged users, and to my
> surprise, the system goes down for the reboot.
>
> I've tested in both debian and centos 7, they act the same, however,
> systemctl halt will prompt you to enter administrator password to continue.
>
> Is it default behavior by design?
>

Yes, but... Depends on whether the user is doing it locally or remotely,
and whether they're the only person who's logged in or whether there are
other users as well. There are different rules in systemd for these cases.

I'm not entirely sure why reboot is treated differently from halt, though.
>From my experience, *neither* is allowed over remote (SSH) sessions by
default.

I dont think a non-privileged user could reboot the system as he/she
> wishes.
>

It hasn't been true for a long time that a user is either fully privileged
or not privileged at all, and nothing in between.

For example, in the case of systemctl, locally logged in users are allowed
to call `systemctl poweroff` because they could just as well pull the plug.
But the exact same user, logged in via SSH, will not be allowed it.

In most everyday installations (talking about other operating systems),
rebooting the local system is a default privilege that even "unprivileged"
users have...

And I do think that defaults should be suitable for the majority, leaving
the burden of customization to unusual sites (kiosks, clusters) – not the
other way around.


> btw, I'm in an HPC related domain, if this behavior of systemctl is
> allowed, every single user could reboot the whole cluster as they wish,
> it's a disaster.
>

Then don't allow it. Change your polkit (PolicyKit) rules to block all
reboot-related actions.

(Check the journal to see which specific action was authorized, though –
the same reboot command can use a few different action IDs to apply
different rules.)

If CentOS uses JS-based rules, here are some examples:
https://gist.github.com/grawity/3886114

Debian's polkit uses the older .pkla format, which is simpler but I don't
have a good example on hand.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Crond session, pam_access and pam_systemd

2020-10-16 Thread Mantas Mikulėnas
On Fri, Oct 16, 2020 at 4:13 PM Thomas HUMMEL 
wrote:

>
> On 16/10/2020 13:22, Mantas Mikulėnas wrote:
>
> > But I think you're still confusing the two different kinds of "sessions"
> > that exist here. PAM open_session creates a PAM session, which
> > eventually *causes* a systemd-logind session to be created, but isn't
> > 100% the same thing.
>
> Yes I probably did.
> My undestanding is that a pam session is anything pam modules do between
> pam_open_session() and pam_close_session(), which could be things like
> write to /var/run/utmp for instance and a systemd-logind session is just
> a scope holding all a user processes between his login and logout
>

Yes, that's right.


>
> [By the way I don't know how a child process can wait for its parent -
> waiting for its parent to send a signal ?]
>

I haven't actually checked, but I'm guessing it uses
prctl(PR_SET_PDEATHSIG). The kernel can automatically send a signal when
this is enabled.

> No, it's actually started by the systemd system manager itself, because
> > user@.service has PAMName= set. It only *appears* to be a child of
> > systemd --user, because it is a child of the process which first forked
> > sd-pam, then exec'd systemd --user.
>
> So basically user@.service is a service using PAMName=systemd-user
> with an sd-pam pam session handler and which main process (similar to an
> ExecStart in a standard service unit) is systemd --user correct ?
>

Yes.


>
> Why has it got to work the other way around compared to as service
> wainting for its child to finish to call pam_close_session() as you said ?
>

If I remember correctly, it's so that the main process would still be able
to have pid 1 as its parent, without introducing an intermediate step in
the process tree.

(pid 1 itself cannot call PAM directly because PAM modules can block and
they often modify process-wide state, so it has to fork at least once
before handling PAM. So if that first child just forked ExecStart as a
2nd-level child process, this would mean a weird difference in behavior
between services which use PAMName= and those which don't.)


>
> > Most tools (sudo, sshd, crond) handle all PAM calls in the parent
> > process, just forking your shell or cronjob as a child, then waiting for
> > the child to exit before they can call pam_close_session(). Systemd does
> > it the other way around – it also forks, but the *child* waits for the
> > parent to exit before calling pam_close_session(), whereas the parent
> > directly execs the ExecStart command.
>
> So the second sd-pam you mentionned in your tree above is this handler
> mentionnend in the doc I mentionned and waiting for systemd --user to
> finish to take proper action when closing the pam session ?
>

Yes. (Actually in my diagram, I probably shouldn't have labelled the
*first* process "sd-pam" -- I think it actually labels itself
"sd-executor", as it handles all other environment preparation as well.)



> Regarding the following part :
>
>  > systemd-logind
>  > └ receives CreateSession(uid=1000)
>  >├ DBus call to systemd: Start(user@1000.service)
>  >└ DBus call to systemd: StartTransientUnit(session-1234.scope)
>
> Since you said systemd-logind does not need systemd --user to creates
> the session I guess the second job (start transient unit) can be done
> without it. So can I conclude that this is just the way systemd-logind
> is designed : when instructed to create a session, it also start the
> user@.service just for the user to be able to use its own systemd
> instance (which in my case of user crontab is not used) ?
>

Yes.

-- 
Mantas Mikulėnas
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Crond session, pam_access and pam_systemd

2020-10-16 Thread Mantas Mikulėnas
On Fri, Oct 16, 2020 at 1:41 PM Thomas HUMMEL 
wrote:

> Hello,
>
> if I try to sum up all of your answers, I come to the following
> understanding :
>
> - sessions are always created via the pam_systemd module
> - which is, in my case called (sshd, crond) via the password-auth stack
> include
> - so crond, through pam_systemd will cause a session to be created
>

If you specifically mean systemd-logind sessions, yes.

But I think you're still confusing the two different kinds of "sessions"
that exist here. PAM open_session creates a PAM session, which eventually
*causes* a systemd-logind session to be created, but isn't 100% the same
thing.


> - such session is created via the sd-pam helper responsible for
> pam_open_session() and pam_close_session() calls
>

Not exactly. For cron and sshd, all those PAM functions are called directly
by cron or sshd themselves.

The sd-pam helper only does this task when systemd pid1 (the service
manager) needs to call PAM for a service that has PAMName= set in its unit.

As far as I could figure out, the entire process works like this:

sshd (listener)
└ sshd (connection worker)
  ├ pam_start(sshd, ...)
  ├ pam_acct_mgmt()
  │ └ pam_access.so
  ├ pam_open_session()
  │ └ pam_systemd.so
  │   └ DBus call to systemd-logind: CreateSession(service=sshd, uid=1000)
  ├ fork login shell
  │ └ /bin/bash
  └ pam_close_session()

systemd-logind
└ receives CreateSession(uid=1000)
  ├ DBus call to systemd: Start(user@1000.service)
  └ DBus call to systemd: StartTransientUnit(session-1234.scope)

systemd (pid1)
└ user@1000.service
  └ sd-pam
├ pam_start(systemd-user, ...)
├ pam_acct_mgmt()
│ └ pam_access.so
├ pam_open_session()
├ fork sd-pam child
│ └ sd-pam (waits for parent to exit)
│   └ pam_close_session()
└ exec systemd --user



> - such a worker is started by a systemd --user instance
>

No, it's actually started by the systemd system manager itself, because
user@.service has PAMName= set. It only *appears* to be a child of systemd
--user, because it is a child of the process which first forked sd-pam,
then exec'd systemd --user.

Most tools (sudo, sshd, crond) handle all PAM calls in the parent process,
just forking your shell or cronjob as a child, then waiting for the child
to exit before they can call pam_close_session(). Systemd does it the other
way around – it also forks, but the *child* waits for the parent to exit
before calling pam_close_session(), whereas the parent directly execs the
ExecStart command.

So if you had a basic unit with "ExecStart=/bin/sleep 1h", if it also had
User= and PAMName=, then you would see 'sd-pam' as a child of 'sleep 1h'.


> - so a user crontab will ultimately cause the use of the already running
> systemd --user instance of the user (because his logged in or is
> lingered) OR the creation of a systemd --user instance for the purpose
> of the crond session creation
>

Yes, more or less.


>
> What I still don't quite get is :
>
> - is it sd-pam or systemd --user or user@.service holding them
> which uses the systemd-user pam service name ?
>

user@.service is where the name is configured, but sd-pam is the
process which actually calls PAM for that service name.

systemd --user on its own doesn't talk to PAM at all. (See what I wrote
above about the sd-pam worker.)


>
> - my understanding was that pam service name is passed to pam_start() :
> in the user crontab case, my guess is that crond does this call with the
> crond service name (so pam knows what module stacks to run).
> So this would mean something like the user@.service (or sd-pam)
> would itself call pam_start(systemd-user, ...) when called by pam_systemd ?
>

Yes.


>
> So basically pam_systemd module would trigger another service which
> itself would go through pam with the systemd-user service name ?
>

Yes.


>
> - again, why is a first ssh login session able to create the user
> session without the user having to be listed for systemd-user in
> access.conf whereas crond semmes to need it (givent no systemd --user
> was previously running in both cases) ?
>

I don't know why you're seeing the different behavior between crond and
sshd.

However, a systemd-logind session doesn't actually *need* user@.service
(systemd --user), it can be created without. So even if user@.service
could not be started due to PAM not authorizing it (or due to some other
reason), this will still not prevent pam_systemd from registering the
session and creating user-.slice and making it appear in `loginctl`.

-- 
Mantas Mikulėnas
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Crond session, pam_access and pam_systemd

2020-10-12 Thread Mantas Mikulėnas
On Mon, Oct 12, 2020 at 8:16 PM Thomas HUMMEL 
wrote:

> Thanks for your answer. Still I'm quite confused.
>
> On 12/10/2020 18:21, Mantas Mikulėnas wrote:
>
>
> > It's a worker process which calls pam_open_session() and
> > pam_close_session() on behalf of the user@.service unit.
>
> Well I may be misunderstanding but this user@.service seems like a
> top level (for this user) placeholder for various other services units
> and/or scope, among which the init.scope corresponding to the sd-pam and
> systemd --user processes).
>

Yes, but it is *not* a top level for *all* of the user's processes – just
for those that are managed through systemctl --user.


>
> So you mean that any service in this placeholder can and do use the
> sd-pam helper to call pam_open_session() and pam_close_session instead
> of doing it themselves, passing it the relevant PAMName ?
>

No, I'm talking about system (global) services.

user@.service, itself, is a system service.


>
>
> > So when you see sd-pam under user@.service, that means it's
> > handling the "systemd-user" PAM service.
>
> I'm not sure I understood in which cases this PAM service name is used
>

It's used in only one case: when starting the "user@.service" unit.


>
>
> > They're different but related. Systemd user sessions are always managed
> > through PAM (the pam_systemd module), so whenever cron calls
> > pam_open_session() it indirectly starts a systemd session as well.
>
> You mean crond running as the user who has his own crontab does call
> pam_open_session() which is defined in the pam_systemd module ?
> If this is correct, this has indeed nothing to do with the sd-pam
> pam_open_seesion() mentionned above or does it ?
>
>
Yes, they're completely separate PAM instances.


>
> >
> > - what does the first error message refers to and why does the
> > systemd-user pam service name get passed ? and by which systemd
> (system
> > or user) ?
> >
> >
> > Your systemd --user instance is run as a service
>
> Yes I understood that. But again I'm not really sure what services or
> other units it is supposed to run if I didn't defined user custom
>

Well, that doesn't mean it shouldn't be started at all – for a few reasons:

1) pam_systemd doesn't know that you don't have any custom units.
2) Even if you don't have any units in ~/.config/systemd, there might be
package-installed ones in /usr/lib/systemd/user (such as gpg-agent.socket).
3) systemd --user can also be used for transient units via `systemd-run`.

Though, it's true that most of those things are about interactive logins.
Actually I kind of wish that pam_systemd would have an option to *only*
create the user-.slice cgroup but without starting user@.service...
(Arch Linux's /etc/pam.d/crond does not list pam_systemd at all, and it
hasn't really created any issues so far.)


> services. Is it responsible to run things like the user's UI termnials
> for instance ?
>

Generally no. Even though your login processes belong to a "user session",
they are not managed by user@.service in any way.


>
>
> > Because of that, the service needs to have its own PAM service name and
> > makes its own PAM calls independently from crond or anything else.
>
> Ok so it's this service (systemd --user) which uses the systemd-user PAM
> service name ? Passed to the generic sd-pam worker ? Correct ?
>

Yes.


>
> >
> > - what is the failing systemd job the second message refers to ? Does
> > this mean that the crond "session" gets created by the systemd --user
> > instance (as some gnome apps in other contexts for instance) ?
> >
> >
> > No, it's mostly the opposite – the starting of user@.service is
> > triggered by crond opening its PAM session.
>
> Sorry I don't get it : what service exactly is started ? crond opening
> its PAM session does not cause a systemd --user to be instanciated or
>

It does *if* your distro's /etc/pam.d/cron[d] includes the pam_systemd
module. (So on Debian it does, on Arch it doesn't.)


> does it ? I thought the only way to have a systemd --user was through
> the creation via pam_systemd notifying systemd-logind at a user fist
> login (and/or to linger the user)
>

Yes but that's exactly what happens in cron as well. When crond calls PAM,
it does exactly the same thing as when a user logs in interactively – it
calls PAM open_session in pretty much the same way as e.g. sshd or console
login would. The only difference is the PAM service name (and therefore a
different /etc/pam.d config file).

-- 
Mantas Mikulėnas
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Crond session, pam_access and pam_systemd

2020-10-12 Thread Mantas Mikulėnas
On Mon, Oct 12, 2020 at 5:26 PM Thomas HUMMEL 
wrote:

> Hello,
>
> Using systemd-239 on CentOS 8.2 I'm trying to figure out what exactly
> happens when a cron "session" is created. In particular, what
> corresponds to the following error messages I get while running a user
> crontab :
>
> 2020-10-12T14:27:01.031334+02:00 maestro-orbit systemd:
> pam_access(systemd-user:account): access denied for user `toto' from
> `systemd-user'
>
> 2020-10-12T14:27:01.036959+02:00 maestro-orbit crond[135956]:
> pam_systemd(crond:session): Failed to create session: Start job for unit
> user@1000.service failed with 'failed'
>
> - What I'm doing :
>
> ssh to the host, sudo -u toto, crontab -e, exit
>
> so when toto's crontab gets executed toto has no running sessions
>
> - access.conf, for cron, has the line
>
> +:ALL:cron crond
>
> - If, I add
>
> +:toto:systemd-user
>
> the error messages do not occur anymore.
>
> My understanding is that for an standard logged-in user, pam_systemd
> registers the user sessions to systemd-logind and each logged-in user
> has a user slice holding all his session's scopes plus an init scope
> holding a user@.service which in turns holds at least a user
> instance of systemd (systemd --user) and "sd-pam".
>
> So my questions are:
>
> - what is sd-pam ?
>

It's a worker process which calls pam_open_session() and
pam_close_session() on behalf of the user@.service unit. (This feature
is generic and accessible to all .service units via PAMName=; however, the
PAM calls often set up various process-wide state, so they cannot be done
in pid1 itself – and they usually require privileges, so they cannot be
done in the systemd --user instance either.)

So when you see sd-pam under user@.service, that means it's handling
the "systemd-user" PAM service.


> - is a crond session different from a user session ?
>

They're different but related. Systemd user sessions are always managed
through PAM (the pam_systemd module), so whenever cron calls
pam_open_session() it indirectly starts a systemd session as well.

However, PAM itself only has a very abstract concept of "sessions"
and doesn't really care about systemd's definition of user sessions at all
– it just tells each module to do whatever it needs to do.


> - what pam service name does crond use ?
>

Either "cron" or "crond", depending on which cron implementation your
distro uses. Check which pam.d config file was already included by your
distro.


> - what does the first error message refers to and why does the
> systemd-user pam service name get passed ? and by which systemd (system
> or user) ?
>

Your systemd --user instance is run as a service – it is not a child of
crond, and is not directly associated with any session (neither systemd nor
PAM), but meant to be shared across all of them. It's shared between cron,
local logins, ssh logins, and all other services which are configured with
pam_systemd. So it can't really inherit cron-specific settings, for example.

Because of that, the service needs to have its own PAM service name and
makes its own PAM calls independently from crond or anything else.


> - what is the failing systemd job the second message refers to ? Does
> this mean that the crond "session" gets created by the systemd --user
> instance (as some gnome apps in other contexts for instance) ?
>

No, it's mostly the opposite – the starting of user@.service is
triggered by crond opening its PAM session.

But otherwise it's completely independent: it has its own PAM session, it
is not a child of crond, it is not a parent of crond either, and it does
not manage crond's processes – just sits there in background.


> - does the line I added to access.conf makes sense at all ?
>

Yes – if you want the user to have access to systemd --user, then your PAM
configuration must authorize the "systemd-user" service.

I would probably recommend always listing all three (cron, crond,
systemd-user) because essentially they provide very similar functions,
especially with linger active.

I also noticed that if the user gets lingered there is no such error
> message (which makes me think about the creation of the crond session
> through the systemd --user instance running a job)
>

Linger means the --user instance starts on boot (without waiting for a
systemd "user session" to trigger it) and runs forever. So most likely the
message also shows up only once at boot time.


-- 
Mantas Mikulėnas
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Q on serial-getty

2020-10-07 Thread Mantas Mikulėnas
On Wed, Oct 7, 2020 at 9:49 AM Ulrich Windl <
ulrich.wi...@rz.uni-regensburg.de> wrote:

> Hi!
>
> I'm thinking of configuring a serial getty in SLES15 (systemd-234). First
> I found that there is no manual page describing the service, and second if
> I use "systemctl show serial-getty" ("systemctl show serial-getty@" does
> not work), I get some "funny" numbers:
>
> ...
> UID=4294967295
> GID=4294967295
> ...
> MemoryCurrent=18446744073709551615
> CPUUsageNSec=18446744073709551615
> TasksCurrent=18446744073709551615
> IPIngressBytes=18446744073709551615
> IPIngressPackets=18446744073709551615
> IPEgressBytes=18446744073709551615
> IPEgressPackets=18446744073709551615
> ...
> CPUWeight=18446744073709551615
> StartupCPUWeight=18446744073709551615
> CPUShares=18446744073709551615
> StartupCPUShares=18446744073709551615
> ...
>
> Obviously that number is the unsigned 64-bit representation of -1, but
> considering that no such service is running, the output looks quite odd.
> If -1 means "unknown", why not use that string, or if it means
> "unlimited", why not use that string?
>

This was fixed in systemd-235 several years ago.
https://github.com/systemd/systemd/commit/21771f338d268e06dc9a10b9b08b14ff8217d4be

-- 
Mantas Mikulėnas
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Q: logrotate and "systemctl kill -s HUP ..."

2020-09-30 Thread Mantas Mikulėnas
On Wed, Sep 30, 2020 at 11:24 AM Ulrich Windl <
ulrich.wi...@rz.uni-regensburg.de> wrote:

> Hi!
>
> I have a problem with logrotate: My postrotate command does not seem to
> send a HUP signal. However the files are rotated.
> I'm using this (not preferred way, I know):
>
> ...
> postrotate
> test -s '/var/run/iotwatch-LOC1/iotwatch-LOC1.pid' &&
> systemctl kill -s HUP --kill-who=main iotwatch@LOC1.service
> endscript
> ...
>
> I've verified that the PID file exists (just rebooted the server a few
> minutes ago):
> # ll /var/run/iotwatch-LOC1/iotwatch-LOC1.pid
> -rw-r--r-- 1 root root 5 Sep 30 10:07
> /var/run/iotwatch-LOC1/iotwatch-LOC1.pid
>

Do you need to check for it in the first place?

Does the same command work from interactive CLI?


>
> My service would log the arrival of any HUP signal, but it didn't. Also in
> syslog I could not find any error message related to "systemctl kill".
> What might be wrong?
>
> My service is using ExecStartPre, ExecStartPost, and ExecStart. Could
> systemd be confused about "--kill-who=main" then?


--kill-who=main means the signal will be sent to the "main" process that
was started from ExecStart (shown as "Main PID:" in systemctl status).

The more preferred way of doing this is to have "ExecReload=/bin/kill -HUP
$MAINPID" and then `systemctl reload foo.service`.

Sending HUP to ExecStartPre and ExecStartPost doesn't make sense, since
those are supposed to be short-running commands – they are not allowed to
actually *have* daemons.

-- 
Mantas Mikulėnas
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] 99-default.link which such a high number ?

2020-09-25 Thread Mantas Mikulėnas
On Fri, Sep 25, 2020, 17:46 Francis Moreau  wrote:

> Hello,
>
> I want to override /usr/lib/systemd/network/99-default.link so I need
> to create a file starting with "99-" prefix.
>
> This doesn't seem logical to me because the numbers are supposed to
> encode the priority however nothing is left to the user if the
> defaults used is 99.
>

It depends on whether the _first_ matching file is used, or whether the
_last_ matching file is used – different programs choose differently. (If
the program merges all files, it still depends on whether the first value
of a particular setting is used, or whether the last one is used.)

As mentioned in systemd.link(5), udev only chooses one .link file per
interface – just the first one that matched – therefore 00 is the highest
priority.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] spurious failures of resolved

2020-09-24 Thread Mantas Mikulėnas
On Thu, Sep 24, 2020 at 2:45 PM Roman Odaisky  wrote:

> Hi,
>
> I have the following resolved configuration:
>
> [Resolve]
> DNS=8.8.8.8 8.8.4.4
> Domains=~.
>
> and the following resolvectl output:
>
> Link 76 (usb0)
>   Current Scopes: DNS
> DefaultRoute setting: yes
>LLMNR setting: yes
> MulticastDNS setting: no
>   DNSOverTLS setting: no
>   DNSSEC setting: no
> DNSSEC supported: no
>   Current DNS Server: 192.168.42.129
>  DNS Servers: 192.168.42.129
>   DNS Domain: ~.
>
> Link 2 (wlp59s0)
>   Current Scopes: DNS
> DefaultRoute setting: yes
>LLMNR setting: yes
> MulticastDNS setting: no
>   DNSOverTLS setting: no
>   DNSSEC setting: no
> DNSSEC supported: no
>   Current DNS Server: 
>  DNS Servers: 
>   
>   DNS Domain: ~.
>
> The default route is via usb0. The wlp59s0 link is faulty (that’s why I’ve
> resorted to USB tethering). The DNS servers provided by DHCP for that link
> use
> public IP addresses yet decline to provide services for clients outside
> that
> ISP, with responses like this:
>
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18189
> ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
> ;; WARNING: recursion requested but not available
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 2800
> ;; QUESTION SECTION:
> ;freedesktop.org.   IN  A
>
> (note it’s not an NXDOMAIN)
>
> The second IP address is more honest and sets status: REFUSED.
>
> This situation results in the following behavior: if I query some domain,
> it
> always fails for the first time then works afterwards.
>
> $ resolvectl query google.com.uy
> google.com.uy: resolve call failed: 'google.com.uy' does not have any RR
> of
> the requested type
>
> $ resolvectl query google.com.uy
> google.com.uy: 172.217.169.163 -- link: usb0
>
> -- Information acquired via protocol DNS in 5.8ms.
> -- Data is authenticated: no
>
> Did I misconfigure something? Did I misread resolved.conf(5) which states
> “Use
> the construct "~." to use the system DNS server defined with DNS=
> preferably
> for all domains”? Is there a bug?
>

You have "~." for the global config, but your Networkmanager or something
also sets "~." for each of your two links, so all those settings are back
to being the same priority again.

-- 
Mantas Mikulėnas
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] systemd doesn't see ttyPS0 devices from udev

2020-09-23 Thread Mantas Mikulėnas
On Wed, Sep 23, 2020, 09:21 ZhouPeng  wrote:

>
> Thank you  very much for you great suggestions.
>
> I chroot the rootfs and tried to the 3 methods in '/usr/lib/udev/rules.d'
> respectively:
>
> try 1) add  a line of  ACTION!="remove", KERNEL=="ttyPS0", TAG+="systemd"
> below the line of  "ACTION=="remove", GOTO="systemd_end"" in file
> 99-systemd.rules
> try 2) add  a line of  ACTION!="remove", KERNEL=="ttyPS0",  NAME="ttyPS0",
> TAG+="systemd"  below the line of  "ACTION=="remove", GOTO="systemd_end""
> in file 99-systemd.rules
> try 3) replace the line  "SUBSYSTEM=="tty",
> KERNEL=="tty[a-zA-Z]*|hvc*|xvc*|hvsi*|ttysclp*|sclp_line*|3270/tty[0-9]*",
> TAG+="systemd" with "SUBSYSTEM=="tty",
> KERNEL=="ttyPS[0-9]|tty[a-zA-Z]*|hvc*|xvc*|hvsi*|ttysclp*|sclp_line*|3270/tty[0-9]*",
> TAG+="systemd"",  in file 99-systemd.rules.
>

At least the 1st one *should* have worked, though NAME= seems wrong in the
2nd one...


> At the same time, I replace the line of
> "KERNEL=="tty[A-Z]*[0-9]|ttymxc[0-9]*|pppox[0-9]*|ircomm[0-9]*|noz[0-9]*|rfcomm[0-9]*",
> GROUP="dialout"" with
> "KERNEL=="ttyPS[0-9]|tty[A-Z]*[0-9]|ttymxc[0-9]*|pppox[0-9]*|ircomm[0-9]*|noz[0-9]*|rfcomm[0-9]*",
> GROUP="dialout"".
>

This line is irrelevant, since TAG+="systemd" is the important part –
groups and modes shouldn't be the problem.



> But they didn't take any effect.
>
> Then at the same time, I do
> cp /usr/lib/systemd/system/serial-getty@.service
> /etc/systemd/system/serial-getty@ttyPS0.service
> Edit /etc/systemd/system/serial-getty\@ttyPS0.service:  replace
> "ExecStart=-/sbin/agetty --keep-baud 115200,38400,9600 %I $TERM" with
> "ExecStart=-/sbin/agetty --keep-baud 115200 %I $TERM"
> ln -s /etc/systemd/system/serial-getty@ttyPS0.service
> /etc/systemd/system/getty.target.wants/
>
> But there was still no effect. There is still boot failure logs like:
> [ *] (3 of 3) a start job is running for dev-ttyPS0.device (41s / 1min
> 30s)// **here**
> ...
>  [ TIME ] Timed out waiting for device dev-ttyPS0.device. // **here**
> ...
>

Yeah, the baudrate won't change anything if systemd doesn't even see the
device in the first place. It doesn't even get to the point of launching
agetty.


> By the way, Do I need to add some configuration to tiger executing
> something like 'mknod /dev/ttyPS0 c 248 0'  for systemd or udev pls? If
> needed, where is the proper place to add this action pls?
>

No. The kernel automatically creates device nodes (as long as /dev has a
"devtmpfs" mounted); udev only applies modes/symlinks. The problem here is
that udev doesn't properly inform systemd about the new device.


> >What does "udevadm info -a /dev/ttyPS0" output?
> I can not get a console from ttyPS0, so I can not run  "udevadm info -a
> /dev/ttyPS0" in the target(xilinx pynq) board.
>

Try booting with the 'rescue' option, this should directly create a root
login prompt on the kernel console.

>
Alternatively, try creating a simple .service that runs this command, then
you'll find its output in the journal or in the boot console (depending on
what StandardOutput= you set).


>
> Thanks all,
> At 2020-09-22 20:34:15, "Andrei Borzenkov"  wrote:
> >On Tue, Sep 22, 2020 at 2:53 PM Mantas Mikulėnas 
> wrote:
> >>
> >> On Tue, Sep 22, 2020 at 1:46 PM Andrei Borzenkov 
> wrote:
> >>>
> >>> On Tue, Sep 22, 2020 at 1:35 PM ZhouPeng 
> wrote:
> >>> >
> >>> > Hi all,
> >>> >
> >>> > When I use Fedora image as rootfs on Xilinx PYNQ-Z2, I encountered
> the issue  when use the /dev/ttyPS0.
> >>> > I think the issue is because systemd and udev on fedora can didn't
> detect ttyPS0 properly. Do I need to install any other package or do some
> special configuration?
> >>> >
> >>> > **systemd version the issue has been seen with**
> >>> > udevadm --version
> >>> > 237
> >>> > systemd-udev.riscv64 237-1.0.riscv64.fc28
> >>> >
> >>> >
> >>> > **Unexpected behaviour you saw**
> >>> > We can see ttyPS0 boots ok in the kernel boot period:
> >>> > [0.18] console [ttyPS0] enabledat MMIO 0xe000 (irq = 2,
> base_baud = 625) is a xuartps
> >>> > [0.18] console [ttyPS0] enabled
> >>> >
> >>> > But, when boot into s

Re: [systemd-devel] systemd doesn't see ttyPS0 devices from udev

2020-09-22 Thread Mantas Mikulėnas
On Tue, Sep 22, 2020 at 1:46 PM Andrei Borzenkov 
wrote:

> On Tue, Sep 22, 2020 at 1:35 PM ZhouPeng  wrote:
> >
> > Hi all,
> >
> > When I use Fedora image as rootfs on Xilinx PYNQ-Z2, I encountered the
> issue  when use the /dev/ttyPS0.
> > I think the issue is because systemd and udev on fedora can didn't
> detect ttyPS0 properly. Do I need to install any other package or do some
> special configuration?
> >
> > **systemd version the issue has been seen with**
> > udevadm --version
> > 237
> > systemd-udev.riscv64 237-1.0.riscv64.fc28
> >
> >
> > **Unexpected behaviour you saw**
> > We can see ttyPS0 boots ok in the kernel boot period:
> > [0.18] console [ttyPS0] enabledat MMIO 0xe000 (irq = 2,
> base_baud = 625) is a xuartps
> > [0.18] console [ttyPS0] enabled
> >
> > But, when boot into systemd, it failed on dev ttyPS0:
> > [ TIME ] Timed out waiting for device dev-ttyPS0.device. // **here**
>
> systemd only monitors for devices with "sysemd" tag. Tags are assigned
> by udev rules. You should add rule to assign tag to ttyPS0. I have no
> idea what it is, but something like
>
> ACTION!="remove", KERNEL=="ttyPS0", TAG+="systemd"
>
> should do it. Whether this should go upstream depends on how common
> this device is.


Well yes, but that should have been already covered by the existing
upstream rules:

99-systemd.rules:12:SUBSYSTEM=="tty",
KERNEL=="*tty[a-zA-Z]**|hvc*|xvc*|hvsi*|ttysclp*|sclp_line*|3270/tty[0-9]*",
TAG+="systemd"

-- 
Mantas Mikulėnas
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] systemd-encrypt is a little painful

2020-09-07 Thread Mantas Mikulėnas
On Mon, Sep 7, 2020 at 5:33 PM Lennart Poettering 
wrote:

> On Mo, 07.09.20 13:51, Kai Hendry (hen...@webconverger.com) wrote:
>
> > Hi guys,
> >
> > After making https://www.youtube.com/watch?v=gh3jkIENmAM I'm
> > thinking the install process could be a lot smoother if:
> >
> > somehow systemd could do the initramfs, i.e. take over mkinitcpio's
> > hook role
>
> Hmm, mkinitcpio? That's arch? Does that run systemd inside?
>

It can optionally use systemd (although the default is to use a traditional
busybox script), and it sounds like Kai *has* configured it that way,
otherwise sd-encrypt wouldn't have had any effect whatsoever.

"sd-encrypt" is the mkinitcpio module (hook) which adds the standard
systemd-cryptsetup(-generator) & systemd-ask-password binaries.

systemd-gpt-auto-generator should work, as it gets added together with the
rest in the main "systemd" hook.

-- 
Mantas Mikulėnas
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Journal message timestamps

2020-09-07 Thread Mantas Mikulėnas
On Fri, Sep 4, 2020 at 6:59 PM Lennart Poettering 
wrote:

> On Do, 27.08.20 11:33, Mark Corbin (m...@dibsco.co.uk) wrote:
>
> > Hello
> >
> > I am working on time synchronisation issues at boot for systems without
> an
> > RTC (using balenaOS on a Raspberry Pi 3) and have some questions about
> how
> > journald assigns timestamps to log messages.
> >
> > When I boot my system and look at the journal I see an initial date/time
> for
> > kernel messages, e.g. '1 June 2020 10:00:00' followed by messages with
> the
> > 'correct' date/time once the system time has been set from another
> source,
> > e.g. build time, NTP, etc. This means that over several reboots I have
> lots
> > of sets of log messages from 1 June 2020 which understandably confuses
> the
> > 'journalctl --list-boots' command. I found an issue that describes the
> > problem here https://github.com/systemd/systemd/issues/662 and had
> assumed
> > that there wasn't anything I could do about this.
> >
> > However, when running some tests on a board with Raspberry Pi OS I found
> > that it didn't suffer from the same problem. RPI OS uses a 'fake-hwclock'
> > service to restore the previous boot time from a file and this time gets
> > applied to all messages in the journal prior to this point. I added the
> > 'fake-hwclock' service to my system which resulted in the timestamps
> being
> > correct the majority of the time, but I was still seeing some boots where
> > the initial messages were showing '1 June 2020'. I eventually tracked the
> > intermittent behaviour down to whether the 'fake-hwclock' time setting
> > occurred in the same system log file as the initial kernel boot
> messages. On
> > my RPI OS board the runtime journal was set to 8MB, so the date/time
> setting
> > always occurred in the first journal file. On my system the runtime
> journal
> > was set to 4MB, so the date/time setting was sometimes happening in the
> > second journal file leaving the messages in the first file with a date
> of '1
> > June 2020'.
> >
> > So my questions are...
> >
> > It seems that journald is using the date/time from the 'fake-hwclock'
> > service to update the timestamps of earlier log messages within the same
> > file. Is this correct?
>
> No. We do not retroactively change written out records.
>
> However, when comparing log entries we prefer the record sequence
> number if two records come from the same system. And if that doesn't
> work, then we prefer monotonic clocks if two records cme from the same
> boot. Wallclock is only used for comparing two records if they are
> from different boots altogether.
>
> > What would be the best technique for ensuring that my journal logs always
> > display the 'best' time for log messages (either 'fake-hwclock' or NTP)?
> Do
> > I always have to ensure that the journal is large enough to capture my
> > initial time setting event in the first file?
>
> There's no nice answer for that. We do not patch written out journal
> records once they are written. They are considered immutable. This
> means, from the journal's PoV if you generated a bunch of records in
> the initrd or early boot (i.e. before /var/log/journal is available)
> and you have no usable wallclock time, and you power cycle 10 times in a
> row, then we have no indication about which of the 10 series of
> recrods came in which order before the others.
>
> To fix that we'd have to keep a separate log of boot ids or so
> somewhere, which we could use as auxiliary source of truth if all we
> have are bootids+monotonic time which came first by comparing boot
> ids. But that would still not be perfect since we could write that out
> only late (i.e. after /var becomes writable), so the order before that
> could not be reconstructed either if the system doesn't get that far.
>

Hmm, but if there's no /var in which to store the append-only log of boot
IDs, then there's also no /var in which journal messages would persist
either, is there? So one wouldn't be seeing messages from previous boots
anyway.

Also, if /var *is* available, didn't .journal files also have some sort of
global sequence number that could be used when timestamps fail?

-- 
Mantas Mikulėnas
___
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

2020-09-07 Thread Mantas Mikulėnas
On Sun, Sep 6, 2020 at 9:28 PM Alexander E. Patrakov 
wrote:

> On Sat, Sep 5, 2020 at 3:12 AM Lennart Poettering
>  wrote:
> >
> > On Fr, 04.09.20 21:41, Dave Howorth (syst...@howorth.org.uk) wrote:
> >
> > > On Fri, 4 Sep 2020 17:44:23 +0200
> > > Lennart Poettering  wrote:
> > > > On Fr, 04.09.20 17:10, Reindl Harald (h.rei...@thelounge.net) wrote:
> > > >
> > > > > > No, that's not supported in sd-boot. A boot loader is a boot
> > > > > > loader, it should contain a fragile storage stack. It's kinda
> > > > > > what sd-boot is supposed to do better than grub.
> > > > >
> > > > > well, a boot loader should just *load* and not write anything so
> > > > > RAID1 is technically no problem and it shouldn't matter which of
> > > > > the 1, 2, 3 or 4 disks is there unless one survived.
> > > >
> > > > Robust boot loaders typically want to write boot counters to disk, so
> > > > that they can automatically revert back to older versions of the
> > > > OS/kernel if it doesn't boot. Thus some form of write access is
> > > > necessary if you care about robustness.
> > >
> > > But surely a boot loader of all things should never try to write to the
> > > place it is loading from? Booting should be idempotent (as long as it
> > > works, for sure). The only sane policy would seem to be that the loader
> > > had another path to a separate writable area?
> >
> > UEFI provides file system access. Both read and write. Typically for
> > VFAT. Yeah, a boot loader should not modify the files it is itself
> > loaded from and also keep writes generally at a minimum, but counting
> > boots is generally the absolute minimum necessary, and can be
> > implemented by single sector updates in file systems such as VFAT. So
> > that's what sd-boot for example does.
>
> May I know why this design has been chosen over keeping the boot
> counts in UEFI variables?
>

I think it was considered but strongly rejected. The problem is that many
older firmwares are especially fragile when it comes to NVRAM writes
(remember Samsung in 2013?) On my older ASUS laptop I've already had
problems after merely adding/deleting boot entries too many times, and I
*would not* want a write to happen on every single boot.

As much as I distrust the FAT implementations in my computers' firmwares, I
still trust them a little bit more than their EFI variable NVRAM
management. (Partly because I don't *have* to trust them as much – if
everything goes bad I can at least wipe and re-mkfs the EFI system
partition from zero, I can't easily do the same with the NVRAM.)

-- 
Mantas Mikulėnas
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Antw: [EXT] Journal message timestamps

2020-08-28 Thread Mantas Mikulėnas
On Fri, Aug 28, 2020, 10:06 Ulrich Windl 
wrote:

> >>> Mark Corbin  schrieb am 27.08.2020 um 12:33 in
> Nachricht
> :
> > Hello
> >
> > I am working on time synchronisation issues at boot for systems without
> > an RTC (using balenaOS on a Raspberry Pi 3) and have some questions
> > about how journald assigns timestamps to log messages.
> >
> > When I boot my system and look at the journal I see an initial date/time
> > for kernel messages, e.g. '1 June 2020 10:00:00' followed by messages
> > with the 'correct' date/time once the system time has been set from
> > another source, e.g. build time, NTP, etc. This means that over several
> > reboots I have lots of sets of log messages from 1 June 2020 which
> > understandably confuses the 'journalctl ‑‑list‑boots' command. I found
> > an issue that describes the problem here
> > https://github.com/systemd/systemd/issues/662 and had assumed that
> there
> > wasn't anything I could do about this.
>
> "Good old UNIX" had the feature to "guess" the current time by looking at
> the
> last update in the root filesystem (when that seemed newer than the
> "current
> time").
> One idea would be to have a "timestamp file" (much like a low-resolution
> software RTC) that is updated periodically when it's known that the system
> time
> is correct. Then after boot you would get a good guess, and time wouldn't
> jump
> backwards, too.
>

I believe systemd already does that, although I keep forgetting the details
– not sure if it's part of core or if it's part of systemd-timesyncd.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] protecting sshd against forkbombs, excessive memory usage by other processes

2020-08-12 Thread Mantas Mikulėnas
On Wed, Aug 12, 2020 at 7:03 AM Tomasz Chmielewski  wrote:

> I've made a mistake and have executed a forkbomb-like task. Almost
> immediately, the system became unresponsive, ssh session froze or were
> very slow to output even single characters; some ssh sessions timed out
> and were disconnected.
>
> It was not possible to connect a new ssh session to interrupt the
> runaway task - new connection attempt were simply timing out.
>
> SSH is the only way to access the server. Eventually, after some 30
> mins, the system "unfroze" - but - I wonder - can systemd help sysadmins
> getting out of such situations?
>
> I realize it's a bit tricky, as there are two cases here:
>
> 1) misbehaving program is a child process of sshd (i.e. user logged in
> and executed a forkbomb)
>

I don't think "child process of sshd" is the useful part, as logged-in user
processes are actually moved to a separate cgroup for the session – so yes,
they're sshd children, but they actually have resource limits fully
separate from the main sshd daemon process.

Which means that with systemd, each user already has their own limit on the
number of processes/tasks (the default in user-.slice.d is TasksMax=33%
of...something, but it could be lowered to e.g. 10% or to 4096) without
affecting the service itself.

So I'm sure that sshd.service and user-0.slice could be tweaked somehow to
give root a higher priority at cgroup level, but that depends on what your
system actually ran out of...

-- 
Mantas Mikulėnas
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] systemd-networkd and interface names

2020-08-10 Thread Mantas Mikulėnas
That seems to be working as expected.

The initial, kernel-assigned name is always going to be an incrementing
eth#, wlan#, or something similar. It's up to the userspace (i.e. udev) to
rename it to something custom.

However, interfaces can only be renamed while they're *not* up, otherwise
the kernel refuses it with EBUSY. If some program brings eth1 up without
waiting for udev to finish rule processing, renaming will fail and it'll
just remain eth1.


On Mon, Aug 10, 2020, 21:45 Matt Zagrabelny  wrote:

> Greetings,
>
> I am using systemd-networkd and I am wondering how/why the interface names
> get chosen.
>
> Scenario:
>
> I am expecting an interface name to be enp1s0. Instead I get eth1.
>
> It appears that eth1 is being referenced in things like:
> /etc/default/isc-dhcp-server
> /etc/default/minissdpd
>
> If I change those instances of eth1 to enp1s0, then the interface rename
> happens as expected:
>
> # dmesg | grep eth1
> [1.751611] tg3 :01:00.0 eth1: Tigon3 [partno(BCM95722A2202G) rev
> a200] (PCI Express) MAC address 00:10:18:59:c3:6f
> [1.751613] tg3 :01:00.0 eth1: attached PHY is 5722/5756
> (10/100/1000Base-T Ethernet) (WireSpeed[1], EEE[0])
> [1.751614] tg3 :01:00.0 eth1: RXcsums[1] LinkChgREG[0] MIirq[0]
> ASF[0] TSOcap[1]
> [1.751616] tg3 :01:00.0 eth1: dma_rwctrl[7618] dma_mask[64-bit]
> [   17.763317] tg3 :01:00.0 enp1s0: renamed from eth1
>
> Is this expected behavior with the kernel, udev, etc.?
>
> Thanks for any help!
>
> -m
> ___
> 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] Wrong interface name

2020-08-06 Thread Mantas Mikulėnas
On Tue, Aug 4, 2020 at 4:22 PM Bao Nguyen  wrote:

> Hello,
>
>
>
> Recently I found that my kvm guest has inconsistent network names every
> reboot. Here is the log
>
>
>
> myPC kernel: virtio_net virtio0 eth000102030405: renamed from eth0
>
> myPC kernel: virtio_net virtio1 eth000102030406: renamed from eth1
>
> myPC kernel: virtio_net virtio2 eth000102030407: renamed from eth2
>

Those look different from udev's typical "persistent" naming scheme, which
never uses the eth* prefix. It might be a custom udev rule, or another (non
udev) service doing the renaming – the same message is shown in all cases.


> myPC kernel: virtio_net virtio0 eth1: renamed from eth000102030405
>
> myPC kernel: virtio_net virtio1 eth3: renamed from eth000102030406
>
> myPC kernel: virtio_net virtio2 eth4: renamed from eth000102030407
>

This *might* be an old "70-persistent-net" udev rules file (the kind that
Debian used to auto-generate in the past).


>
>
> Looks like systemd-udevd has renamed the interface name but incorrectly.
> Could you please let me know if the above log is printed out because
> system-udevd runs or from kernel?
>

The message is shown by the kernel, but the actual renaming could have been
done by anything – udev, `ip link`, or literally any other userspace tool.


> And why the name is changed incorrectly, is it due to some udev rules?
>

Could be either custom udev rules, or custom /etc/systemd/network/*.link
files, or some network management daemon with its own renaming logic.  My
guess is that lines 1-3 are a custom rule and 4-6 are 70-persistent-net.

You might find at least some information by running `udevadm test
/sys/class/net/eth0` (replace eth0 with any interface that currently
exists).

Systemd's standard interface renaming rules (at 80-net-setup-link.rules)
were written to never override any custom name that earlier rules might
have set.


> Is there any way I can change to make the interface name persistent on
> each reboot.
>

The kernel does not remember anything across reboots. The only way to make
a custom name persistent is to rename it from userspace every single time
(e.g. udev rules).

-- 
Mantas Mikulėnas
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Upstreaming systemd patch

2020-07-30 Thread Mantas Mikulėnas
On Thu, Jul 30, 2020 at 8:51 AM Amit anand  wrote:

> Hi,
>
> Not able to create pull request to systemd, permission denied to my github
> user credentials.
>
> I git cloned https://github.com/systemd/systemd
>
> While creating pull request,
> git push --set-upstream origin 
> 1. Entered github username
> 2. Entered github passwd
> getting below error message for my github username.
> remote: Permission to systemd/systemd.git denied to 
> fatal : unable to access 'https://github.com/systemd/systemd.git/': The
> requested URL returned error: 403
>

Pull requests are usually made from your own personal repository. Use
Github's "Fork" feature to get a writable copy of the repository, then `git
remote add` its URL and push there.

For example:

git remote add fork https://github.com//systemd
git push -u fork 

-- 
Mantas Mikulėnas
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] systemd.timer every X days?

2020-07-28 Thread Mantas Mikulėnas
I'd create a single raidcheck.service that runs daily and calls a script
that itself determines which device to check, e.g. /dev/md$[dayofyear % 16].

On Sun, Jul 26, 2020, 22:56 Ian Pilcher  wrote:

> My NAS has 16 MD RAID devices.  I've created a simple service
> (raidcheck@.service) that will trigger a check of the RAID device
> identified by the argument.  E.g., 'systemctl start raidcheck@md1' will
> trigger the check of md1 (after checking that no other array is being
> checked/synced, no arrays are degraded, etc.).
>
> It takes 6-8 hours to check one of these arrays, so I want to run one
> check every night at 23:00.  So (picking tonight as an arbitrary
> starting point) md1 would run tonight, md2 would run tomorrow night, md3
> would run the following night ... all the way through md16.  Then the
> cycle would start over with md1.
>
> I had thought that I would be able to create 16 separate timers (one for
> each device), each scheduled to trigger every 16 days at 23:00, starting
> on a particular day.
>
> Looking through the systemd.timer(5) and systemd.time(7) man pages,
> however, I haven't been able to figure out how to do this.  Is it not
> possible, or am I missing something?
>
> --
> 
>   In Soviet Russia, Google searches you!
> 
>
> ___
> 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


  1   2   3   4   5   6   7   8   9   10   >