Re: [systemd-devel] Q: journalctl -g

[Michael Chapman]

On Fri, 4 Mar 2022, Ulrich Windl wrote:
> Hi!
> 
> In SLES15 SP3 (systemd-246.16-7.33.1.x86_64) I have this effect, wondering 
> whether it is a bug or a feature:
> When using "journalctl -b -g raid" I see that _ome_ matches are highlighted 
> in red, but others aren't. For example:
> Mar 01 01:37:09 h16 kernel: mega*raid*_sas :c1:00.0: BAR:0x1  BAR's 
> base_addr(phys):0xa550  mapped virt_addr:0xae628322
> Mar 01 01:37:09 h16 kernel: megaraid_sas :c1:00.0: FW now in Ready state
> ...

Messages at log priority LOG_INFO -- between LOG_NOTICE and LOG_DEBUG -- 
don't get any highlight colour set [1]. This seems like a simple bug to 
me.

[1] 
https://github.com/systemd/systemd/blob/178d598b5fae36fa9d54c30668771f9c626724f6/src/basic/terminal-util.c#L1413-L1449

Re: [systemd-devel] systemd.sockets vs xinetd

[Michael Chapman]

On Thu, 10 Feb 2022, Yolo von BNANA wrote:
> Hello,
> 
> i read the following in an LPIC 1 Book:
> 
> " If you’ve done any investigation into systemd.sockets, you may believe 
> that it makes super servers like xinetd obsolete. At this point in time, 
> that is not true. The xinetd super server offers more functionality than 
> systemd.sockets can currently deliver. "
> 
> I thought, that this information could be deprecated.
> 
> Is systemd.sockets at this point in time a good replacement for xined?
> 
> Is there a good resource to dive deeper into it?
> 
> 
> Yolo

Surely it would be up to the author of that book to justify that claim?

They say it "offers more functionality". Do they say anything more than 
that... like precisely what functionality they're talking about?

Re: [systemd-devel] Systemd hang when restarting a service during shutdown

[Michael Chapman]

On Mon, 8 Nov 2021, Sean Nyekjaer wrote:
> Hi,
> 
> Regarding,
> https://github.com/systemd/systemd/issues/21203
> 
> I think the point of the issue missed when the issue got closed.
> 
> We have a service that is changing configs for systemd-networkd and
> issuing a `systemctl restart systemd-networkd`.
> An other service is checking uptime and issues a `systemctl reboot`,
> when our max uptime have been exeeced.
> If restart of systemd-networkd happens while a reboot is in progress,
> the system will hang "forever" (and continue to pet the watchdog).
> This is not a thing that eventually will timeout and reboot the
> system...
> 
> /Sean

This looks very similar to a problem I saw mentioned on Reddit a few days 
ago:

   
https://www.reddit.com/r/Fedora/comments/qgj1bh/systemctl_emergency_question_f34_f35_beta/

There the problem was that `systemctl emergency` hung. It looked like it 
was because the transaction to switch to emergency mode got cancelled, as 
something wanted to talk to logind after it had shut down. Socket 
activation started it back up again, and that cancelled the remaining jobs 
in the transaction. systemd ended up idle with most services shut down and 
with nothing useful running.

In your case it's not logind that's being restarted... it's resolved or 
networkd. But the overall effect appears to be the same. You end up with a 
system where most things are stopped, and where it's not making any 
progress towards the reboot you asked for.

Re: [systemd-devel] masking --global, but allowing --user

[Michael Chapman]

On Sat, 18 Sep 2021, Matt Zagrabelny wrote:
> Greetings,
> 
> I believe the Debian package of mpd enables a --global .service and
> .socket unit for the mpd daemon/service.
> 
> I'd like to mask that and install it just to a single --user service.

Why do you need to mask the socket and service at the --global level? Why 
not simply not enable them there?

If a unit is not enabled globally, but it is not masked, individual users 
can still enable it for their own user.

Re: [systemd-devel] Why systemd-journald is creating '/var/log/journal/machine_id" directory when Storage=auto

[Michael Chapman]

On Sun, 29 Aug 2021, Nishant Nayan wrote:
> Awesome, thanks!
> 
> Also, where can I find the code section where services And kernel logs to
> journald?
> After tracing from 'main' at journald.c I came across the part where
> various sockets are opened and validated (/run/systemd/journal/stdout,
> /dev/kmsg, /dev/log ) for journald to listen to logs of systemd services
> and kernel. That is the server side part.
> 
> Where can I find the client side journald code where services and kernel
> sends their logs to journal.

If programs are using sd-journal, they are using the code 
from src/libsystemd/sd-journal/.

Programs can also implement the journal protocol themselves, using the 
documentation at:

https://systemd.io/JOURNAL_NATIVE_PROTOCOL/

The kernel doesn't do any of this, of course. journald *reads* from the 
kernel ring buffer.

Re: [systemd-devel] Why systemd-journald is creating '/var/log/journal/machine_id" directory when Storage=auto

[Michael Chapman]

On Sun, 29 Aug 2021, Nishant Nayan wrote:
> Also I was wondering where in the code does journald.config file changes
> are parsed?
> For example in the above code , the line :-
>   if (s->storage == STORAGE_PERSISTENT)
> Here, s->storage corresponds to 'Storage' option of conf file right?
> How is it getting set when we edit the conf file?

The configuration files are loaded in server_parse_config_file(). The 
actual code that maps keys in the files to variables in the program is 
generated by gperf [1] from the journald-gperf.gperf source file.

[1] https://www.gnu.org/software/gperf/manual/html_node/index.html

> Also, on doing "ls /run/log/journal/machine_id/"
> I can see output as following
> .journal
> .journal
> .
> .
> .
> system.journal
> 
> Is 'system.journal' is the currently active journal and rest are archived
> journals?

That's correct.

Re: [systemd-devel] Why systemd-journald is creating '/var/log/journal/machine_id" directory when Storage=auto

[Michael Chapman]

On Sun, 29 Aug 2021, Nishant Nayan wrote:
> I was looking into the code of systemd-journald and found this (in
> system_journal_open() ) :-
> 
> if (!s->system_journal && IN_SET(s->storage, STORAGE_PERSISTENT,
> STORAGE_AUTO) && (flush_requested || flushed_flag_is_set())) {
> 
> /* If in auto mode: first try to create the machine
>  * path, but not the prefix.
>  *
>  * If in persistent mode: create /var/log/journal and
>  * the machine path */
> 
> if (s->storage == STORAGE_PERSISTENT)
> (void) mkdir_p("/var/log/journal/", 0755);
> 
> (void) mkdir(s->system_storage.path, 0755);
> 
> fn = strjoina(s->system_storage.path, "/system.journal");
[...]
> 
> Also after reading the comment, how is it possible to create
> '/var/log/journal/machine_id' without creating the prefix? I am assuming
> '/var/log/journal' is the prefix .

Sorry, I actually misread your question here.

In Storage=auto mode, no attempt to create the /var/log/journal directory 
is made. If it doesn't exist, then the persistent journal simply fails to 
be opened.

Re: [systemd-devel] Why systemd-journald is creating '/var/log/journal/machine_id" directory when Storage=auto

[Michael Chapman]

On Sun, 29 Aug 2021, Nishant Nayan wrote:
> I was looking into the code of systemd-journald and found this (in
> system_journal_open() ) :-
> 
> if (!s->system_journal && IN_SET(s->storage, STORAGE_PERSISTENT,
> STORAGE_AUTO) && (flush_requested || flushed_flag_is_set())) {
> 
> /* If in auto mode: first try to create the machine
>  * path, but not the prefix.
>  *
>  * If in persistent mode: create /var/log/journal and
>  * the machine path */
> 
> if (s->storage == STORAGE_PERSISTENT)
> (void) mkdir_p("/var/log/journal/", 0755);
> 
> (void) mkdir(s->system_storage.path, 0755);
> 
> fn = strjoina(s->system_storage.path, "/system.journal");
> 
> Here, system_storage.path is set to "strjoin("/var/log/journal/",
> SERVER_MACHINE_ID(s));" in previous function call.
> 
> As far as I understood its saying to create '/var/log/journal' directory
> when storage is set to 'persistent'.
> 
> But in either of the cases (persistent or auto) why is it creating
> '/var/log/journal/machine_id' directory ( (void)
> mkdir(s->system_storage.path, 0755); ) ??
> 
> 'auto' will store logs persistently if '/var/log/journal' is created
> beforehand or else logs will be written in '/run/log/journal' .
> 
> For 'auto' it should not create '/var/log/journal/machine_id' directory
> right?

All of this is guarded with:

flush_requested || flushed_flag_is_set()

In other words, this code path is used if a request to flush the journal 
data from /run into /var had been received, or the runtime journal had 
already been flushed in the past.

> Also after reading the comment, how is it possible to create
> '/var/log/journal/machine_id' without creating the prefix? I am assuming
> '/var/log/journal' is the prefix .

mkdir_p() creates parent directories, like `mkdir -p` in your shell.

Re: [systemd-devel] [hostnamed] Why the service will automatically exit after 30 seconds

[Michael Chapman]

On Thu, 19 Aug 2021, Michael Chapman wrote:
> On Thu, 19 Aug 2021, Cristian Rodríguez wrote:
> > On Tue, Aug 17, 2021 at 9:35 PM 李成刚  wrote:
> > >
> > > How to configure this service so that it will not automatically exit
> > 
> > 
> > So what are you trying to accomplish with this ? why do you need yet
> > another service running when it is totally idle ?
> > 
> > > When the systemd-hostnamed service is started through policykit, the 
> > > password window will automatically exit, which seems to be a terrible 
> > > experience
> > 
> > DAFUQ? if polkit is really talking to hostnamed then has to deal with
> > things so they either remaining alive or connect again ...
> 
> It's the other way around. hostnamed uses polkit to authorise requests 
> sent to it over D-Bus.
> 
> If hostnamed is exiting while in the middle of a polkit conversation, then 
> yes I would say that is a bug in hostnamed. It really ought not to do 
> that.

I've looked at this more closely now, and it's a bit more complicated than 
I would have liked.

While hostnamed's own idle timeout can easily be disabled while a 
polkit conversation is in progress, that won't necessarily help anybody 
using hostnamectl. hostnamectl uses sd-bus's default method call timeout, 
which is 25 seconds.

Perhaps this should be increased for method calls that are likely to 
result in using polkit? 25 seconds might be too short for some people to 
enter their password.

Is it possible for sd_bus_call to detect that the recipient of a call has 
dropped off the bus and is never going to return a response? If that were 
possible we could possibly rely on that rather than an explicit timeout. I 
think the answer to this question might be "no" though...

Re: [systemd-devel] [hostnamed] Why the service will automatically exit after 30 seconds

[Michael Chapman]

On Thu, 19 Aug 2021, Cristian Rodríguez wrote:
> On Tue, Aug 17, 2021 at 9:35 PM 李成刚  wrote:
> >
> > How to configure this service so that it will not automatically exit
> 
> 
> So what are you trying to accomplish with this ? why do you need yet
> another service running when it is totally idle ?
> 
> > When the systemd-hostnamed service is started through policykit, the 
> > password window will automatically exit, which seems to be a terrible 
> > experience
> 
> DAFUQ? if polkit is really talking to hostnamed then has to deal with
> things so they either remaining alive or connect again ...

It's the other way around. hostnamed uses polkit to authorise requests 
sent to it over D-Bus.

If hostnamed is exiting while in the middle of a polkit conversation, then 
yes I would say that is a bug in hostnamed. It really ought not to do 
that.

Re: [systemd-devel] Antw: [EXT] Re: [systemd‑devel] systemctl log verbosity

[Michael Chapman]

On Wed, 18 Aug 2021, Ulrich Windl wrote:
> >>> Michael Chapman  schrieb am 18.08.2021 um 08:38 in
> Nachricht :
> > On Wed, 18 Aug 2021, Ulrich Windl wrote:
> >> >>> Michael Chapman  schrieb am 17.08.2021 um 02:52
> in
> >> Nachricht <885331af-bb7-41d0-e8-26c92023b...@very.puzzling.org>:
> >> > On Tue, 17 Aug 2021, Dave Close wrote:
> >> >> I'm trying to run "systemctl show" in a cron script. It works but I get
> >> >> a huge number of extra lines in my log for each run. Why? Can this be
> >> >> suppressed. I don't want to overfill the log.
> >> >> 
> >> >> There is nothing in the man page (that I noticed) indicating that
> "show"
> >> >> causes anything to be logged. But here's an example of what I see.
> >> >> 
> >> >> >Aug 16 16:10:01 svcs systemd[1]: Created slice User Slice of UID 0.
> >> >> >Aug 16 16:10:01 svcs systemd[1]: Starting User Runtime Directory 
> >> > /run/user/0...
> >> >> >Aug 16 16:10:01 svcs systemd[1]: Finished User Runtime Directory 
> >> > /run/user/0.
> >> >> >Aug 16 16:10:01 svcs systemd[1]: Starting User Manager for UID 0...
> >> >> >Aug 16 16:10:01 svcs systemd[80491]: Queued start job for default
> target 
> >> > Main User Target.
> >> >> >Aug 16 16:10:01 svcs systemd[80491]: Created slice User Application
> >> Slice.
> >> >> >Aug 16 16:10:01 svcs systemd[80491]: Condition check resulted in Mark
> boot
> >> 
> >> > as successful after the 
> >> >> user session has run 2 minutes being skipped.
> >> >> >Aug 16 16:10:01 svcs systemd[80491]: Started Daily Cleanup of User's 
> >> > Temporary Directories.
> >> >> >Aug 16 16:10:01 svcs systemd[80491]: Reached target Paths.
> >> >> >Aug 16 16:10:01 svcs systemd[80491]: Reached target Timers.
> >> >> >Aug 16 16:10:01 svcs systemd[80491]: Starting D‑Bus User Message Bus
> >> Socket.
> >> >> >Aug 16 16:10:01 svcs systemd[80491]: Condition check resulted in
> PipeWire
> >> 
> >> > PulseAudio being skipped.
> >> >> >Aug 16 16:10:01 svcs systemd[80491]: Listening on Multimedia System.
> >> >> >Aug 16 16:10:01 svcs systemd[80491]: Starting Create User's Volatile
> Files
> >> 
> >> > and Directories...
> >> >> >Aug 16 16:10:01 svcs systemd[80491]: Finished Create User's Volatile
> Files
> >> 
> >> > and Directories.
> >> >> >Aug 16 16:10:01 svcs systemd[80491]: Listening on D‑Bus User Message
> Bus 
> >> > Socket.
> >> >> >Aug 16 16:10:01 svcs systemd[80491]: Reached target Sockets.
> >> >> >Aug 16 16:10:01 svcs systemd[80491]: Reached target Basic System.
> >> >> >Aug 16 16:10:01 svcs systemd[80491]: Reached target Main User Target.
> >> >> >Aug 16 16:10:01 svcs systemd[80491]: Startup finished in 151ms.
> >> >> >Aug 16 16:10:01 svcs systemd[1]: Started User Manager for UID 0.
> >> >> >Aug 16 16:10:01 svcs systemd[1]: Started Session 72 of User root.
> >> >> >Aug 16 16:10:01 svcs root[80504]: ## logger output from cron script ##
> >> >> >Aug 16 16:10:01 svcs systemd[1]: session‑72.scope: Deactivated
> >> successfully.
> >> >> 
> >> >> I see these additional 23 lines (plus the one‑line script output) every
> >> >> time the script runs. That seems excessively verbose to me.
> >> >> 
> >> >> The system is Fedora 34 x86_64.
> >> > 
> >> > Cron jobs are run with pam_systemd, so they are run within a logind 
> >> > session. If there is no other sessions for root at that time, root's own
> 
> >> > systemd manager is started when the Cron job launches, and is stopped
> when 
> >> > the Cron job terminates. All of these log messages are related to this.
> >> > 
> >> > You may instead want to make root a lingering user:
> >> > 
> >> > loginctl enable‑linger root
> >> > 
> >> > This setting is persistent. You can use disable‑linger at a later time to
> 
> >> > turn it off if necessary.
> >> > 
> >> > With root configured as a lingering user, its systemd manager remains 
> >> > running all the time.
> >> 
> >> After reading the manual page I wonder: Is tha tsetting persistent, i.e.:
> >> Where is that setting stored?
> > 
> > Yes, it is persistent.
> > 
> > Lingering users are just represented as files under 
> > /var/lib/systemd/linger/ (though this is an implementation detail, of 
> > course).
> 
> Of course, but the manual page of systemd-logind.service could state that
> settings are saved persistently "somewhere".
> Currently it does not even mention "linger", but the binary has the string
> "Failed to open /var/lib/systemd/linger/: %m" inside.

Well, the loginctl documentation says:

If enabled for a specific user, a user manager is spawned for
the user at boot and kept around after logouts.

Which kind of implies that there must be some persistent state somewhere 
-- how else would it do this "at boot"? The actual nature of this state 
isn't really that important.

Re: [systemd-devel] Antw: [EXT] Re: [systemd‑devel] systemctl log verbosity

[Michael Chapman]

On Wed, 18 Aug 2021, Ulrich Windl wrote:
> >>> Michael Chapman  schrieb am 17.08.2021 um 02:52 in
> Nachricht <885331af-bb7-41d0-e8-26c92023b...@very.puzzling.org>:
> > On Tue, 17 Aug 2021, Dave Close wrote:
> >> I'm trying to run "systemctl show" in a cron script. It works but I get
> >> a huge number of extra lines in my log for each run. Why? Can this be
> >> suppressed. I don't want to overfill the log.
> >> 
> >> There is nothing in the man page (that I noticed) indicating that "show"
> >> causes anything to be logged. But here's an example of what I see.
> >> 
> >> >Aug 16 16:10:01 svcs systemd[1]: Created slice User Slice of UID 0.
> >> >Aug 16 16:10:01 svcs systemd[1]: Starting User Runtime Directory 
> > /run/user/0...
> >> >Aug 16 16:10:01 svcs systemd[1]: Finished User Runtime Directory 
> > /run/user/0.
> >> >Aug 16 16:10:01 svcs systemd[1]: Starting User Manager for UID 0...
> >> >Aug 16 16:10:01 svcs systemd[80491]: Queued start job for default target 
> > Main User Target.
> >> >Aug 16 16:10:01 svcs systemd[80491]: Created slice User Application
> Slice.
> >> >Aug 16 16:10:01 svcs systemd[80491]: Condition check resulted in Mark boot
> 
> > as successful after the 
> >> user session has run 2 minutes being skipped.
> >> >Aug 16 16:10:01 svcs systemd[80491]: Started Daily Cleanup of User's 
> > Temporary Directories.
> >> >Aug 16 16:10:01 svcs systemd[80491]: Reached target Paths.
> >> >Aug 16 16:10:01 svcs systemd[80491]: Reached target Timers.
> >> >Aug 16 16:10:01 svcs systemd[80491]: Starting D‑Bus User Message Bus
> Socket.
> >> >Aug 16 16:10:01 svcs systemd[80491]: Condition check resulted in PipeWire
> 
> > PulseAudio being skipped.
> >> >Aug 16 16:10:01 svcs systemd[80491]: Listening on Multimedia System.
> >> >Aug 16 16:10:01 svcs systemd[80491]: Starting Create User's Volatile Files
> 
> > and Directories...
> >> >Aug 16 16:10:01 svcs systemd[80491]: Finished Create User's Volatile Files
> 
> > and Directories.
> >> >Aug 16 16:10:01 svcs systemd[80491]: Listening on D‑Bus User Message Bus 
> > Socket.
> >> >Aug 16 16:10:01 svcs systemd[80491]: Reached target Sockets.
> >> >Aug 16 16:10:01 svcs systemd[80491]: Reached target Basic System.
> >> >Aug 16 16:10:01 svcs systemd[80491]: Reached target Main User Target.
> >> >Aug 16 16:10:01 svcs systemd[80491]: Startup finished in 151ms.
> >> >Aug 16 16:10:01 svcs systemd[1]: Started User Manager for UID 0.
> >> >Aug 16 16:10:01 svcs systemd[1]: Started Session 72 of User root.
> >> >Aug 16 16:10:01 svcs root[80504]: ## logger output from cron script ##
> >> >Aug 16 16:10:01 svcs systemd[1]: session‑72.scope: Deactivated
> successfully.
> >> 
> >> I see these additional 23 lines (plus the one‑line script output) every
> >> time the script runs. That seems excessively verbose to me.
> >> 
> >> The system is Fedora 34 x86_64.
> > 
> > Cron jobs are run with pam_systemd, so they are run within a logind 
> > session. If there is no other sessions for root at that time, root's own 
> > systemd manager is started when the Cron job launches, and is stopped when 
> > the Cron job terminates. All of these log messages are related to this.
> > 
> > You may instead want to make root a lingering user:
> > 
> > loginctl enable‑linger root
> > 
> > This setting is persistent. You can use disable‑linger at a later time to 
> > turn it off if necessary.
> > 
> > With root configured as a lingering user, its systemd manager remains 
> > running all the time.
> 
> After reading the manual page I wonder: Is tha tsetting persistent, i.e.:
> Where is that setting stored?

Yes, it is persistent.

Lingering users are just represented as files under 
/var/lib/systemd/linger/ (though this is an implementation detail, of 
course).

Re: [systemd-devel] systemctl log verbosity

[Michael Chapman]

On Tue, 17 Aug 2021, Dave Close wrote:
> I'm trying to run "systemctl show" in a cron script. It works but I get
> a huge number of extra lines in my log for each run. Why? Can this be
> suppressed. I don't want to overfill the log.
> 
> There is nothing in the man page (that I noticed) indicating that "show"
> causes anything to be logged. But here's an example of what I see.
> 
> >Aug 16 16:10:01 svcs systemd[1]: Created slice User Slice of UID 0.
> >Aug 16 16:10:01 svcs systemd[1]: Starting User Runtime Directory 
> >/run/user/0...
> >Aug 16 16:10:01 svcs systemd[1]: Finished User Runtime Directory /run/user/0.
> >Aug 16 16:10:01 svcs systemd[1]: Starting User Manager for UID 0...
> >Aug 16 16:10:01 svcs systemd[80491]: Queued start job for default target 
> >Main User Target.
> >Aug 16 16:10:01 svcs systemd[80491]: Created slice User Application Slice.
> >Aug 16 16:10:01 svcs systemd[80491]: Condition check resulted in Mark boot 
> >as successful after the 
> user session has run 2 minutes being skipped.
> >Aug 16 16:10:01 svcs systemd[80491]: Started Daily Cleanup of User's 
> >Temporary Directories.
> >Aug 16 16:10:01 svcs systemd[80491]: Reached target Paths.
> >Aug 16 16:10:01 svcs systemd[80491]: Reached target Timers.
> >Aug 16 16:10:01 svcs systemd[80491]: Starting D-Bus User Message Bus Socket.
> >Aug 16 16:10:01 svcs systemd[80491]: Condition check resulted in PipeWire 
> >PulseAudio being skipped.
> >Aug 16 16:10:01 svcs systemd[80491]: Listening on Multimedia System.
> >Aug 16 16:10:01 svcs systemd[80491]: Starting Create User's Volatile Files 
> >and Directories...
> >Aug 16 16:10:01 svcs systemd[80491]: Finished Create User's Volatile Files 
> >and Directories.
> >Aug 16 16:10:01 svcs systemd[80491]: Listening on D-Bus User Message Bus 
> >Socket.
> >Aug 16 16:10:01 svcs systemd[80491]: Reached target Sockets.
> >Aug 16 16:10:01 svcs systemd[80491]: Reached target Basic System.
> >Aug 16 16:10:01 svcs systemd[80491]: Reached target Main User Target.
> >Aug 16 16:10:01 svcs systemd[80491]: Startup finished in 151ms.
> >Aug 16 16:10:01 svcs systemd[1]: Started User Manager for UID 0.
> >Aug 16 16:10:01 svcs systemd[1]: Started Session 72 of User root.
> >Aug 16 16:10:01 svcs root[80504]: ## logger output from cron script ##
> >Aug 16 16:10:01 svcs systemd[1]: session-72.scope: Deactivated successfully.
> 
> I see these additional 23 lines (plus the one-line script output) every
> time the script runs. That seems excessively verbose to me.
> 
> The system is Fedora 34 x86_64.

Cron jobs are run with pam_systemd, so they are run within a logind 
session. If there is no other sessions for root at that time, root's own 
systemd manager is started when the Cron job launches, and is stopped when 
the Cron job terminates. All of these log messages are related to this.

You may instead want to make root a lingering user:

loginctl enable-linger root

This setting is persistent. You can use disable-linger at a later time to 
turn it off if necessary.

With root configured as a lingering user, its systemd manager remains 
running all the time.

Re: [systemd-devel] Is `kernel-install` called automatically?

[Michael Chapman]

On Sat, 17 Jul 2021, Mike Beaton wrote:
> > I've managed to get it to be called
> automatically on both Fedora and CentOS/Rocky 8
> 
> Thank you. How? I'm not asking for excruciating detail, just roughly. Your
> own scripts, or something in the distribution?

On Fedora, the kernel-core RPM's %posttrans scriptlet calls kernel-install 
directly.

See for example:

  
https://src.fedoraproject.org/rpms/kernel/blob/7464e60427be7b6af8d65b8db72db1ef2bb28549/f/kernel.spec#_2608
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

[Michael Chapman]

On Fri, 12 Mar 2021, Ulrich Windl wrote:
[...]
> > Can you think of a better way of wording the documentation? 
> 
> It depends: Do you consider /dev/log to be a "syslog socket"?
> (I'm not running rsyslog there)

I'm not quite sure what you mean. If where you're going is "well 
*obviously* syslog.socket refers to /dev/log", then ... maybe that's true, 
but that ship has sailed. It simply doesn't, it means what it currently 
means: the socket by which journald sends messages to some other syslog 
daemon (if any).
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

[Michael Chapman]

On Fri, 12 Mar 2021, Ulrich Windl wrote:
> >>> Reindl Harald  schrieb am 11.03.2021 um 16:23 in
> Nachricht <4422087b-9966-e7fb-66ad-4157d83f2...@thelounge.net>:
> 
> > 
> > Am 11.03.21 um 12:17 schrieb Ulrich Windl:
> >> 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?
> >> 
> >> Manual says:
> >> syslog.socket
> >> The socket unit syslog implementations should listen on. All
> >> userspace log messages will be made available on this socket. 
> > For
> >> more information about syslog integration, please consult the
> >> Syslog Interface[2] document
> > 
> > you need no dependencies for logging ‑ journald is responsible for that 
> > and even available in the initrd
> 
> So journald is not listening to the syslog socket? So how are messages sent to
> the journal in a compatible way?
> At least the manual page for syslog.socket is confusing then.

So you say "the" syslog socket, but when you're running both journald and 
rsyslog, say, there are *two different syslog sockets*.

It looks something like this:

  app
   |
   V
/dev/log (systemd-journald-dev-log.socket)
   |
   V
journald
   |
   | if ForwardToSyslog=yes
   |
   V
/run/systemd/journal/syslog
   | (syslog.socket)
   |
   V
rsyslog  (syslog.service, symlinked to rsyslog.service)

In other words, applications that expect something at /dev/log will work 
normally. Their messages sent to this socket will be sent to the journal. 
If the journal is configured to "forward to syslog", the message will sent 
to /run/systemd/journal/syslog ... and this will socket-activate some 
syslog implementation, such as rsyslog.

I documentation for syslog.socket does essentially say this. The "syslog 
implementations" it's talking about means "rsyslog etc.", and "userspace 
log messages will be made available on this socket" means that the journal 
will send those messages to that socket. The linked Syslog Interface 
document also goes into more detail on it.

Can you think of a better way of wording the documentation? ___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Antw: Antw: Re: Re: Antw: [EXT] Re: Still confused with socket activation

[Michael Chapman]

On Tue, 9 Feb 2021, Ulrich Windl wrote:
[...]
> OK, I tried (staring libvirtd.service with --listen and without --timout):
> Feb 09 10:59:23 h18 libvirtd[42540]: --listen parameter not permitted with
> systemd activation sockets, see 'man libvirtd' for further guidance
> Feb 09 10:59:23 h18 systemd[1]: libvirtd.service: Main process exited,
> code=exited, status=6/NOTCONFIGURED
> Feb 09 10:59:23 h18 systemd[1]: Failed to start Virtualization daemon.

That must be because you're still passing through sockets from systemd.

When `libvirtd.service` is started, any active socket units with 
`Service=libvirtd.service` will be passed to the service. When libvirt is 
started with `--listen`, it checks that no sockets were passed to it.

If you don't want libvirt to be socket-activated, you have to make sure 
ALL of libvirt's sockets are stopped. Masking them is a good idea too, 
but stopping them is what's important.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Antw: Re: Antw: [EXT] Re: Still confused with socket activation

[Michael Chapman]

On Tue, 9 Feb 2021, Ulrich Windl wrote:
[...]
> > 
> > libvirt can be run without socket activation [2]. I strongly recommend you 
> > configure it this way if you intend to manage libvirt in Pacemaker.
> 
> Yes, I'd like to! Any pointers?

Follow the link. It's all described there.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Antw: Re: Antw: [EXT] Re: Still confused with socket activation

[Michael Chapman]

On Tue, 9 Feb 2021, Ulrich Windl wrote:
[...]
> At what timne exactly? When pacemaker starts, or when the systemd using is
> about to be started?

Pacemaker adds the drop-in just before it starts the resource, and it 
removes the drop-in just after it stops the resource. It's entire purpose 
is to handle the case when Pacemaker and the service are *simultaneously* 
stopped (i.e. by something external to Pacemaker).

Without the drop-in, what can happen is that the service is stopped before 
Pacemaker thinks it should be stopped... which makes Pacemaker attempt to 
recover the resource... which makes every go wrong quickly.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Antw: [EXT] Re: Still confused with socket activation

[Michael Chapman]

On Tue, 9 Feb 2021, Ulrich Windl wrote:
[...]
> As for the drop-ins: I neither know what those are expected to do, not who
> adds them at run time. See "documentation"...

The 50-pacemaker.conf drop-ins are, as their name suggests, created by 
Pacemaker.

Specifically, Pacemaker's systemd resource agent [1] creates a drop-in on 
each Pacemaker-managed systemd service. Consider the situation where both 
Pacemaker and the Pacemaker-managed service are scheduled to be stopped 
(e.g. you're rebooting the entire system). Either you want Pacemaker to 
stop the service itself (and, perhaps, start the service on some other 
node in your cluster), or -- if the pacemaker resource has management 
disabled -- you want the service to be stopped *after* Pacemaker has been 
stopped. Either way, the service needs to be ordered 
Before=pacemaker.service. This is precisely what that drop-in does.

Note that when you're using Pacemaker to manage a systemd service, you 
should not enable the service in the normal way -- that is, the service 
should not be started simply by virtue of it being in the Wants= list of 
multi-user.target. The service is intended to be started and stopped only 
by Pacemaker.

For more help on this drop-in in particular, I think you'd be better off 
contacting the Pacemaker developers.

[1] https://github.com/ClusterLabs/pacemaker/blob/master/lib/services/systemd.c
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Antw: [EXT] Re: Still confused with socket activation

[Michael Chapman]

On Tue, 9 Feb 2021, Michael Chapman wrote:
[...]
> Note that when you're using Pacemaker to manage a systemd service, you 
> should not enable the service in the normal way -- that is, the service 
> should not be started simply by virtue of it being in the Wants= list of 
> multi-user.target. The service is intended to be started and stopped only 
> by Pacemaker.

Ah, there's something else I forgot to mention.

Since Pacemaker is in charge of the service's lifecycle, you almost 
certainly *do not* want it to be socket-activated.

libvirt can be run without socket activation [2]. I strongly recommend you 
configure it this way if you intend to manage libvirt in Pacemaker.

(I think managing libvirt in Pacemaker is a mistake, mind you. Sure, 
manage individual libvirt *guests* in Pacemaker. But managing libvirt as a 
whole from Pacemaker seems to be the wrong approach.)

[2] https://libvirt.org/daemons.html
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] non-existent unit instances

[Michael Chapman]

On Sat, 5 Sep 2020, Richard Hector wrote:
> Hi all,
> 
> Quoting from another thread:
> 
> On 5/09/20 4:36 am, Lennart Poettering wrote:
> > Unit instances can be activated on-the-fly without further prepartion
> > or regsitration of the instance string or so. it's sufficient if the
> > template unit exists.
> 
> Is that preventable?
> 
> I have some instance names that are easily typoed. When I start one with
> the wrong name, it sticks around trying to restart for ever - or at
> least till I notice it or reboot - where I'm much rather get an error
> message and stop.
> 
> For reference, this is with the openvpn-client@ (and maybe
> openvpn-server@) units in Debian buster. Some of the content was
> modified/overwritten by me, so it could well be a bug introduced by me.

Since the instance name for this unit is used to derive a configuration 
filename, a simple solution here would be to use:

ConditionPathExists=/etc/openvpn/client/%i.conf

in the unit. Or, if you want the start job to fail when given a bad 
instance name:

AssertPathExists=/etc/openvpn/client/%i.conf

> The typos are because my instances are based on hostname, which can
> contain '-' but not '_'. Instance names can apparently not contain '-',
> so I have to use '_' instead, but my muscle memory for my hostnames is
> strong.

Instance names can contain hyphens, however depending on how they're used 
these hyphens will be translated into slashes. The %I specifier does this 
kind of translation, for instance.

This upstream OpenVPN units use %i when they reference configuration 
filenames, however, and this does not perform any translation on the 
instance name. I'm not sure why hyphens would cause problems for you.

> I don't know if this is a result of the way the units are written, or an
> inherent issue with systemd.
> 
> Cheers,
> Richard
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Ensuring that a unit starts before any networking

[Michael Chapman]

On Sat, 27 Jun 2020, Mark Rogers wrote:
> On Sat, 27 Jun 2020 at 11:06, Zbigniew Jędrzejewski-Szmek
>  wrote:
> > You should use Before=network-pre.target, Wants=network-pre.target.
> 
> Thanks, tried that but still not working:

It could very well be because of the dhcpcd.service you're using.

I don't know what it's like on Raspbian, but on Debian this unit appears 
to have no ordering with respect to network.target or network-pre.target 
at all.

On Fedora, this unit is Before=network.target, but it has no ordering with 
respect to network-pre.target. So even there this wouldn't help you.

In my experience a lot of network management software's systemd units 
don't use these target units properly.___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Failed to activate service 'org.freedesktop.systemd1': timed out

[Michael Chapman]

On Mon, 18 May 2020, Debraj Manna wrote:
> Around the same time I am seeing the below error in syslog
> 
> May 18 08:49:24 platform3 systemd[1]: Removed slice User Slice of support.
> May 18 08:49:27 platform3 systemd[1]: Assertion 's->type ==
> SERVICE_ONESHOT' failed at ../src/core/service.c:1792, function
> service_enter_start(). Aborting.
> May 18 08:49:27 platform3 systemd[1]: Caught , dumped core as pid 15839.
> May 18 08:49:27 platform3 systemd[1]: Freezing execution.

This bug (https://github.com/systemd/systemd/issues/) was fixed in 
systemd v236.

See if you can use a newer version of systemd.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd update "forgets" ordering for shutdown

[Michael Chapman]

On Sun, 17 May 2020, Andrei Borzenkov wrote:
> 17.05.2020 03:32, Michael Chapman пишет:
> > On Fri, 15 May 2020, Frank Steiner wrote:
> >> Hi,
> >>
> >> I need to run a script on shutdown before any other service is stopped.
> >> Due to an advice Lennart gave a while ago I'm using this service file
> >> (with multi-user.target being our default runlevel target):
> >>
> >> [Unit]
> >> After=multi-user.target
> >>
> >> [Service]
> >> Type=oneshot
> >> ExecStart=/bin/true
> >> ExecStop=/usr/lib/systemd/scripts/halt.local.bio
> >> TimeoutSec=120
> >> RemainAfterExit=yes
> > 
> > This seems inherently fragile.
> > 
> > If `multi-user.target` were to be stopped for whatever reason (and this 
> > is generally possible), the ordering dependencies between services 
> > Before=multi-user.target and services After=multi-user.target are broken. 
> 
> This is universally true. Do you have suggestion how it can be done
> differently?

Perhaps ordering dependencies should propagate through units even when 
they are not part of the transaction?

If we have A.service before B.service before C.service, we probably still 
want A.service before C.service even if B.service is not part of the 
transaction.

I must admit I haven't figured out the repercussions of this... but I'm 
pretty sure it's closer to how people *think* systemd's ordering 
dependencies work.

> Even if multi-user.target is manually stopped, there is no way normal
> service can be stopped concurrently with local filesystems, simply
> because normal service is always ordered After=basic.target. Unless of
> course we manually stop basic.target and sysinit.target as well :)

Well, that's actually my concern... there's really nothing preventing 
those targets from being "accidentally" stopped. That could happen at some 
point during the system's uptime, and utter chaos would ensue the next 
time the system was shutdown.
 
> I cannot reproduce it using trivial service definition on openSUSE Leap
> 15.1 which should have the same systemd as SLE 15 SP1. So possibilities are
> 
> 1. Something in unit definition triggers some bug in systemd. In this
> case exact full unit definition is needed. Also shutdown log with debug
> log level will certainly be useful.
> 
> 2. ExecStop command is not synchronous, it forks and continues in
> background. In this case probably systemd assumes unit is stopped and
> continues. Again, log with debug log level would confirm it.

I agree, we do need to find out exactly what happened with Frank's system. 
There's clearly something more to it if his service is surviving 
local-fs.target being stopped.___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd update "forgets" ordering for shutdown

[Michael Chapman]

On Sun, 17 May 2020, Michael Chapman wrote:
> On Fri, 15 May 2020, Frank Steiner wrote:
> > Hi,
> > 
> > I need to run a script on shutdown before any other service is stopped.
> > Due to an advice Lennart gave a while ago I'm using this service file
> > (with multi-user.target being our default runlevel target):
> > 
> > [Unit]
> > After=multi-user.target
> > 
> > [Service]
> > Type=oneshot
> > ExecStart=/bin/true
> > ExecStop=/usr/lib/systemd/scripts/halt.local.bio
> > TimeoutSec=120
> > RemainAfterExit=yes
> 
> This seems inherently fragile.
> 
> If `multi-user.target` were to be stopped for whatever reason (and this 
> is generally possible), the ordering dependencies between services 
> Before=multi-user.target and services After=multi-user.target are broken. 
> This is because no stop job for `multi-user.target` will be added to 
> systemd's transaction (it's already stopped!), and ordering dependencies 
> only apply to units actually added to the transaction.

A quick test can demonstrate this.

First, let's set up a few test units:

$ systemctl --user cat test-a.service test-b.service start-tests.target 
stop-tests.target
# /home/mchapman/.config/systemd/user/test-a.service
[Unit]
Conflicts=stop-tests.target

[Service]
ExecStart=/bin/echo start a
ExecStop=/bin/echo stop a
RemainAfterExit=true

[Install]
WantedBy=start-tests.target

# /home/mchapman/.config/systemd/user/test-b.service
[Unit]
Conflicts=stop-tests.target
After=start-tests.target

[Service]
ExecStart=/bin/echo start b
ExecStop=/bin/echo stop b
RemainAfterExit=true

[Install]
WantedBy=start-tests.target

# /home/mchapman/.config/systemd/user/start-tests.target
[Unit]
Conflicts=stop-tests.target

# /home/mchapman/.config/systemd/user/stop-tests.target
[Unit]
Conflicts=start-tests.target

The idea here is that `start-tests.target` is like `multi-user.target`, 
and `stop-tests.target` is like `shutdown.target` (or one of the other 
targets normally used during shutdown).

`test-a.service` is ordered before `start-tests.target`, but 
`test-b.service` is ordered after it.

Next we enable `test-a.service` and `test-b.service`:

$ systemctl --user enable test-a.service test-b.service
Created symlink 
/home/mchapman/.config/systemd/user/start-tests.target.wants/test-a.service -> 
/home/mchapman/.config/systemd/user/test-a.service.
Created symlink 
/home/mchapman/.config/systemd/user/start-tests.target.wants/test-b.service -> 
/home/mchapman/.config/systemd/user/test-b.service.

With this in place, both simulated "boot" and "shutdown" work correctly. 
Simulating boot:

$ systemctl --user start start-tests.target
$ journalctl --user
May 17 11:01:07 beren.home systemd[2186]: Started test-a.service.
May 17 11:01:07 beren.home systemd[2186]: Reached target start-tests.target.
May 17 11:01:07 beren.home echo[983330]: start a
May 17 11:01:07 beren.home systemd[2186]: Started test-b.service.
May 17 11:01:07 beren.home echo[983331]: start b

Simulating shutdown:

$ systemctl --user start stop-tests.target
$ journalctl --user
May 17 11:01:11 beren.home systemd[2186]: Reached target stop-tests.target.
May 17 11:01:11 beren.home systemd[2186]: Stopping test-b.service...
May 17 11:01:11 beren.home systemd[2186]: test-b.service: Succeeded.
May 17 11:01:13 beren.home echo[983355]: stop b
May 17 11:01:11 beren.home systemd[2186]: Stopped test-b.service.
May 17 11:01:13 beren.home echo[983359]: stop a
May 17 11:01:11 beren.home systemd[2186]: Stopped target start-tests.target.
May 17 11:01:11 beren.home systemd[2186]: Stopping test-a.service...
May 17 11:01:11 beren.home systemd[2186]: test-a.service: Succeeded.
May 17 11:01:11 beren.home systemd[2186]: Stopped test-a.service.

But what happens if we were to stop `start-tests.target` in the middle of 
this?

$ systemctl --user start start-tests.target
$ journalctl --user
May 17 11:01:23 beren.home systemd[2186]: Stopped target stop-tests.target.
May 17 11:01:23 beren.home systemd[2186]: Started test-a.service.
May 17 11:01:23 beren.home systemd[2186]: Reached target start-tests.target.
May 17 11:01:23 beren.home echo[983369]: start a
May 17 11:01:23 beren.home systemd[2186]: Started test-b.service.
May 17 11:01:23 beren.home echo[983370]: start b
May 17 11:01:28 beren.home systemd[2186]: Stopped target start-tests.target.

$ systemctl --user stop start-tests.target
$ journalctl --user
May 17 11:01:28 beren.home systemd[2186]: Stopped target start-tests.target.

$ systemctl --user start stop-tests.target
$ journalctl --user
May 17 11:01:34 beren.home systemd[2186]: Reached target stop-tests.target.
May 17 11:01:34

Re: [systemd-devel] systemd update "forgets" ordering for shutdown

[Michael Chapman]

On Fri, 15 May 2020, Frank Steiner wrote:
> Hi,
> 
> I need to run a script on shutdown before any other service is stopped.
> Due to an advice Lennart gave a while ago I'm using this service file
> (with multi-user.target being our default runlevel target):
> 
> [Unit]
> After=multi-user.target
> 
> [Service]
> Type=oneshot
> ExecStart=/bin/true
> ExecStop=/usr/lib/systemd/scripts/halt.local.bio
> TimeoutSec=120
> RemainAfterExit=yes

This seems inherently fragile.

If `multi-user.target` were to be stopped for whatever reason (and this 
is generally possible), the ordering dependencies between services 
Before=multi-user.target and services After=multi-user.target are broken. 
This is because no stop job for `multi-user.target` will be added to 
systemd's transaction (it's already stopped!), and ordering dependencies 
only apply to units actually added to the transaction.

I saw that you noted that the problem started after `systemctl 
daemon-reload`. Perhaps you could check whether `multi-user.target` is 
still active after this?

(Thinking about this some more, this seems like an inherent design flaw 
with the way all of the systemd's standard targets work. Perhaps these 
ought to use RefuseManualStop=true? Perhaps this should even be the 
default?)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Using *.path units without races?

[Michael Chapman]

On Fri, 20 Mar 2020, Uwe Geuder wrote:
[...]
> > PathChanged= and PathModified= each map down to a set of inotify
> > events. It's the kernel's inotify system that determines whether the
> > file changed or modified, not systemd.
> 
> My understanding is that since
> https://github.com/systemd/systemd/pull/13509/commits/06582e42de65a61d0238a18720a12b6353edb7cd
> there are 2 states
> 
> 1. While the path unit is waiting and the triggered service unit is dead
> its indead all inotify's business. When a change happens the kernel will
> notify systemd.
> 
> 2. However, while the triggered service unit is running also the path
> unit is running and the inotify fd is closed. So the kernel will not
> report any changes to systemd at all during that time.

Yes, I agree, this does seem like a regression to me.

I'm actually a bit lost with all the changes that have happened to path 
units over the last year. It looks like this issue:

  https://github.com/systemd/systemd/issues/12801

is significant, since the reporter had a similar problem to the one you 
had: that is, a file created while the triggered service was active would 
not be picked up by PathExists=.

But that issue was closed with a commit that fixed a side-issue -- that 
reloading or restarting the daemon would cause the service to be triggered 
-- and not the issue that the reporter had!

And worse yet, I'm not even sure that side-issue is actually an issue. If 
these predicates are supposed to be level-triggered, and the predicate 
passes (e.g. the monitored path exist), then it shouldn't matter whether 
daemon-reload causes a retrigger, since the retriggered unit should 
already be active. "Retriggering" it would be a no-op.

So... yeah, I'm really confused too.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Using *.path units without races?

[Michael Chapman]

On Fri, 20 Mar 2020, Uwe Geuder wrote:
[...]
> The manual page is not very specific about how that is supposed to work
> IMHO, but I could imagine the following distinction:
> 
> PathExists=, PathExistsGlob=, and DirectoryNotEmpty= are absolute
> predicates. When setting the path unit to waiting one can just check
> whether they are true or not. (After arming inotify of course.) With
> your patch my limited testing was successful.
> 
> However, PathChanged= and PathModified= are relative predicates. You
> cannot just check whether they are true or not. Wouldn't the correct
> implementation
> 
> 1. need to store the applicable timestamp of the path involved when the
>path unit is set to started and
> 
> 2. when the path unit is set to waiting again it would need to compare
>the stored timestamp with the current timestamp (again after arming
>inotify) to catch modifications that happened while the unit was
>running/inotify not armed
> 
> I don't think I see the timestamps stored at all. So how was this
> supposed to work? Was the intended semantics different?

PathChanged= and PathModified= each map down to a set of inotify 
events. It's the kernel's inotify system that determines whether the 
file changed or modified, not systemd.

For example, consider the IN_MODIFY event. This is the only event that 
distinguishes PathModified= from PathChanged=. inotify generates this 
event on any kind of "data write" operation to the file.

See the inotify(7) manpage for details.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Using *.path units without races?

[Michael Chapman]

On Wed, 18 Mar 2020, Uwe Geuder wrote:
> Hi!
> 
> I have wondered for a while how I can use *.path units without (too bad)
> races.
> 
> Since
> https://github.com/systemd/systemd/pull/13509/commits/06582e42de65a61d0238a18720a12b6353edb7cd
> the behaviour has been become much clearer, but I must admit I still
> don't get it.

That commit does look incomplete to me.

As a quick test, are you able to try out the patch below? This makes 
systemd always check the filesystem when the service stops, rather than 
just relying on the (as of that commit nonexistent) inotify event.

(This change would mean the third argument to path_enter_waiting() is 
always true, so the code can be further simplified afterwards. The big 
comment in path_dispatch_io() should probably also be changed.)


diff --git a/src/core/path.c b/src/core/path.c
index cb75d778af..a513df97b2 100644
--- a/src/core/path.c
+++ b/src/core/path.c
@@ -759,11 +759,7 @@ static void path_trigger_notify(Unit *u, Unit *other) 
{
 if (p->state == PATH_RUNNING &&
 UNIT_IS_INACTIVE_OR_FAILED(unit_active_state(other))) {
 log_unit_debug(UNIT(p), "Got notified about unit 
deactivation.");
-
-/* Hmm, so inotify was triggered since the
- * last activation, so I guess we need to
- * recheck what is going on. */
-path_enter_waiting(p, false, p->inotify_triggered);
+path_enter_waiting(p, false, true);
 }
 }
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

[Michael Chapman]

On Thu, 12 Mar 2020, Jędrzej Dudkiewicz wrote:
[...]
> And one more question: what is systemd-timedated? It seems that is
> exactly same thing, but I don't think this is true?

It's the DBus service that most bits of timedatectl talk to. timedatectl 
doesn't modify system configuration directly. When you run `timedatectl 
set-time ...`, for instance, it's actually systemd-timedated that changes 
the system's time.

There's a bunch of reasons for this split: privilege separation is a good 
idea in general; the privileged service can choose whether to perform or 
deny a request according to the system's polkit configuration; other 
non-timedatectl clients can have equal programmatic access to the same 
time-and-date settings.

systemd-timedated doesn't actually have any relationship with 
systemd-timesyncd, despite the similar name.___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

[Michael Chapman]

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

This seems like a reasonably good idea to me, so long as it's behind an 
option (so systemctl remains silent on success by default).

Perhaps open an RFE on GitHub? I can't see anything like this there yet.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] disable "InaccessiblePaths" with a dropin

[Michael Chapman]

On Thu, 9 Jan 2020, Reindl Harald wrote:
> Hi
> 
> deployed http.service contains:
> 
>  * InaccessiblePaths=-/usr/bin/bash
>  * InaccessiblePaths=-/usr/bin/dash
>  * InaccessiblePaths=-/usr/bin/sh
> 
> now there is one instance where passthru() in a php script is desired
> 
> /etc/systemd/system/http.service/allow-paths.conf:
> ReadOnlyPaths=-/usr/bin/bash
> ReadOnlyPaths=-/usr/bin/dash
> ReadOnlyPaths=-/usr/bin/sh
> 
> that don't work - is there a way to disable specific "InaccessiblePaths"
> from the main unit with a dropin other then clone the whole httpd.service?

An empty:

InaccessiblePaths=

in the drop-in should do it. In general "list-valued" directives are 
emptied with a blank value.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Portable service and bind paths

[Michael Chapman]

On Mon, 6 Jan 2020, Claes H wrote:
> Turns out the problem was not with the mount - that was working well.
> Instead it was a user problem and I did not realize the process ran as
> root and used a different home directory.
> When I added the user homeassistant in the host and added it to the
> User= configuration in the service file it worked
> But this required the "admin" of the host to do something additional,
> it did not work "out of the box".
> 
> I was thinking  - how is it supposed to work with a portable service,
> which user is it recommended to run as?
> Maybe portablectl attach should create the user the service has
> declared, if it does not exist already?
> Or should is there be a general user that portable services to run as?
> Interested to hear if there is any recommendation for how a portable
> service "packager" should define the user aspect of the service
> 
> Best regards
> Claes

This seems like an ideal use-case for DynamicUser=. Don't specify any 
User= or Group= directly; just let systemd allocate them automatically.

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

Re: [systemd-devel] How to execute Shell before rootfs mount on centos7

[Michael Chapman]

On Sat, 30 Nov 2019, Ankele zhang wrote:
> Hello All:
> How to execute shell before rootfs mounted on CentOS7.
> On CentOS6, we can modify init shell in initramfs.img to do something
> we need. But on CentOS7 my beloved init has be changed to systemd and
> systemd has no shell script.

CentOS 7 uses Dracut [1] for its initramfs. With Dracut, you can use 
`rd.break=mount` to the kernel command-line to instruct Dracut to launch a 
shell just before it mounts the new root filesystem.

See the dracut.cmdline(7) manpage [2] for further details.

[1] https://dracut.wiki.kernel.org/
[2] http://man7.org/linux/man-pages/man7/dracut.cmdline.7.html
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Make systemd-localed modify the kernel commandline for the initrd keymap?

[Michael Chapman]

On Thu, 26 Sep 2019, Hans de Goede wrote:
> Hi,
> 
> On 26-09-2019 11:10, Michael Chapman wrote:
> > On Thu, 26 Sep 2019, Hans de Goede wrote:
> > [...]
> >> I believe that the best alternative is to have localed append / update
> >> a rd.vconsole.keymap=foo argument to the kernel commandline, to override
> >> the vconsole.conf KEYMAP setting, but only in the initrd (so that later
> >> runtime changes when booted still work).
> >>
> >> The way I see this working is that localed does a read-modify-write of
> >> all the BLS .conf files under /boot/loader/entries and updates their
> >> "options" line to have rd.vconsole.keymap=foo appended or updated if
> >> already present.
> > 
> > To be honest, I really do think having the initrd rebuilt completely is a
> > better approach... but I do not think localed should be directly
> > responsible for that.
> 
> As I already mentioned there are 2 issues with rebuilding the initrd:
> 
> 1) It might break booting the system and, assuming we rebuild the initrd
> for all installed kernels on a locale change, then their will not be
> an older one to fallback to as there normally is, which is BAD.
> 
> 2) We are moving (and in case of rpmostree based distros already shipping)
> to pre-generated (on the distros buildsys) initrds, which likely will
> also be signed.
> 
> How do you propose to solve these 2 issues?

Hmm, these are good points. I do like the idea of using a 
locally-generated overlay initrd though.
 
> > There are a lot of reasons the initrd needs to be rebuilt. Changing the
> > system locale is just one of them. It seems unreasonable to have every
> > tool know how to append boot parameters.
> 
> Actually there are not that many reasons, Note that all other config info
> needed for the initrd, like the rootfs UUID, which raid/lvm members to
> assemble, etc. is already on the kernel commandline, so it seems logical
> to put the locale (which is config info) there too and pre systemd at least
> Fedora was already doing this.

Perhaps I've been overly eager to rebuild the initrd on my systems when 
changing files under /etc. I think that's because I've seen just how much 
Dracut copies into the initrd, and I always get the feeling that if I 
forget to rebuild it something will break on the next reboot...

Just to pick an example, I was fiddling around with /etc/udev/rules.d 
files a little while ago. I just assumed I'd need to rebuild the initrd 
for those.

Perhaps a more common example is /etc/crypttab. That certainly needs to be 
in the initrd if the root filesystem is encrypted.

So I guess I'm already in the habit of rebuilding the initrd when 
modifying config in /etc that might be needed on boot, and changing the 
locale wouldn't be any different.
 
> > I would be a lot happier seeing a "well-known" binary that various things
> > can call to rebuild the initrd, somewhat akin to the kernel-install we
> > have already. That way distributions can plug in whatever tooling they use
> > for initrds (e.g. dracut, initramfs-tools, ...)
> 
> So maybe we need a well-known binary to update the kernel-commandline ?

I think that would be useful just generally.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Make systemd-localed modify the kernel commandline for the initrd keymap?

[Michael Chapman]

On Thu, 26 Sep 2019, Hans de Goede wrote:
[...]
> I believe that the best alternative is to have localed append / update
> a rd.vconsole.keymap=foo argument to the kernel commandline, to override
> the vconsole.conf KEYMAP setting, but only in the initrd (so that later
> runtime changes when booted still work).
> 
> The way I see this working is that localed does a read-modify-write of
> all the BLS .conf files under /boot/loader/entries and updates their
> "options" line to have rd.vconsole.keymap=foo appended or updated if
> already present.

To be honest, I really do think having the initrd rebuilt completely is a 
better approach... but I do not think localed should be directly 
responsible for that.

There are a lot of reasons the initrd needs to be rebuilt. Changing the 
system locale is just one of them. It seems unreasonable to have every 
tool know how to append boot parameters.

I would be a lot happier seeing a "well-known" binary that various things 
can call to rebuild the initrd, somewhat akin to the kernel-install we 
have already. That way distributions can plug in whatever tooling they use 
for initrds (e.g. dracut, initramfs-tools, ...)

Perhaps even just a new kernel-install verb, e.g:

   kernel-install refresh KERNEL-VERSION [KERNEL-IMAGE]

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

Re: [systemd-devel] Unload disabled units

[Michael Chapman]

On Sun, 15 Sep 2019, Daniel Duong wrote:
> Hi,
> 
> I have a 2 template units: 1 for a service and 1 for a socket. Each
> instance is a version of my web application.
> 
> After a successful deploy, I stop and disable the old version and I
> enable the new one:
>   systemctl start belleshop@0.2.socket
>   # Test that everything is fine
>   systemctl enable belleshop@0.2.socket
>   systemctl stop belleshop@0.1.socket
>   systemctl stop belleshop@0.1.service
>   systemctl disable belleshop@0.1.socket
> 
> I've done that for a few versions now, and it seemed to work OK. There
> is a little problem though. The old versions are still loaded:
> 
>   $ systemctl --no-legend --all list-units belleshop@*
>   belleshop@0.110.service loaded active   running Belleshop server
>   belleshop@0.34.service  loaded inactive deadBelleshop server
>   belleshop@0.36.service  loaded inactive deadBelleshop server
>   belleshop@0.37.service  loaded inactive deadBelleshop server
>   [...]
>   belleshop@0.110.socket  loaded active   running Belleshop socket
>   belleshop@0.34.socket   loaded inactive deadBelleshop socket
>   belleshop@0.36.socket   loaded inactive deadBelleshop socket
>   belleshop@0.37.socket   loaded inactive deadBelleshop socket
>   [...]
> 
> Is there any way I can unload these old versions?

You should check to see if anything is actually still referencing these 
units. Try `systemd-analyze dump` and see if any "ReferencedBy" entries 
appear for these units.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Unload disabled units

[Michael Chapman]

On Mon, 16 Sep 2019, Reindl Harald wrote:
> Am 16.09.19 um 09:36 schrieb Zbigniew Jędrzejewski-Szmek:
> > Normally units should be unloaded immediately if they are stopped
> > and didn't fail. What systemd version are you using?
> 
> the better question is which one are you using because this behavior
> below exists for many years and it's good given that you normally want
> the journald output
> 
> [root@srv-rhsoft:~]$ systemctl status vnc
> ● vnc.service - VNC Server
>Loaded: loaded (/etc/systemd/system/vnc.service; disabled; vendor
> preset: disabled)
>Active: inactive (dead)
> 
> Sep 16 11:15:24 srv-rhsoft.rhsoft.net systemd[1]: Started VNC Server.
> Sep 16 11:15:28 srv-rhsoft.rhsoft.net systemd[1]: Stopping VNC Server...
> Sep 16 11:15:28 srv-rhsoft.rhsoft.net systemd[1]: vnc.service: Succeeded.
> Sep 16 11:15:28 srv-rhsoft.rhsoft.net systemd[1]: Stopped VNC Server.
> 
> [root@srv-rhsoft:~]$ rpm -q systemd
> systemd-241-12.git1e19bcd.fc30.x86_64

This unit probably is being unloaded when you're not looking at it. Using 
`systemctl status` on it will force it to be loaded (possibly only 
temporarily). The unit does not need to remain loaded to be able to view 
its journal logs.___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd243rc2, sysd-coredump is not triggered on segfaults

[Michael Chapman]

On Tue, 3 Sep 2019, Chris Murphy wrote:
> Maybe it's something unique to gnome-shell segfaults, that's the only
> thing I have crashing right now. But I've got a pretty good reproducer
> to get it to crash and I never have any listings with coredumpctl.
> 
> process segfaults but systemd-coredump does not capture it
> https://bugzilla.redhat.com/show_bug.cgi?id=1748145

GNOME shell appears to handle several normally-fatal signals, including 
SIGSEGV.

If I'm reading [1] correctly GNOME shell ignores all signals, dumps the 
GJS stack, and re-raises the signal. This will not work correctly for a 
user-generated SIGSEGV however... the signal generated by raise() will 
just get ignored. (If the kernel generates SIGSEGV it arranges things so 
the process is terminated even if SIGSEGV is ignored, I think.)

So I think this might be a GNOME shell bug.

[1] https://gitlab.gnome.org/GNOME/gnome-shell/blob/master/src/main.c#L366-403
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] /etc/fstab dependences migrated between units due to automount feature

[Michael Chapman]

On Sat, 31 Aug 2019, Daniel Otero Oubiña wrote:
> I forgot to say that the devices on crypttab are also configured with
> `noauto`, that's why I was adding the dependences manually.

Even with `noauto`, the manual dependency isn't needed. The dependencies I 
described were all about the block device, not the filesystem, so when the 
filesystem is actually mounted isn't relevant.

> The strange behavior for me is that, if I do not put the `x-systemd.automount`
> everything works fine: the devices are not decrypted until I try to mount
> the final filesystem. But when I add the automount feature, the devices get
> automatically decrypted at boot, because the dependencies are moved from
> the .mount to the .automount.
> 
> This can be solved manually with custom units, but I would like to know if
> there is an explanation for this behavior.

When these fstab options were added, the use case that originally brought 
them up was dependencies between mount units:

  https://bugzilla.redhat.com/show_bug.cgi?id=812826
  https://bugzilla.redhat.com/show_bug.cgi?id=1164334
  
https://github.com/systemd/systemd/commit/3519d230c8bafe834b2dac26ace49fcfba139823
  

If a particular fstab entry has both x-systemd.automount and 
x-systemd.requires=something.mount, then the Requires= dependency would 
have to be applied on the corresponding automount unit.

So I'm not sure how systemd can cater for your request. It would be weird 
for dependencies on only _some_ unit types to be transferred from the 
mount unit to the automount unit.

But really, I keep reiterating: you don't need this explicit cryptsetup 
dependency at all. Do you have some use case where it's actually needed?___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] /etc/fstab dependences migrated between units due to automount feature

[Michael Chapman]

On Fri, 30 Aug 2019, Daniel Otero Oubiña wrote:
> Hi all!
> 
> I have found a somehow strange systemd "feature" that I'm not sure if it's
> a bug. Let me know if you prefer having this reported on GitHub instead.
> 
> First, let me explain my setup: I have a data filesystem that is split in
> two encrypted partitions (with LUKS) formated as a single btrfs raid1
> filesystem.
> I manage to make everything work just modifying fstab and crypttab.
> 
> The problem arises when I try to make the data partition mounted on demand
> (`x-systemd.automount`). That's because it makes my "decrypted partitions"
> dependences (declared with `systemd.requires=systemd-cryptsetup@xxx.service`)
> move from the .mount autogenerated unit to the .automount one. This causes
> the partitions to be decrypted even if the data filesystem is never used,
> because the .automount unit is activated on boot. Is there a reasoning for
> this behavior or I'm missing something?
> 
> Here is a link with the autogenerated units with and without the automount
> option:
>  https://pastebin.com/RkdHFt59

First, I don't think you should specify 
x-systemd.requires=systemd-cryptsetup@xxx.service explicitly.

systemd's cryptsetup-generator ensures that cryptsetup.target has 
Wants=systemd-cryptsetup@xxx.service, and systemd-cryptsetup@xxx.service 
has BindsTo=dev-yyy.device according to the contents of your crypttab 
file.

The end result is cryptsetup should be performed when the device is 
detected, not necessarily when any filesystem on it is mounted. That is 
the behaviour you're seeing already, but without any need for explicit 
dependencies.

As for whether this behaviour is intended, I would say it is. An encrypted 
block device might be used for something other than a mountable 
filesystem. You might have LVM on it, for instance.___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Antw: Re: help: unmounting iscsi xfs filesystem without using netdev in /etc/fstab

[Michael Chapman]

On Tue, 27 Aug 2019, Ulrich Windl wrote:
[...]
> > If you're not using the _netdev keyword, and systemd does not otherwise 
> > think this is a remote filesystem, you will need to add this dependency 
> > manually. You'll probably also want:
> > 
> > Wants=network‑online.target
> > After=network‑online.target
> 
> I wonder: Shouldn't that be remote-fs-pre.target?
> For example if the NFS client starts AFTER the network target is done, the
> remote filesystem will start concurrently. In most cases it may work well, but
> in general it won't.

Yes, I should have added After=remote-fs-pre.target to this message. It is 
in the code as well (replacing After=local-fs-pre.target used on 
non-_netdev mounts).

Note that mount units do *not* have a default Wants=remote-fs-pre.target 
or Wants=local-fs-pre.target though. These targets are not automatically 
added to the transaction. They are only added if something *else* pulls 
them in (e.g. for iSCSI you would typically have an iscsi.service with 
Before=remote-fs-pre.target and Wants=remote-fs-pre.target).___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] help: unmounting iscsi xfs filesystem without using netdev in /etc/fstab

[Michael Chapman]

On Tue, 27 Aug 2019, Tony Rodriguez wrote:
> Managed to detect/mount iscsi devices without using _netdev keyword in
> /etc/fstab.  Made changes within src/fstab-generator/ftstab-generator.c and it
> seems to work.  The only problem is during shutdown/reboot, my iscsi xfs
> filesystem does not unmount cleanly before the network/iscs service/system is
> shutdown.  When this happens I receive a xfs error/warning.
> 
> However this doesn't happen when _netdev is specified in /etc/fstab for my
> iscsi device.  Seems _netdev handles management of mounts/unmounts before
> killing things off.  How exactly does _netdev manage unmounting filesystems
> during a shutdown/reboot?

One of the "default dependencies" for a mount unit that systemd thinks is 
a network filesystem is After=network.target. During shutdown, this 
ensures the filesystem is unmounted before networking is brought down:


https://github.com/systemd/systemd/blob/fef40ceb5dfbb76d4733e579846a380a224efd55/src/core/mount.c#L455-L482

If you're not using the _netdev keyword, and systemd does not otherwise 
think this is a remote filesystem, you will need to add this dependency 
manually. You'll probably also want:

Wants=network-online.target
After=network-online.target

to match the code linked above.

>   I would like to invoke that same netdev unmount
> code/logic myself from within systemd source but without using the _netdev
> keyword. Unfortunately it is a requirement to not use _netdev within
> /etc/fstab for iscsi.  Seems _netdev takes a long time to timeout and continue
> when unable to mount.

I haven't been following your earlier threads too closely, but if you're 
stuck with stupid fstab requirements why not just bypass them with 
altogether with drop-in:

# path-to-mountpoint.mount.d/20-Options.conf
[Mount]
Options=_netdev

Plus any other options you may need, of course; this directive is not 
"list-valued", so you can't use it to add just one option.

> Checked src/core/mount.c and src/core/unmount.c but not sure what to do to
> duplicate how _netdev manages unmounting before the system is shutdown or
> rebooted.  Do I need a special before and after keyword in /etc/fstab so my
> xfs filesystems is unmounted before shutting down the iscsi
> service/network/system?  If so, will such keywords also propagate to
> /run/systemd/generator/remote-fs-target.requires?
> 
> 
> Thanks,
> Tony
> ___
> 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's connections to /run/systemd/private ?

[Michael Chapman]

On Fri, 16 Aug 2019, Uoti Urpala wrote:
> On Thu, 2019-08-15 at 20:36 +1000, Michael Chapman wrote:
> > With systemd 239 I was unable to cause an fd leak this way.
> > 
> > Still, I would feel more comfortable if I could find a commit that 
> > definitely fixed the problem. All of these experiments are just 
> > circumstantial evidence.
> 
> 5ae37ad833583e6c1c7765767b7f8360afca3b07
> sd-bus: when attached to an sd-event loop, disconnect on processing errors

Ah, nice. So since systemd v237.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd's connections to /run/systemd/private ?

[Michael Chapman]

On Thu, 15 Aug 2019, Lennart Poettering wrote:
> On Mi, 14.08.19 22:36, Michael Chapman (m...@very.puzzling.org) wrote:
> 
> > On Wed, 14 Aug 2019, Lennart Poettering wrote:
> > > Well, a D-Bus connection can remain open indefinitely, and may even
> > > have incomplete "half" messages queued in them as long as the client
> > > desires. After the initial authentication is done, clients may thus
> > > take up resources as long as they want, this is by design of dbus
> > > really, and is different from HTTP for example, where connections
> > > usually have a time-out applied. dbus doesn't know timeouts for
> > > established connections. It knows them for the authentication phase,
> > > and it knows them for method calls that are flight, but it does not
> > > know them for the mere existance of an established connection.
> >
> > I'm sure it's not in the design of DBus that clients can continue to
> > consume those resources after they've disconnected.
> >
> > > PID 1 authenticates clients of the private connection simply by making
> > > the socket for it inaccessible to anyone who is not privileged. Due to
> > > that it gets away with not doing any further per-user accounting,
> > > because it knows the clients are all privileged anyway.
> > >
> > > So, yes, it would be good if we could protect us from any form of
> > > misuse, but basically, if you have a root client that misbehaves you
> > > have too accept that...
> >
> > I understand all that. Nevertheless, Brian identified a bug: after
> > receiving certain data on its private socket, the systemd process can leak
> > a file descriptor.
> 
> Can it? Did I miss something? If the client closes the client side of
> the socket, but PID 1 would keep the server side of it open anyway,
> then that would be a bug indeed. But my understanding was that the
> client side stays pinned?

I was able to reproduce the bug on CentOS 7's systemd 219. That is, the 
file descriptor in PID 1 was dropped from its epoll set without it 
reaching EOF and without it being closed. Every time I ran Brian's command 
PID 1 would leak another file descriptor.

I was unable to reproduce this on a later version of systemd, but that 
_could_ just be because this later version of systemd side-steps the issue 
by ensuring that systemctl doesn't use fd 1 for its socket.

I have some reason to believe the problem in PID 1 has been fixed though. 
On CentOS 7 I was able to cause it to sometimes leak an fd simply by 
sending random data to it:

  # count-sockets() { ss -x | grep /run/systemd/private | wc -l; }
  # inject-junk() { timeout 1s nc -U /run/systemd/private https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd's connections to /run/systemd/private ?

[Michael Chapman]

On Wed, 14 Aug 2019, Lennart Poettering wrote:
> Well, a D-Bus connection can remain open indefinitely, and may even
> have incomplete "half" messages queued in them as long as the client
> desires. After the initial authentication is done, clients may thus
> take up resources as long as they want, this is by design of dbus
> really, and is different from HTTP for example, where connections
> usually have a time-out applied. dbus doesn't know timeouts for
> established connections. It knows them for the authentication phase,
> and it knows them for method calls that are flight, but it does not
> know them for the mere existance of an established connection.

I'm sure it's not in the design of DBus that clients can continue to 
consume those resources after they've disconnected.

> PID 1 authenticates clients of the private connection simply by making
> the socket for it inaccessible to anyone who is not privileged. Due to
> that it gets away with not doing any further per-user accounting,
> because it knows the clients are all privileged anyway.
> 
> So, yes, it would be good if we could protect us from any form of
> misuse, but basically, if you have a root client that misbehaves you
> have too accept that...

I understand all that. Nevertheless, Brian identified a bug: after 
receiving certain data on its private socket, the systemd process can leak 
a file descriptor.

All we need to establish is whether that bug still exists in the current 
version of systemd. _Even if_ it isn't a security issue, having one fewer 
bugs is a good thing.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Antw: Re: systemd's connections to /run/systemd/private ?

[Michael Chapman]

On Wed, 14 Aug 2019, Reindl Harald wrote:
> Am 14.08.19 um 12:41 schrieb Michael Chapman:
> > On Wed, 14 Aug 2019, Reindl Harald wrote:
> >> Am 14.08.19 um 12:10 schrieb Ulrich Windl:
> >>>>>> Michael Chapman  schrieb am 14.08.2019 um 
> >>>>>> 11:47 in
> >>>> That's all true, but the thing we need to check here is that systemd 
> >>>> correctly handles junk on the /run/systemd/private socket. The change on 
> >>>> the systemctl side certainly tries to prevent incorrect data being sent 
> >>>> down the socket -- though it looks like there's several ways in which 
> >>>> fd_move_above_stdio() can fail, so this isn't foolproof -- but we need 
> >>>> to 
> >>>> ensure that some _malicious_ client can't DoS systemd.
> >>>
> >>> I don't want to contradict in principle, but doesn't "private socket" 
> >>> mean it's intended to be used by systemd only? Of course being root 
> >>> allows you to use any socket...
> >>
> >> may is ask you to read the thread you are responding to?
> >> nobody is touching the private socket
> > 
> > systemctl will mostly use /run/systemd/private when run as root
> 
> that's not the point - the point is his talking about "doesn't private
> socket mean" when the code triggering in the thread the issue don't talk
> to it directly

I don't know who specifically you are referring to.

Brian's example, when run as root, connects to systemd using the private 
socket. When run as an unprivileged user it will go via the DBus daemon 
instead.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Antw: Re: systemd's connections to /run/systemd/private ?

[Michael Chapman]

On Wed, 14 Aug 2019, Reindl Harald wrote:
> Am 14.08.19 um 12:10 schrieb Ulrich Windl:
> >>>> Michael Chapman  schrieb am 14.08.2019 um 11:47 
> >>>> in
> >> That's all true, but the thing we need to check here is that systemd 
> >> correctly handles junk on the /run/systemd/private socket. The change on 
> >> the systemctl side certainly tries to prevent incorrect data being sent 
> >> down the socket -- though it looks like there's several ways in which 
> >> fd_move_above_stdio() can fail, so this isn't foolproof -- but we need to 
> >> ensure that some _malicious_ client can't DoS systemd.
> > 
> > I don't want to contradict in principle, but doesn't "private socket" mean 
> > it's intended to be used by systemd only? Of course being root allows you 
> > to use any socket...
> 
> may is ask you to read the thread you are responding to?
> nobody is touching the private socket

systemctl will mostly use /run/systemd/private when run as root.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Antw: Re: systemd's connections to /run/systemd/private ?

[Michael Chapman]

On Wed, 14 Aug 2019, Ulrich Windl wrote:
> >>> Michael Chapman  schrieb am 14.08.2019 um 11:47 in
> Nachricht :
> > On Wed, 14 Aug 2019, Lennart Poettering wrote:
> >> Quite frankly, invoking generic UNIX programs with fds < 3 closed is a
> >> really bad idea in general. That systemctl nowadays is particularly
> >> careful and deals with situations like that is not an invitation to
> >> actually invoke things like this. After all UNIX guarantees that
> >> open() (and the other calls that allocate an fd) allocated the lowest
> >> available one, hence they will necessarily step into
> >> stdin/stdout/stderr territory when invoked with any of those fds
> >> closed.
> >> 
> >> Hence: your code that closes fd1 like this is simply buggy. Don't do
> >> that, you are shooting yourself in the foot. And even if newer
> >> systemctl will handle cases like this more gracefully pretty much any
> >> other tool you might call will break in some form or another too,
> >> since a simple printf() will already spill into the wrong fds in that
> >> case.
> >> 
> >> Lennart
> > 
> > That's all true, but the thing we need to check here is that systemd 
> > correctly handles junk on the /run/systemd/private socket. The change on 
> > the systemctl side certainly tries to prevent incorrect data being sent 
> > down the socket -- though it looks like there's several ways in which 
> > fd_move_above_stdio() can fail, so this isn't foolproof -- but we need to 
> > ensure that some _malicious_ client can't DoS systemd.
> 
> Hi!
> 
> I don't want to contradict in principle, but doesn't "private socket" 
> mean it's intended to be used by systemd only? Of course being root 
> allows you to use any socket...
>
> I could imaging two things of torture testing:
> 1) send random data to the socket and see what happens.
> 2) vary valid messages randomly to see what happens

Any user can connect to it at least. systemd will drop the connection if 
it's from an unprivileged client. The question though is whether junk 
data still pending on that connection will cause systemd to leak the file 
descriptor.

I think we'd need to fully understand why the problem occurred on older 
systemd versions to be able to answer that. Maybe that problem has been 
fixed.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd's connections to /run/systemd/private ?

[Michael Chapman]

On Wed, 14 Aug 2019, Lennart Poettering wrote:
> Quite frankly, invoking generic UNIX programs with fds < 3 closed is a
> really bad idea in general. That systemctl nowadays is particularly
> careful and deals with situations like that is not an invitation to
> actually invoke things like this. After all UNIX guarantees that
> open() (and the other calls that allocate an fd) allocated the lowest
> available one, hence they will necessarily step into
> stdin/stdout/stderr territory when invoked with any of those fds
> closed.
> 
> Hence: your code that closes fd1 like this is simply buggy. Don't do
> that, you are shooting yourself in the foot. And even if newer
> systemctl will handle cases like this more gracefully pretty much any
> other tool you might call will break in some form or another too,
> since a simple printf() will already spill into the wrong fds in that
> case.
> 
> Lennart

That's all true, but the thing we need to check here is that systemd 
correctly handles junk on the /run/systemd/private socket. The change on 
the systemctl side certainly tries to prevent incorrect data being sent 
down the socket -- though it looks like there's several ways in which 
fd_move_above_stdio() can fail, so this isn't foolproof -- but we need to 
ensure that some _malicious_ client can't DoS systemd.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd's connections to /run/systemd/private ?

[Michael Chapman]

On Wed, 14 Aug 2019, Michael Chapman wrote:
> On Wed, 14 Aug 2019, Brian Reichert wrote:
> > On Thu, Aug 01, 2019 at 07:18:20PM +, Zbigniew J??drzejewski-Szmek 
> > wrote:
> > > Yes. (With the caveat that there *are* legitimate reasons to have new
> > > long-lived fds created, so not every long-lived fd is "wrong".)
> > 
> > I finally was able to track down what's happening on my system.
> > 
> > This is sufficient to reproduce the effect of increasing the number
> > of file descriptors open to /run/systemd/private; at least, on my
> > box, in it's current state:
> > 
> >   sh -c 'exec 1>&-; /usr/bin/systemctl status ntpd.service'
> 
> I can reproduce this on CentOS 7's systemd 219, but not on Fedora 29's 
> systemd 239.

Looking in to this further, my guess is that this is fixed in:

  commit 7fe2903c2315db9d9f501ae255a6b6e4f01ba46c
  Author: Lennart Poettering 
  Date:   Fri Feb 9 17:53:28 2018 +0100

  fd-util: move certain fds above fd #2 (#8129)

which was introduced in systemd 238.

What's happening is that systemctl is getting fd 1 for the socket to 
/run/systemd/private, as it's the lowest unused fd, but fd 1 (aka stdout) 
is also where it sends its regular human-readable output. This commit 
ensures that the socket is moved to a file descriptor that can't be 
mistaken for a standard stream.

I'm not sure if systemd >= 238 itself still suffers from the problem where 
any "extra" data on that connection causes it to leak its file descriptor. 
That may still be a problem, or it may have been fixed by a different 
commit.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd's connections to /run/systemd/private ?

[Michael Chapman]

On Wed, 14 Aug 2019, Brian Reichert wrote:
> On Thu, Aug 01, 2019 at 07:18:20PM +, Zbigniew J??drzejewski-Szmek wrote:
> > Yes. (With the caveat that there *are* legitimate reasons to have new
> > long-lived fds created, so not every long-lived fd is "wrong".)
> 
> I finally was able to track down what's happening on my system.
> 
> This is sufficient to reproduce the effect of increasing the number
> of file descriptors open to /run/systemd/private; at least, on my
> box, in it's current state:
> 
>   sh -c 'exec 1>&-; /usr/bin/systemctl status ntpd.service'

I can reproduce this on CentOS 7's systemd 219, but not on Fedora 29's 
systemd 239.

On CentOS 7 I took two `strace -e desc -p 1` runs, comparing:

  # good
  sh -c 'exec 1>/dev/null; systemctl status tmp.mount'

with:

  # bad
  sh -c 'exec 1>&-; systemctl status tmp.mount'

The diff is:

  # diff -u /tmp/good /tmp/bad
  --- /tmp/good 2019-08-14 18:11:20.100792406 +1000
  +++ /tmp/bad  2019-08-14 18:11:24.882886972 +1000
  @@ -6,7 +6,7 @@
   fstat(24, {st_mode=S_IFSOCK|0777, st_size=0, ...}) = 0
   epoll_ctl(4, EPOLL_CTL_ADD, 24, {0, {u32=107062384, u64=94382013391984}}) = 0
   epoll_ctl(4, EPOLL_CTL_MOD, 24, {EPOLLIN|EPOLLOUT, {u32=107062384, 
u64=94382013391984}}) = 0
  -timerfd_settime(3, TFD_TIMER_ABSTIME, {it_interval={0, 0}, 
it_value={1136546, 444853000}}, NULL) = 0
  +timerfd_settime(3, TFD_TIMER_ABSTIME, {it_interval={0, 0}, 
it_value={1136551, 444853000}}, NULL) = 0
   epoll_wait(4, [{EPOLLOUT, {u32=107062384, u64=94382013391984}}], 58, -1) = 1
   epoll_ctl(4, EPOLL_CTL_MOD, 24, {EPOLLIN, {u32=107062384, 
u64=94382013391984}}) = 0
   epoll_wait(4, [{EPOLLIN, {u32=107062384, u64=94382013391984}}], 58, -1) = 1
  @@ -23,13 +23,7 @@
   openat(AT_FDCWD, "/usr/local/lib/systemd/system/tmp.mount.d", 
O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = -1 ENOENT (No such file or 
directory)
   openat(AT_FDCWD, "/usr/lib/systemd/system/tmp.mount.d", 
O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = -1 ENOENT (No such file or 
directory)
   openat(AT_FDCWD, "/run/systemd/generator.late/tmp.mount.d", 
O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = -1 ENOENT (No such file or 
directory)
  -epoll_wait(4, [{EPOLLIN|EPOLLHUP, {u32=107062384, u64=94382013391984}}], 58, 
-1) = 1
  -epoll_ctl(4, EPOLL_CTL_MOD, 24, {0, {u32=107062384, u64=94382013391984}}) = 0
  -timerfd_settime(3, TFD_TIMER_ABSTIME, {it_interval={0, 0}, it_value={0, 1}}, 
NULL) = 0
  -epoll_wait(4, [{EPOLLHUP, {u32=107062384, u64=94382013391984}}, {EPOLLIN, 
{u32=3, u64=3}}], 58, -1) = 2
  -read(3, "\1\0\0\0\0\0\0\0", 8)  = 8
  +epoll_wait(4, [{EPOLLIN, {u32=107062384, u64=94382013391984}}], 58, -1) = 1
   epoll_ctl(4, EPOLL_CTL_DEL, 24, NULL)   = 0
  -close(24)   = 0
  -timerfd_settime(3, TFD_TIMER_ABSTIME, {it_interval={0, 0}, 
it_value={1136622, 194853000}}, NULL) = 0
   epoll_wait(4, strace: Process 1 detached
  

So it looks like systemd is removing the file descriptor from the epoll 
instance in both cases. However, in the "bad" case no EOF was reached, and 
the file descriptor is never closed. Looking at `ss` there is still 387 
bytes in this descriptor's receive queue.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Antw: Re: Antw: Re: Q: ConditionPathExists=

[Michael Chapman]

On Wed, 5 Jun 2019, Ulrich Windl wrote:
> >>> Reindl Harald  schrieb am 04.06.2019 um 14:23 in
> Nachricht <4e4bc6ca-2637-b10d-f4f6-536f45264...@thelounge.net>:
> 
> > 
> > Am 04.06.19 um 14:17 schrieb Ulrich Windl:
> [...]
> > BTW: can you please only reply to the list instead reply all, your
> > offlist copy is typically faster which leads in automatically delete the
> > later coming list-message on mailservers configured to kill such
> > needless duplicates and that breaks threading and reply-list in sane
> > mail clients
> 
> This is a thing the list should fix via Reply-To header (there is non 
> set). I can only "Reply" (goes to the From:) or "Reply to all". 
> Everything else is complex editing.

It would be solved if Reindl flipped the "Avoid duplicate copies of 
messages?" bit on his list subscriptions. Reply-To munging has some 
drawbacks, so most mailing lists don't do it.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Wtrlt: Re: Antw: Re: Unexplainable unit restart ("Start request repeated too quickly")

[Michael Chapman]

On Tue, 4 Jun 2019, Ulrich Windl wrote:
> >>> Michael Chapman  schrieb am 04.06.2019 um 11:04 in
> Nachricht :
[...]
> > As you can see, even E.service was only started once.
> > 
> > Are you sure you were actually doing everything in one transaction?
> 
> I guess your version is significantly newer than 228. In 228 I have some odd
> effects hard to explain (I'm still trying to learn).

I just tested it on systemd 239 (Fedora 29) and systemd 219 (RHEL 7). Same 
behaviour.
 
> As far as I can tell the following commands were issued (during package
> upgrade):
> reenable E
> start E
> reenable A
> restart A

At this point, if E has already completed and become inactive, then 
restarting A will start E again. This is to be expected.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Antw: Re: Unexplainable unit restart ("Start request repeated too quickly")

[Michael Chapman]

On Tue, 4 Jun 2019, Ulrich Windl wrote:
> >>> Michael Chapman  schrieb am 03.06.2019 um 13:14 in
> Nachricht :
> [...]
> > 
> > Um, OK. I don't think we're any closer to solving your problem though. :-)
> 
> Actually I am!
> The root of the problem is that any oneshot service without 
> RemainAfterExit=true is listed as "inactive (dead)" after being started. 
> I think the manual page should be more clear on that fact! Then if you 
> have a dependency like this (best viewed with a monospaced font):
>   B
>  / \
> A-C-E
>  \ /
>   D
> 
> where A is a target that wants B,C,D, and each of those in turn wants E 
> (which is the oneshot service), the following happens: When starting A, 
> E is NOT started ONCE, but it is started THREE TIMES, while my 
> expectation was it will be started once only. As I had set a burst limit 
> of 1, an unexpected fauilure was reported.
> 
> What I'm unsure: Does systemd wait for each "start of E" to terminate 
> before calling the next one (i.e. serialized), or are the starts being 
> attempted in parallel?
> 
> The obvious deficit in systemd is that it does not no a proper 2-pass 
> dependency analysis before executing: If it would do a dependency 
> analysis for starting A, it would see that E has to be started ONCE 
> before B,C,D. In stead it seems to do a 1-pass analysis firing the start 
> of E every time.

This doesn't seem right to me, as systemd _does_ have the concept of 
transactions to which multiple jobs can be attached, and the set of jobs 
does appear to be determined in one go based upon the configured 
requirement dependencies.

So I thought I'd set up a test case. I created a set of Type=oneshot units 
with Wants= dependencies as in your diagram. There were no ordering 
dependencies (Before= or After=). Each service just echoed its own name.

Then:

  $ systemctl --user daemon-reload
  $ systemctl --user start A.service

yielded:

  systemd[2312]: Reloading.
  systemd[2312]: Starting B...
  systemd[2312]: Starting D...
  echo[21672]: B
  systemd[2312]: Starting E...
  echo[21673]: D
  systemd[2312]: Starting A...
  echo[21674]: E
  systemd[2312]: Starting C...
  echo[21675]: A
  systemd[2312]: Started B.
  systemd[2312]: Started D.
  echo[21676]: C
  systemd[2312]: Started E.
  systemd[2312]: Started A.
  systemd[2312]: Started C.

As you can see, even E.service was only started once.

Are you sure you were actually doing everything in one transaction?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Antw: Re: Antw: Re: Unexplainable unit restart ("Start request repeated too quickly")

[Michael Chapman]

On Mon, 3 Jun 2019, Ulrich Windl wrote:
> >>> Reindl Harald  schrieb am 03.06.2019 um 12:35 in
> Nachricht :
> 
> > 
> > Am 03.06.19 um 12:30 schrieb Ulrich Windl:
> >>> That looks fine, though it _might_ make sense for it to have 
> >>> RemainAfterExit= turned on. After all, if default.target or 
> >>> iotwatch.target get restarted for any reason, then this unit will be 
> >>> started again.
> >> 
> >> That's a valuable hint: I thought systemd would remember that once started
> >> with success, the service is considered started until stopped manually.
> >> So does RemainAFterExit created a kind of dummy process that just remembers
> >> the state? The manual is not clear when you would need it:
> >> 
> >>RemainAfterExit=
> >>Takes a boolean value that specifies whether the service shall 
> >> be
> >>considered active even when all its processes exited. Defaults 
> >> to
> >>no.
> > 
> > a oneshot service without "RemainAfterExit" is not "active" for good
> > reasons - think about timer activated units or socket activated services
> > which both terminate after the last process exits and are started again
> > at the next event
> 
> But why isn't it on by default for "oneshot"?

I don't know, both RemainAfterExit=yes and RemainAfterExit=no are useful, 
so it's hard to know which should be the default.

Regardless, RemainAfterExit=no _is_ the default. Whether or not that's the 
most useful default is irrelevant: it can't be changed now, since any 
change would not be backwards-compatible.

> And if RemainAfterExit is on, can I simply "start" a oneshot service again, 
> or do I need a "restart"?

You would have to restart it. A "start" operation on an active unit is a 
no-op.

> For fun I read systemd.timer, and here the manual page says:
> 
>RemainAfterExit=
>Takes a boolean argument. If true, an elapsed timer will stay
>loaded, and its state remains queriable. Defaults to yes.
> 
> I almost seems as if the defaulkts are just inverted (wrong in both cases).
>
> Regards,
> Ulrich Windl

The directive was added to timer units significantly after it was added to 
service units. Again, I can see use-cases for both settings. For transient 
timers, for instance, it makes sense to discard them completely when 
they've fired. This would correspond closely with the way at jobs work, 
for instance.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Antw: Re: Unexplainable unit restart ("Start request repeated too quickly")

[Michael Chapman]

On Mon, 3 Jun 2019, Ulrich Windl wrote:
>>>> Michael Chapman  schrieb am 03.06.2019 um 11:39
> in
> Nachricht :
> > On Mon, 3 Jun 2019, Ulrich Windl wrote:
> > [...]
> >> Hi!
> >> 
> >> The generator unit is:
> >> [Unit]
> >> Description=I/O performance monitor instance generator
> >> Documentation=man:iotwatch‑generator(8) man:iotwatch@.service(8)
> >> Wants=nss‑user‑lookup.target time‑sync.target paths.target
> >> After=nss‑user‑lookup.target time‑sync.target paths.target
> >> ConditionPathExists=/etc/iotwatch.conf
> >> Conflicts=shutdown.target
> >> 
> >> [Service]
> >> Type=oneshot
> >> ExecStart=/usr/lib/iotwatch/iotwatch‑generator /run/systemd/system
> >> TimeoutStartSec=10
> >> RestartPreventExitStatus=2 3 4 5
> >> StartLimitBurst=1
> >> 
> >> [Install]
> >> WantedBy=default.target iotwatch.target
> > 
> > That looks fine, though it _might_ make sense for it to have 
> > RemainAfterExit= turned on. After all, if default.target or 
> > iotwatch.target get restarted for any reason, then this unit will be 
> > started again.
> 
> That's a valuable hint: I thought systemd would remember that once started
> with success, the service is considered started until stopped manually.
> So does RemainAFterExit created a kind of dummy process that just remembers
> the state? The manual is not clear when you would need it:
> 
>RemainAfterExit=
>Takes a boolean value that specifies whether the service shall be
>considered active even when all its processes exited. Defaults to
>no.

A oneshot service normally becomes inactive as soon as the command 
terminates. Once inactive it is available to be activated again.

You would use RemainAfterExit=true if you wanted the service to remain in 
an active state even once the command has terminated. While in this 
"active" state it can't be "activated" -- after all, it's _already_ 
active.

Some kind of "stop" action would be needed to transition the service back 
to its inactive state. This could be explicit (e.g. from systemctl) or 
implicit (via dependencies).

> > 
> > It's very weird to have what appears to be a generator done as a service 
> > though. Any idea why that might be the case?
> 
> Yes: systemd generators are called so early that they are not useful in my
> case (I cannot have dependencies for the generator). So I have a (little bit
> clever) generator service that creates or updates service files "when needed".
> 
> > 
> >> The iotwatch.target is:
> >> [Unit]
> >> Description=iotwatch I/O performance monitor
> >> Documentation=man:iotwatch@.service(8) man:iotwatch‑generator(8)
> >> After=nss‑lookup.target time‑sync.target paths.target
> >> Wants=iotwatch@NFS1.service iotwatch@NFS2.service iotwatch@LOC1.service 
> >> 
> >> [Install]
> >> WantedBy=default.target
> >> 
> >> and the instance services look like:
> >> # automatically generated by /usr/lib/iotwatch/iotwatch‑generator
> >> 
> >> [Unit]
> >> Description=iotwatch I/O performance monitor instance "LOC1"
> >> Documentation=man:iotwatch(1) man:iotwatch@.service(8)
> >> SourcePath=/etc/iotwatch.conf
> >> PartOf=iotwatch.target
> > 
> > That also seems to imply that starting and stopping iotwatch.target would 
> > be something that happens with some regularity.
> 
> After a configuration change (when the generator actually updated the service
> files).

OK, so since iotwatch-generator.service is WantedBy=iotwatch.target, that 
means if iotwatch.target is started or restarted, for any reason, 
then iotwatch-generator.service will also be activated.
 
> 
> > 
> >> Requires=iotwatch‑generator.service
> >> Wants=nss‑user‑lookup.target time‑sync.target paths.target
> >> After=iotwatch‑generator.service
> >> After=nss‑user‑lookup.target time‑sync.target paths.target
> >> ConditionPathExists=/etc/passwd
> >> Conflicts=shutdown.target
> >> 
> >> [Service]
> >> Type=forking
> >> RuntimeDirectory=iotwatch‑LOC1
> >> WorkingDirectory=/var/run/iotwatch‑LOC1
> >> ExecStartPre=/bin/sh ‑c '...'
> >> ExecStart=@/var/run/iotwatch‑LOC1/iotwatch‑LOC1 iotwatch‑LOC1 ‑l ...
> >> /etc/passwd
> >> ExecStartPost=/usr/bin/sleep 0.2
> >> TimeoutStartSec=10
> >> ExecStop=/var/run/iotwatch‑LOC1/iotwatch‑LOC1 ‑l ...
> >> #SyslogIdentifier=%p‑LOC1
> >> TimeoutStopSec=30
>

Re: [systemd-devel] Antw: Re: Unexplainable unit restart ("Start request repeated too quickly")

[Michael Chapman]

On Mon, 3 Jun 2019, Ulrich Windl wrote:
[...]
> Hi!
> 
> The generator unit is:
> [Unit]
> Description=I/O performance monitor instance generator
> Documentation=man:iotwatch-generator(8) man:iotwatch@.service(8)
> Wants=nss-user-lookup.target time-sync.target paths.target
> After=nss-user-lookup.target time-sync.target paths.target
> ConditionPathExists=/etc/iotwatch.conf
> Conflicts=shutdown.target
> 
> [Service]
> Type=oneshot
> ExecStart=/usr/lib/iotwatch/iotwatch-generator /run/systemd/system
> TimeoutStartSec=10
> RestartPreventExitStatus=2 3 4 5
> StartLimitBurst=1
> 
> [Install]
> WantedBy=default.target iotwatch.target

That looks fine, though it _might_ make sense for it to have 
RemainAfterExit= turned on. After all, if default.target or 
iotwatch.target get restarted for any reason, then this unit will be 
started again.

It's very weird to have what appears to be a generator done as a service 
though. Any idea why that might be the case?

> The iotwatch.target is:
> [Unit]
> Description=iotwatch I/O performance monitor
> Documentation=man:iotwatch@.service(8) man:iotwatch-generator(8)
> After=nss-lookup.target time-sync.target paths.target
> Wants=iotwatch@NFS1.service iotwatch@NFS2.service iotwatch@LOC1.service 
> 
> [Install]
> WantedBy=default.target
> 
> and the instance services look like:
> # automatically generated by /usr/lib/iotwatch/iotwatch-generator
> 
> [Unit]
> Description=iotwatch I/O performance monitor instance "LOC1"
> Documentation=man:iotwatch(1) man:iotwatch@.service(8)
> SourcePath=/etc/iotwatch.conf
> PartOf=iotwatch.target

That also seems to imply that starting and stopping iotwatch.target would 
be something that happens with some regularity.

> Requires=iotwatch-generator.service
> Wants=nss-user-lookup.target time-sync.target paths.target
> After=iotwatch-generator.service
> After=nss-user-lookup.target time-sync.target paths.target
> ConditionPathExists=/etc/passwd
> Conflicts=shutdown.target
> 
> [Service]
> Type=forking
> RuntimeDirectory=iotwatch-LOC1
> WorkingDirectory=/var/run/iotwatch-LOC1
> ExecStartPre=/bin/sh -c '...'
> ExecStart=@/var/run/iotwatch-LOC1/iotwatch-LOC1 iotwatch-LOC1 -l ...
> /etc/passwd
> ExecStartPost=/usr/bin/sleep 0.2
> TimeoutStartSec=10
> ExecStop=/var/run/iotwatch-LOC1/iotwatch-LOC1 -l ...
> #SyslogIdentifier=%p-LOC1
> TimeoutStopSec=30
> PIDFile=/var/run/iotwatch-LOC1/iotwatch-LOC1.pid
> Restart=always
> RestartSec=10s
> RestartPreventExitStatus=1
> StartLimitBurst=1
> 
> [Install]
> WantedBy=iotwatch.target
> 
> > 
> > It might also be good to know the RequiredBy, WantedBy, TriggeredBy, 
> > RequisiteOf and PartOf properties of this iotwatch-generator.service (see 
> > `systemctl show iotwatch-generator.service`), since they're possible ways 
> > in which the service may be implicitly started or restarted.
> 
> Yes, but I'm missing a log message that explains what happened.

Sure, there isn't one. That's why I'm asking about the properties.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Unexplainable unit restart ("Start request repeated too quickly")

[Michael Chapman]

On Mon, 3 Jun 2019, Ulrich Windl wrote:
> Hi!
> 
> When installing a test package, I noticed that one unit
> (iotwatch-generator.service) triggered a restart for an unknown reason. The
> status is (note: no reason for restart shown):
> 
> # systemctl status iotwatch-generator.service -l
> ● iotwatch-generator.service - I/O performance monitor instance generator
>Loaded: loaded (/usr/lib/systemd/system/iotwatch-generator.service;
> enabled; vendor preset: disabled)
>Active: failed (Result: start-limit) since Mon 2019-06-03 09:41:18 CEST;
> 5min ago
>  Docs: man:iotwatch-generator(8)
>man:iotwatch@.service(8)
>   Process: 29133 ExecStart=/usr/lib/iotwatch/iotwatch-generator
> /run/systemd/system (code=exited, status=0/SUCCESS)
>  Main PID: 29133 (code=exited, status=0/SUCCESS)
> 
> Jun 03 09:41:18 v04 systemd[1]: Starting I/O performance monitor instance
> generator...
> Jun 03 09:41:18 v04 systemd[1]: Started I/O performance monitor instance
> generator.
> Jun 03 09:41:22 v04 systemd[1]: iotwatch-generator.service: Start request
> repeated too quickly.
> Jun 03 09:41:22 v04 systemd[1]: Failed to start I/O performance monitor
> instance generator.
> Jun 03 09:41:22 v04 systemd[1]: iotwatch-generator.service: Unit entered
> failed state.
> Jun 03 09:41:22 v04 systemd[1]: iotwatch-generator.service: Failed with result
> 'start-limit'.
> 
> So there was a successful start, but then some spurious restart. Why?

It'd probably be easier if you supplied us with these units' 
configurations. My distribution does not ship iotwatch@.service or 
iotwatch-generator.service units.

It might also be good to know the RequiredBy, WantedBy, TriggeredBy, 
RequisiteOf and PartOf properties of this iotwatch-generator.service (see 
`systemctl show iotwatch-generator.service`), since they're possible ways 
in which the service may be implicitly started or restarted.___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Antw: Re: suggestion: auto reload as the default to help packagers?

[Michael Chapman]

On Mon, 3 Jun 2019, Andrei Borzenkov wrote:
> 03.06.2019 10:15, Ulrich Windl пишет:
> >>>> Michael Chapman  schrieb am 31.05.2019 um 13:28 
> >>>> in
> > Nachricht :
> >> On Fri, 31 May 2019, Reindl Harald wrote:
> >>> Am 31.05.19 um 12:31 schrieb Michael Chapman:
> >>>> For RPM on Fedora, the systemd package has %transfiletriggerin and 
> >>>> %transfiletriggerun scriptlets that run automatically at the end of the 
> >>>> RPM transaction if units were installed or removed. This is the cleanest 
> >>>> approach since it means all changes from all updated packages are 
> >>>> applied 
> >>>> at once.
> >>>
> >>> sadly that's all theory given that all services in Fedora are
> >>> automatically hard restartet when packages are updated and "at the end"
> >>> is too late when the service got restarted with the old unit but new 
> >>> binary
> >>
> >> I actually got it slightly wrong: %transfiletriggerin and 
> >> %transfiletriggerun occur in the _middle_ of the transaction, in between 
> 
> That's not what source says:
> 
> https://github.com/rpm-software-management/rpm/blob/096ec07465f6d223a1e9d68b69e2fab103f7/lib/transaction.c#L1660
> 
> The sequence is
> 
> %pretrans
> %transfiletriggerun
> actual transaction
> %posttrans
> %transfiletriggerpostun
> %transfiletriggerin
> 
> Are you sure you do not mix up %transfiletrigger and %filetrigger?

Quite possible. I really wish the %_docdir/triggers shipped in RPM 
was updated to describe file triggers properly.

Regardless, I'm pretty sure that the way systemd is using these things is 
correct. I certainly have never seen any issues in services being 
restarted with "old" unit configs.___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Antw: Re: suggestion: auto reload as the default to help packagers?

[Michael Chapman]

On Mon, 3 Jun 2019, Ulrich Windl wrote:
[...]
> Where is the definitive documentation for these (rather new) RPM features?

https://rpm.org/user_doc/file_triggers.html

For Fedora specifically: 
https://docs.fedoraproject.org/en-US/packaging-guidelines/Scriptlets/

> And do all the major RPM-based dirstributions support these?

File triggers have been available since RPM 4.13. 

For packages that ship systemd units, so long as they use the various 
%systemd_* macros in the correct places, everything should work correctly 
no matter which RPM-based distribution the package is being built for. 
That's because the %systemd_* macros are tailored appropriately for each 
of those distributions -- I already noted how they differ between current 
versions of systemd and the version of system on RHEL 7, for instance.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] suggestion: auto reload as the default to help packagers?

[Michael Chapman]

On Fri, 31 May 2019, Reindl Harald wrote:
[...]
> [harry@srv-rhsoft:/downloads/f28-f29]$ cat *.txt | grep -i "changed on disk"
> Warning: The unit file, source configuration file or drop-ins of
> mlocate-updatedb.timer changed on disk. Run 'systemctl daemon-reload' to
> reload units.
[...]

Without knowing how any of those files were generated, I cannot comment on 
them.

As I said, I do not see these kinds of errors during regular RPM 
transactions (online or offline).

If you think you have a bug, please raise a bug report. Mailing list rants 
won't help you.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] suggestion: auto reload as the default to help packagers?

[Michael Chapman]

On Fri, 31 May 2019, Reindl Harald wrote:
> Am 31.05.19 um 12:31 schrieb Michael Chapman:
> > For RPM on Fedora, the systemd package has %transfiletriggerin and 
> > %transfiletriggerun scriptlets that run automatically at the end of the 
> > RPM transaction if units were installed or removed. This is the cleanest 
> > approach since it means all changes from all updated packages are applied 
> > at once.
> 
> sadly that's all theory given that all services in Fedora are
> automatically hard restartet when packages are updated and "at the end"
> is too late when the service got restarted with the old unit but new binary

I actually got it slightly wrong: %transfiletriggerin and 
%transfiletriggerun occur in the _middle_ of the transaction, in between 
installation of new packages (or new versions of packages) and removal of 
old packages (or old versions of packages). While %transfiletriggerin 
does perform a daemon-reload, %transfiletriggerun simply stores a 
flag that's picked up by a separate %filetriggerpostun scriptlet. That 
reloads systemd.

So overall there shouldn't be any issues there. I don't recall seeing the 
errors you're talking about.

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

Re: [systemd-devel] suggestion: auto reload as the default to help packagers?

[Michael Chapman]

On Fri, 31 May 2019, Roger Pack wrote:
> Had a thought the other day...
> 
> Seems like many packages (ex: rpm's) that includes a *.service file
> may eventually be required to call
> 
> systemctl daemon-reload
> 
> in the package, for new file changes to "take."
> 
> This causes bugs like
> https://github.com/StackStorm/st2-packages/issues/495 (which lists
> other reports of this problem near the bottom).
> 
> Seeing as one goal of systemd is to DRY up installation and running of
> services so that people can't "accidentally mess things up" through
> their own init.d files...perhaps that principle could be expanded upon
> to help make it so that package creators also can't "accidentally mess
> things up"?  Maybe the default could be to reload units automatically,
> ?  With a configuration option to not to, so that package creators
> don't *all* have to remember to daemon-reload, since not all do?
> 
> Just a thought, thinking out loud.

There's a couple of reasons auto-reloading could be problematic.

First, it doesn't help with generated units. systemd has no way to 
know that the contents of generated units might be different than 
before, since the way these units are generated is entirely opaque to it.

It also means that the sysadmin can't prepare a set of interconnected 
changes and have them applied at once. For instance, you might want a 
timer unit and its associated service unit to be applied at the same time, 
rather than have the timer fire before the service has been properly 
configured.

For RPM on Fedora, the systemd package has %transfiletriggerin and 
%transfiletriggerun scriptlets that run automatically at the end of the 
RPM transaction if units were installed or removed. This is the cleanest 
approach since it means all changes from all updated packages are applied 
at once.

For RHEL 7, at least, it appears that RPM does not support file triggers. 
However, the %systemd_postun macro supplied by systemd for use by 
packagers always reloads systemd on this OS.

So either way, there should be no need for a packager to explicitly 
invoke daemon-reload from their own package's scriptlets. They should just 
use the macros provided systemd.

It looks like the project you linked to is using its own macros instead, 
which is probably why it didn't work properly.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Requires and After

[Michael Chapman]

On Thu, 3 Jan 2019, Jonathon Kowalski wrote:
> On Wed, 2 Jan 2019, Jérémy Rosen wrote:
> > I'm pretty sure that there is something about Requires making a unit fail if
> > it's dependency has already failed when it is scheduled for startup...
> >
> > Again I may be wrong...
> 
> On Wed, 2 Jan 2019, Michael Chapman wrote
> >Make of that what you will. I was expecting a.service to stop because
> >b.service failed, but apparently my understanding of this isn't quite
> >right.
> 
> Requires= alone without After= has interesting interaction with
> systemd's job machinery.
> 
> When you use Requires= alone, say from a to b (as in Michael's
> example), two start jobs will be queued for both as part of the
> transaction, but the one for a will not wait for the one for b to
> complete running. Therefore, both go in parallel, and at one point, if
> a completes before b, it will start up as usual. However, if b fails
> before a completes, the start job for a is canceled with
> JOB_DEPENDENCY job result. Hence, in your case, the job is dispatched
> right away and completes before b fails.

For what it's worth, I was quite aware of the issues in omitting any 
ordering dependency with these units. However, I was expecting a.service 
to be stopped whether or not b.service failed before or after a.service 
had become active.

I'll have to do further testing to nail down the behaviour precisely. The 
documentation certainly seems to indicate that no matter how and no matter 
when b.service gets stopped, a.service would be stopped.___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] .service and .socket

[Michael Chapman]

On Wed, 2 Jan 2019, Reindl Harald wrote:
> Am 02.01.19 um 11:49 schrieb Michael Chapman:
> > On Wed, 2 Jan 2019, Reindl Harald wrote:
> > [...]
> >> agreed, but why can't have socket simply optional a [Service] section to
> >> save the "demo@.service" in cases like below?
> >>
> >> [root@client:/etc/systemd/system]$ cat demo.socket
> >> [Unit]
> >> Description=Demo Server - Activation Socket
> >>
> >> [Socket]
> >> Accept=yes
> >> ListenStream=0.0.0.0:7
> >> ListenStream=0.0.0.0:19
> >> ListenStream=0.0.0.0:21
> >>
> >> [Service]
> >> Type=oneshot
> >> ExecStart=/usr/bin/echo "DEMO-SERVICE"
> >> StandardOutput=socket
> >> StandardInput=socket
> >>
> >> [Install]
> >> WantedBy=sockets.target
> 
> first can you please reply only to the list so that the duplicate
> message-filter don't rip the later coming list message after your
> off-list copy was received breaking my reply-to-list button and threading?

I'll try to remember, but I'm likely to forget. (I use Reply-all for much 
the reasons described in [1]. I also prefer _receiving_ Reply-all emails, 
since I've set up notifications when I receive personal email, but 
not when I receive list email. You're lucky I'm keeping an eye on this 
list at the moment, otherwise I probably wouldn't have seen your reply. 
Mailman deduplicates the mail for me, so I never see duplicates. 
Threading is fine since all the relevant headers are kept intact.)

[1] http://david.woodhou.se/reply-to-list.html

> > Presumably things in [Unit] would only apply to the socket. What if the 
> > service needs [Unit] directives itself? Do we really want yet another 
> > special case ("you can embed the service inside the socket... but only if 
> > the service doesn't need [Unit] directives")?
> 
> why would they need only apply to the socket?

Well, consider things like After= and Before=. Yes, you could make those 
only apply to both the socket and the service, but it wouldn't make much 
sense. In fact, they probably should only apply to the service.

But then you've got the special case that [Unit] directives inside a file 
whose name matches *.socket don't apply to the socket, if and only if the 
file also contains a [Service] section.

I would find that confusing.

> > I really don't think combining two units into one file makes things 
> > simpler.
> well, all the 5 socket-activation units i ever wrote have besides
> ExecStart boilerplate stuff to make it a valid unit

I'm just looking on my system, and most of the socket-activated services 
have their own other [Unit]-section directives in them (and not just 
Description=).
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] .service and .socket

[Michael Chapman]

On Wed, 2 Jan 2019, Reindl Harald wrote:
[...]
> agreed, but why can't have socket simply optional a [Service] section to
> save the "demo@.service" in cases like below?
> 
> [root@client:/etc/systemd/system]$ cat demo.socket
> [Unit]
> Description=Demo Server - Activation Socket
> 
> [Socket]
> Accept=yes
> ListenStream=0.0.0.0:7
> ListenStream=0.0.0.0:19
> ListenStream=0.0.0.0:21
> 
> [Service]
> Type=oneshot
> ExecStart=/usr/bin/echo "DEMO-SERVICE"
> StandardOutput=socket
> StandardInput=socket
> 
> [Install]
> WantedBy=sockets.target

Presumably things in [Unit] would only apply to the socket. What if the 
service needs [Unit] directives itself? Do we really want yet another 
special case ("you can embed the service inside the socket... but only if 
the service doesn't need [Unit] directives")?

I really don't think combining two units into one file makes things 
simpler.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Requires and After

[Michael Chapman]

On Wed, 2 Jan 2019, Reindl Harald wrote:
> Am 02.01.19 um 09:14 schrieb Michael Chapman:
> > I have two services on my system, A.service and B.service, where A.service 
> > Wants=B.service but is ordered Before=B.service. The reason for this is 
> > that when I start A I want B to be automatically started too, but B cannot 
> > function without A being active.
> 
> this is insane

Please reduce your hyperbole.

> when B cannot work without A then B wants A and not the other way

I should have probably been more precise with "cannot function". B can 
actually function without A. It's just useless if it were to do so.

Moreover, the fact that B is started as a side-effect of starting A is 
important. I _do not_ want to have to start B explicitly. As I noted in 
another email, I've got some systems where B does not even exist. Having 
every system just have an A.timer that starts A (and on some of them, B as 
well) is very convenient.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Requires and After

[Michael Chapman]

On Wed, 2 Jan 2019, Jérémy Rosen wrote:
> So...
> >> Requires = Wants + PartOf
> >> Requires + After = Wants  + PartOf + Requisite + After
> >>
> >> better ?
> >> My goal is to try to clarify that in the documentation at some point...
> > I don't think Requisite= comes into it at all.
> >
> > Requisite= propagates a "start" or "restart" job as a "verify-active" job.
> > In other words, it only checks that the other unit is active, failing the
> > activation of the current unit if necessary.
> >
> > Requires= propagates these as "start" jobs, activating the other unit if
> > it is not already active.
> I'm pretty sure that there is something about Requires making a unit fail if
> it's dependency has already failed when it is scheduled for startup...
> 
> Again I may be wrong...

Let's try it out!

$ systemctl --user cat a.service
# /home/mchapman/.config/systemd/user/a.service
[Unit]
Requires=b.service

[Service]
ExecStart=/bin/true
RemainAfterExit=true

$ systemctl --user cat b.service
# /home/mchapman/.config/systemd/user/b.service
[Service]
ExecStart=/bin/false
RemainAfterExit=true

$ systemctl --user start b.service

No error here, since a Type=oneshot service is always immediately active. 
But it did fail, as expected:

$ systemctl --user status b.service
* b.service
   Loaded: loaded (/home/mchapman/.config/systemd/user/b.service; static; 
vendor preset: enabled)
   Active: failed (Result: exit-code) since Wed 2019-01-02 20:29:53 AEDT; 
7s ago
  Process: 512 ExecStart=/bin/false (code=exited, status=1/FAILURE)
 Main PID: 512 (code=exited, status=1/FAILURE)

Jan 02 20:29:53 beren.home systemd[2618]: Started b.service.
Jan 02 20:29:53 beren.home systemd[2618]: b.service: Main process exited, 
code=exited, status=1/FAILURE
Jan 02 20:29:53 beren.home systemd[2618]: b.service: Unit entered failed 
state.
Jan 02 20:29:53 beren.home systemd[2618]: b.service: Failed with result 
'exit-code'.

So what happens if we now try to start a.service?

$ systemctl --user start a.service
$ systemctl --user status a.service
* a.service
  Loaded: loaded (/home/mchapman/.config/systemd/user/a.service; static; 
vendor preset: enabled)
  Active: active (exited) since Wed 2019-01-02 20:30:08 AEDT; 2s ago
 Process: 544 ExecStart=/bin/true (code=exited, status=0/SUCCESS)
Main PID: 544 (code=exited, status=0/SUCCESS)

Jan 02 20:30:08 beren.home systemd[2618]: Started a.service.

It was successful! But you can see that it was unable to start b.service a 
second time:

$ systemctl --user status b.service
* b.service
   Loaded: loaded (/home/mchapman/.config/systemd/user/b.service; static; 
vendor preset: enabled)
   Active: failed (Result: exit-code) since Wed 2019-01-02 20:30:08 AEDT; 
4s ago
  Process: 545 ExecStart=/bin/false (code=exited, status=1/FAILURE)
 Main PID: 545 (code=exited, status=1/FAILURE)

Jan 02 20:30:08 beren.home systemd[2618]: Started b.service.
Jan 02 20:30:08 beren.home systemd[2618]: b.service: Main process exited, 
code=exited, status=1/FAILURE
Jan 02 20:30:08 beren.home systemd[2618]: b.service: Unit entered failed 
state.
Jan 02 20:30:08 beren.home systemd[2618]: b.service: Failed with result 
'exit-code'.

However, explicitly stopping b.service causes a.service to be stopped:

$ systemctl stop --user b.service
[mchapman@beren ~]$ systemctl --user status a.service
* a.service
   Loaded: loaded (/home/mchapman/.config/systemd/user/a.service; static; 
vendor preset: enabled)
   Active: inactive (dead)

Jan 02 20:33:33 beren.home systemd[2618]: Stopped a.service.

Make of that what you will. I was expecting a.service to stop because 
b.service failed, but apparently my understanding of this isn't quite 
right.___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Requires and After

[Michael Chapman]

On Wed, 2 Jan 2019, Jérémy Rosen wrote:
> 
> 
> On 02/01/2019 10:08, Michael Chapman wrote:
> >
> >> Requires = Wants + Requisite + PartOf
> >>
> >> is that correct ?
> > I think it's just:
> >
> >Requires = Wants + PartOf
> >
> > Wants= propagates "start" and "restart" jobs as "start" jobs on the other
> > unit.
> >
> > ConsistsOf= (the inverse of PartOf=) propagates "stop" and "restart" jobs
> > as "stop" and "try-restart" jobs respectively on the other unit.
> >
> > So Wants= configures activation dependencies in one direction, and
> > PartOf= configures deactivation dependencies in the other direction.
> >
> > (I'm taking this from transaction_add_job_and_dependencies in
> > src/core/transaction.c, if anybody wants to check my working.)
> So...
> 
> Requires = Wants + PartOf
> Requires + After = Wants  + PartOf + Requisite + After
> 
> better ?
> My goal is to try to clarify that in the documentation at some point...

I don't think Requisite= comes into it at all.

Requisite= propagates a "start" or "restart" job as a "verify-active" job. 
In other words, it only checks that the other unit is active, failing the 
activation of the current unit if necessary.

Requires= propagates these as "start" jobs, activating the other unit if 
it is not already active.___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Requires and After

[Michael Chapman]

On Wed, 2 Jan 2019, Jérémy Rosen wrote:
> 
> > In my opinion, I don't think the extra inconsistency we get from this is
> > worth it. It literally only saves one line in a unit file.
> >
> It's not about saving a line in the unit file, it's about avoiding errors on
> the most common case
> 
> i.e if A Requires B, you would expect failures of B to prevent A from
> starting.
> * This is not the case if B is (randomly) scheduled after A.
> * This is the case if B is (randomly) scheduled before A.
> This is the race the implicit After= would prevent.
> 
> That being said... the fact that Requires influences both startup and 
> restart/shutdown makes things a bit more complicated...
>
> From reading the documentation it seems that Requires without After is 
> equivalent to PartOf and thus is suspicious (if you want PartOf, you 
> should use PartOf, if you want Requires, the you should also use After)

Well, PartOf= doesn't provide any forward activation dependencies, so it's 
not exactly equivalent.

> This means that there are cases to be checked for but I still globally 
> think that Requires without After is suspicious, and that an implicit 
> order would make sense... but that's just my opinion and I am still a 
> bit confused about the fine-details of what Requires does.
> 
> my understanding is
> 
> Requires = Wants + Requisite + PartOf
> 
> is that correct ?

I think it's just:

  Requires = Wants + PartOf

Wants= propagates "start" and "restart" jobs as "start" jobs on the other 
unit.

ConsistsOf= (the inverse of PartOf=) propagates "stop" and "restart" jobs 
as "stop" and "try-restart" jobs respectively on the other unit.

So Wants= configures activation dependencies in one direction, and 
PartOf= configures deactivation dependencies in the other direction.

(I'm taking this from transaction_add_job_and_dependencies in 
src/core/transaction.c, if anybody wants to check my working.)___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Requires and After

[Michael Chapman]

On Wed, 2 Jan 2019, Olaf van der Spek wrote:
> On Wed, Jan 2, 2019 at 9:14 AM Michael Chapman  wrote:
> > > What good is an activation dependency without an ordering dependency?
> >
> > The problem is that it's not necessarily clear _which_ ordering dependency
> > is required. systemd can't just assume one way or the other.
> >
> 
> > I have two services on my system, A.service and B.service, where A.service
> > Wants=B.service but is ordered Before=B.service. The reason for this is
> > that when I start A I want B to be automatically started too, but B cannot
> > function without A being active.
> 
> And A can't function without B being active? So basically a circular 
> dependency?

No, not a circular dependency. A can function without B. I just want B   
to start whenever A starts, but I want B to start _after_ A starts.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Requires and After

[Michael Chapman]

On Wed, 2 Jan 2019, Zbigniew Jędrzejewski-Szmek wrote:
> On Wed, Jan 02, 2019 at 07:14:10PM +1100, Michael Chapman wrote:
[...]
> > The problem is that it's not necessarily clear _which_ ordering dependency 
> > is required. systemd can't just assume one way or the other.
> > 
> > I have two services on my system, A.service and B.service, where A.service 
> > Wants=B.service but is ordered Before=B.service. The reason for this is 
> > that when I start A I want B to be automatically started too, but B cannot 
> > function without A being active.
> 
> But this really means that B.service should have After=A.service +
> Requires=A.service. Having A.service/start automatically imply B.service/start
> is just unnecessary magic.

In my particular case the magic is quite useful. Specifically, only _some_ 
of my systems need B.service. I don't want to have to think "on this 
system I need to start A, but on this system I need to start B and let it 
automatically start A".

I could imagine also it'd be useful if B.service had some ConditionFoo= 
directive, since that won't prevent A.service from being started even if 
it had Requires=B.service.

> > So here's an example where the activation dependency is essentially 
> > "opposite" that of the ordering dependency.
> > 
> > As you've pointed out, Requires= a bit of a strange case. If I change the 
> > above situation to use Requires= instead, and if B subsequently exits or 
> > fails, A would be stopped. I don't have an immediate use for that, but I 
> > think it's a bit presumptuous to assume that no use could possibly exist.
> > 
> > I think there's use in having Wants= and Requires= work similarly to each 
> > other, in that they are both orthogonal to ordering dependencies. It would 
> > be odd to have only one imply an ordering dependency.
> 
> If we made Requires= imply After=, it'd be a "default" dependency, so an
> explicit Before= would prevent the After= from being added. (This is the same
> as for .wants/ and .after/ directories: an ordering dependency is added, if
> DefaultDependencies=yes, and if Before= was not added to invert the ordering.)
> So a "reverse" orderding like you describe would still be possible.

OK. I'm still not convinced the inconsistency is worth it (it's hard 
enough explaining the existing logic, now we're thinking about adding 
_more_ exceptional cases!), but if it can be overridden it's not too bad.___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Requires and After

[Michael Chapman]

On Wed, 2 Jan 2019, Zbigniew Jędrzejewski-Szmek wrote:
> On Sun, Dec 30, 2018 at 12:05:46PM +0100, Olaf van der Spek wrote:
> > Hi,
> > 
> > Evverx suggested I ask here @ 
> > https://github.com/systemd/systemd/issues/11284
> > It's about Requires and After. I think a unit in Requires should imply
> > that unit in After too, otherwise the requirement isn't really met.
> > Is there a use case for Requires but not After?
> > If not, would it make sense to change semantics to have Requires imply 
> > After?
> 
> The short answer is that Requires without After is mostly meaningless,
> because it's impossible for systemd to actually implement the check,
> so effectively Requires downgrades to Wants.

Only on service activation though.

During deactivation, RequiredBy= dependencies (but not WantedBy= 
dependencies) are followed to enqueue further deactivation jobs.

> Two considerations though:
> - For Wants=, it is OK to not have an ordering dependency.
> 
>   So if we made Requires= imply After=, there'd be an inconsistency
>   between Requires= and Wants=.
> 
> - When .requires/ is used (and .wants/ too), an After= dependency is
>   added automatically.
> 
> I think we could consider making Requires= imply After=, with the
> necessary notices in NEWS, if somebody looks through units (e.g. all
> the ones packaged in Fedora), to verify that this is unlikely to break
> existing units. Elsewhere in the thread, somebody mentioned openstack,
> so that'd be first thing to check.

In my opinion, I don't think the extra inconsistency we get from this is 
worth it. It literally only saves one line in a unit file.___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Requires and After

[Michael Chapman]

On Wed, 2 Jan 2019, Jérémy Rosen wrote:
> 
> >> What's the benefit of not having After= for those services?
> >I guess they can start and do their initialization in parallel with
> > the service they require.
> In that case, what is the benefit or Requires vs Wants ?
> 
> I might be missing something about what Requires does (shutdown ?) but at that
> point, Wants would be a better dependency, no ?

If a unit Requires=other.service, any stop or restart job for 
other.service is propagated back to this unit (the latter as try-restart). 
This does not occur with Wants=.

In _most_ cases this back-propagation isn't needed, which is why Wants= is 
generally preferred.___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Requires and After

[Michael Chapman]

On Wed, 2 Jan 2019, Olaf van der Spek wrote:
> On Wed, Jan 2, 2019 at 4:22 AM James Feeney  wrote:
> > systemd has two different classes of "dependencies": 1) "activation" 
> > dependencies, and 2) "ordering" dependencies.
> >
> > An activation dependency does not, a priori, have to obey any rules 
> > about ordering.  There are not, automatically, any promises or 
> > guarantees about in what order service units, for instance, might be 
> > queued for execution, based upon a Requires= dependency.
> >
> > "Ordering" is an independent characteristic from "Activation".  
> > "Activation" only promises to enqueue a unit, and then, only if the 
> > unit is some kind of unit that can be "executed", such as a timer or 
> > service unit.  In contrast, for instance, systemd is only a "passive 
> > observer" of a device unit.  "enqueuing" a device unit for 
> > "activation" would make no sense in this context.  A *service* unit 
> > that *creates* a device unit could be enqueued for activation, but not 
> > the device unit itself.
> >
> > If "A Requires B", and you don't like that "A" *might* get enqueued, 
> > or get executed, before "B", then add an "ordering" dependency.  
> > "Ordering dependencies", then, create guarantees about unit activation 
> > *ordering*.
> 
> What good is an activation dependency without an ordering dependency?

The problem is that it's not necessarily clear _which_ ordering dependency 
is required. systemd can't just assume one way or the other.

I have two services on my system, A.service and B.service, where A.service 
Wants=B.service but is ordered Before=B.service. The reason for this is 
that when I start A I want B to be automatically started too, but B cannot 
function without A being active.

So here's an example where the activation dependency is essentially 
"opposite" that of the ordering dependency.

As you've pointed out, Requires= a bit of a strange case. If I change the 
above situation to use Requires= instead, and if B subsequently exits or 
fails, A would be stopped. I don't have an immediate use for that, but I 
think it's a bit presumptuous to assume that no use could possibly exist.

I think there's use in having Wants= and Requires= work similarly to each 
other, in that they are both orthogonal to ordering dependencies. It would 
be odd to have only one imply an ordering dependency.

Moreover, we can't simply change what systemd does here: it would be a 
backward-incompatible change. We don't want that.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] .service and .socket

[Michael Chapman]

On Tue, 1 Jan 2019, Olaf van der Spek wrote:
> Hi,
> 
> AFAIK socket units require a separate file, which seems more complex
> then it has to be.
> 
> 1. Could sockets be specified directly in the .service file?

If anything, I should think it would work the other way around: a .socket 
without any activatable .service is relatively useless.

But I'm not proposing that this actually be implemented.

> 2. If not, could the .service file gain a default / implicit
> dependency on the .socket file?

There are a some reasons for not having a .service dependent upon its 
.socket. Many services can be started directly and will work correctly 
even when not passed any sockets from systemd.

> 3. AFAIK Install.WantedBy doesn't have a default. Could it get a proper 
> default?

That doesn't make much sense.

Take your example:

> xhp.service:
> [Unit]
> Requires=xhp.socket
> 
> [Install]
> WantedBy=default.target
> 
> xhp.socket:
> [Socket]
> ListenStream=/run/xhp.socket

This would start xhp.service at daemon startup (i.e. boot, for the system 
daemon) whether or not the service is actually required. One of the 
reasons for using socket activation is to _not_ start services when 
they're not required.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Environment-variable security?

[Michael Chapman]

On Tue, 13 Nov 2018, David Parsley wrote:
> I already scrub the environment when executing external scripts, and I've
> found that even after os.Unsetenv(...) the full environment is available to
> all processes owned by the robot in /proc//environ.

I'm a bit hesitent to enter this already-too-heated discussion, but I 
think this point here is important.

Yes, a process can clear or sanitize its environment, and once done that 
is done you can be confident the variables won't be propagated to child 
processes. It is important that this be done as early as possible, of 
course.

But this sanitization does not necessarily clean up the _original_ 
environment passed in from the kernel, and this memory is still readable 
to other processes running as that user through that /proc/$pid/environ 
file. Certainly, glibc's environment-manipulation functions (i.e. 
setenv(3), putenv(3), unsetenv(3) and clearenv(3)) do not overwrite it.

If a process wants to hide this content, it needs to explicitly overwrite 
this memory or change its address range using prctl(2). Maybe you can 
investigate whether this is possible in Python.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] When does a systemctl start ... returns to prompt?

[Michael Chapman]

On Wed, 29 Aug 2018, Wojtek Swiatek wrote:
> Le mer. 29 août 2018 à 10:03, Michael Chapman  a
> écrit :
> 
> Thank you for the clarification.
> 
> 
> > > Question 2: how can I configure the prog_two/prog_three case, i.e. having
> > > them starting one after the other (= start prog_three when prog_two is
> > > done), and have the prompt return immediately
> >
> > You can use "systemctl --no-block" to have systemctl not wait for the
> > service to finish activating. The downside to this is that you will have
> > no indication of a problem if the service fails during activation.
> >
> 
> But I will still see it via systemctl status prog_two.service, right? Since
> this usage (at least for me) only happens when testing, it would be fine
> (normally the service is ran via a timer so the problem of the prompt not
> returning does not matter)

Yes, a service activation failure will still be visible in "systemctl 
status".

> Again thank you for the help, it clarified a lot.
> 
> Cheers
> Wojtek

Glad to help!___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] When does a systemctl start ... returns to prompt?

[Michael Chapman]

On Wed, 29 Aug 2018, Wojtek Swiatek wrote:
> Hello everyone
> 
> systemctl start myserv.service sometimes immediately returns to the shell
> prompt and sometimes stays until the program is done. Specifically, taking
> the example of two programs
> 
> - prog_one which starts in the foreground and never ends, defined as
> ExecStart=/path/to/prog_one
> 
> - prog_two and prog_three which are defined as
> Type=oneshot
> ExecStart=/path/to/prog_two
> ExecStartPost=/path/to/prog_three
> 
> systemctl start prog_one.service immediately returns (and prog_one keeps
> running)
> systemctl start prog_two.service does not return, waits until prog_two and
> then progr_three finish before returning
> 
> If I do not use a Type in the prog_one unit, the unit fails because
> prog_three is started right after prog_one is initialized (and still
> running)
> 
> Question 1: what are the rules for systemctl start ... to immediately come
> back to the prompt or not

systemctl waits until the service has finished activating. As you've 
noted, this is governed by the Type property. For a Type=oneshot service, 
the service finishes activating once all of its ExecStartPre=, ExecStart= 
and ExecStartPost= commands have exited successfully.

Essentially, it's exactly the same rule used by the ordering properties 
After= and Before=.

> Question 2: how can I configure the prog_two/prog_three case, i.e. having
> them starting one after the other (= start prog_three when prog_two is
> done), and have the prompt return immediately

You can use "systemctl --no-block" to have systemctl not wait for the 
service to finish activating. The downside to this is that you will have 
no indication of a problem if the service fails during activation.

Another option is to change a Type=oneshot service to Type=simple. In this 
case systemd does not wait for any startup notification from the 
ExecStart= command; it proceeds to execute any ExecStartPost= commands 
immediately.

However, take note that Type=simple services can have only a single 
ExecStart= command.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Restarting a service as user instead as root

[Michael Chapman]

On Mon, 13 Aug 2018, Cecil Westerhof wrote:
> 2018-08-13 11:51 GMT+02:00 Michael Chapman :
> 
> > On Mon, 13 Aug 2018, Cecil Westerhof wrote:
> > > I have a service that is run as a different user as root. But only root
> > can
> > > restart the service. Is there a way to make 'systemctl restart' work for
> > > the user that runs the service?
> >
> > You could simply add some Sudo rules allowing the user to perform that
> > command.
> >
> > Alternatively, you can write a polkit rule to describe the permissions.
> > For example, the following would give permission for a particular
> > user to restart a particular service:
> >
> > polkit.addRule(function(action, subject) {
> > if (action.id == "org.freedesktop.systemd1.manage-units" &&
> > action.lookup("unit") == "example.service" &&
> > action.lookup("verb") == "restart" &&
> > subject.user == "username") {
> > return polkit.Result.YES;
> > }
> > });
> >
> > See the AUTHORIZATION RULES section of the polkit(8) manpage for further
> > details.
> >
> 
> I tried to put this in:
> /etc/polkit-1/rules.d/10-auth.rules
> 
> When reading:
> https://www.freedesktop.org/software/polkit/docs/latest/polkit.8.html
> AUTHORIZATION RULES
> 
> It should work immediately after writing the file, but it does not.
> Is there something else I should do?
> 
> I am using Debian 9.

It should work immediately. polkitd will log that it is reloading the 
rules. I suggest you check the log... maybe there's some syntax error or 
other problem with your rule file.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Restarting a service as user instead as root

[Michael Chapman]

On Mon, 13 Aug 2018, Cecil Westerhof wrote:
> I have a service that is run as a different user as root. But only root can
> restart the service. Is there a way to make 'systemctl restart' work for
> the user that runs the service?

You could simply add some Sudo rules allowing the user to perform that 
command.

Alternatively, you can write a polkit rule to describe the permissions. 
For example, the following would give permission for a particular 
user to restart a particular service:

polkit.addRule(function(action, subject) {
if (action.id == "org.freedesktop.systemd1.manage-units" &&
action.lookup("unit") == "example.service" &&
action.lookup("verb") == "restart" &&
subject.user == "username") {
return polkit.Result.YES;
}
});

See the AUTHORIZATION RULES section of the polkit(8) manpage for further 
details.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Restarting a systemd service with new command line options from systemctl?

[Michael Chapman]

On Sat, 7 Jul 2018, Rick Beldin wrote:
[...]
> # systemctl restart systemd-udevd --debug
> systemctl: unrecognized option '--debug'

You would need to override the service's ExecStart= setting if you wanted 
to do it that way.

> Is there a more supported way of doing this with systemctl for systemd-udevd,
> perhaps in general for all systemd services?   I tend to think that there
> isn't, but thought I would I ask.

For udev in particular you can use:

udevadm control --log-priority=debug

to change its log level without restarting it.

All of systemd's components will default to a debug log level if "debug" 
or "systemd.log_level=debug" appears on the kernel command-line, or if 
their environment contains "SYSTEMD_LOG_LEVEL=debug". You could implement 
the latter for specific services with drop-in files.

For the the systemd manager itself, you can also bump its log level by 
sending it SIGRTMIN+22 (documented in the systemd(1) manpage).
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] getgroups returning a diferent result

[Michael Chapman]

On Fri, 15 Jun 2018, Jérémy Rosen wrote:
> Partial answer, I don't know all the details...
> 
> We are all taught in school that each unix user belongs to to a certain number
> of groups, and that is defined in /etc/passwd.
> 
> That's kinda true, but it's an oversimplification.
> 
> Each PROCESS has a user and a set of groups. Those groups are set when login
> (or whoever does the login process) switch
> from running as root to running as your user. At that point, it will
> explicitely read /etc/passwd, set the correct groups then
> switch to the final UID (which can't change groups anymore)
> 
> This is the normal process when you login, but its a convention, not something
> that is enforced by the kernel.
> 
> IIUC systemd does not do that for services. Services only have a UID, a main
> GID but no supplementary GIDs.
> 
> Supplementary GID must be set explicitely with SupplementaryGroups= in
> [Service] They won't be read from /etc/passwd
> 
> That's my understanding, at least, someone else might know better...

systemd does call initgroups(3) -- which populates a process's 
supplementary group list -- but only when the GID is _not_ 0. There's a 
comment in the code that it is to avoid an NSS lookup in this case, though 
I must admit I don't know the full rationale for it.

It's probably got something to do with the fact that the group database 
in NSS won't necessarily be available early during boot, especially if 
it's backed onto some network service.___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] option to wait for pid file to appear

[Michael Chapman]

On Thu, 7 Jun 2018, Igor Bukanov wrote:
> On 18 May 2018 at 19:37, Lennart Poettering  wrote:
> > On Do, 17.05.18 22:54, Igor Bukanov (i...@mir2.org) wrote:
> > Well, no. The protocol is clear, and what we do is pretty close to
> > black magic, and still racy in many ways.
> >
> > I mean, broken behaviour is still broken behaviour, even if we
> > nowadays handle it pretty nicely. Really, nginx should be fixed,
> > everybody benefits, sysvinit as much as we do.
> 
> It turned out it is not only nginx that behaves this way. Any program
> that is using the daemon(3) call available both in Linux and BSD
> writes the pid from the child without the parent waiting. So this
> behaviour must be widespread and as such I think must be accepted as a
> de-facto standard (even if it is unfortunate) and systemd should not
> even warn about it.

I would agree. There's nothing the end user can really do about it, and 
they're more likely to complain here about it than the problematic 
software.

For what it's worth, I took a look at the Type=pid-file idea again... and 
I'm not sure if I'm going to be able to do it. The problem is primarily 
the way systemd only tracks up to one "control" process and one "main" 
process, and that with Type=pid-file it's not clear at the outset whether 
the process spawned by systemd is one or the other. I don't think starting 
it off as a control process and then converting it to a main process -- if 
and only if it writes its own PID out -- is the right approach.

So I might have to leave this idea for now, unless I can think of some way 
around this. Sorry if you were waiting on it.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] option to wait for pid file to appear

[Michael Chapman]

On Thu, 17 May 2018, Igor Bukanov wrote:
> On 17 May 2018 at 12:07, Michael Chapman <m...@very.puzzling.org> wrote:
> > It _is_ better for the PID file to be written out before the initial
> > process exits, but systemd will handle things correctly even if they
> > happen the other way around. Essentially the service won't be considered
> > to have completed activation until both events occur. If one or the other
> > takes too long (i.e. longer than the TimeoutStartSec= setting), the unit
> > will fail.
> 
> Does it means that even ExecStartPost and especially ExecReload can
> always safely use $MAINPID? I.e. does systemd call these Execs only
> after it managed to read the the pid file even when the file is
> written after the initial ExecStart process exited?

So it looks like systemd will add the MAINPID environment variable any 
time it knows what the main PID is. It learns this by reading the PID 
file, or if PIDFile= is omitted by guessing. It forgets it when it sees 
the SIGCHLD from that PID and no new PID file is available.

So by the time ExecStartPost runs, the main PID may or may not be known. 
Indeed, it's permitted for the PID file to be written out by ExecStartPost 
itself.

For ExecReload, though, there definitely should be a known main PID. I 
can't see any way you can get systemd to reload a service whose main PID 
hasn't been determined (or guessed). ExecReload may cause systemd to 
forget the main PID, if it makes the process exit, but it will be run with 
$MAINPID set.

> And yes, Type=pid-file will be very useful. I have exactly a shell
> script that will benefit from it nicely.

I'll dig it out and see what I can do. It's probably bitrotted quite a bit 
since I wrote it -- I never completed it because my own need for it went 
away.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] option to wait for pid file to appear

[Michael Chapman]

On Thu, 17 May 2018, Igor Bukanov wrote:
> Hi,
> 
> I have a service unit for nginx that uses Type=forking and PIDFile.
> That works, but occasionally I see in the log a message like
> 
> nginx.service: PID file /run/nginx/nginx.pid not readable (yet?) after
> start: No such file or directory
> 
> After investigating this father I see the reason for this is that
> nginx creates the pid file in a child process, not in the parent (at
> least this is how I interpret their code). As the parent may exit and
> systemd may respond to it before the child writes the pid, that leads
> to the above message.

The message is essentially harmless, at least when you're talking about 
initial service startup.

It _is_ better for the PID file to be written out before the initial 
process exits, but systemd will handle things correctly even if they 
happen the other way around. Essentially the service won't be considered 
to have completed activation until both events occur. If one or the other 
takes too long (i.e. longer than the TimeoutStartSec= setting), the unit 
will fail.

I think the only time this is actually a problematic situation is if the 
service is in a fully activated state, and the main process goes away 
before its replacement writes out a new PID file. There's a window there 
when systemd can think that the main process has simply decided to exit 
itself. In this case it will stop the unit.

On the other hand, if this sequence of events was initiated because the 
admin explicitly reloaded the service through systemd, then again systemd 
will, as far as I know, be happy with these two events happening in the 
wrong order. I'd need to check the code more thoroughly to be sure of this 
though.

For what it's worth, there is an "introduce Type=pid-file" item in the 
systemd TODO that seems like it would help with these kinds of problematic 
services. I see value in having something that simply waits for a PID file 
to appear, and doesn't care whether any processes exited in the meantime.

As an example use-case, authors of scripts currently need to use 
systemd-notify and NotifyAccess= to implement reliable service startup 
notification. With Type=pid-file, however, they could just do:

  #!/bin/sh

  # Run various setup stuff, possibly "exit 1"
  # if there's a problem ...

  # All good, tell systemd we're active
  echo $$ >/run/some-script.pid

  # ...

As it happens, I actually have some code to implement Type=pid-file, but I 
never got around to finish cleaning it up and raising a pull request. I 
should probably dig it out and raise a PR.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Stacked automount dependencies

[Michael Chapman]

On Fri, 30 Mar 2018, Kenneth Porter wrote:
I need to automount a couple cifs shares on a NAS box, with one share mounted 
to a directory within another share:


/srv/share0/share1


This probably isn't going to work the way you want. Starting the share1 
automount will itself cause share0 to be mounted, since systemd needs to 
ensure that the share1 directory exists, and to mount an autofs 
filesystem at this directory.


If you stack automounts in this way, the "inner" automount essentially 
keeps the "outer" mount permanently in use.


I've created the unit files for .mount and .automount for the two shares, 
with mount disabled and automount enabled and started. This seems to work 
fine once the system is booted. But the share1 automount fails to start on 
boot with the error "dependency". The share0 automount is started and works 
when the mount point is later accessed, but not the share1 automount.


I don't know what to add to satisfy the boot-time dependency of 
srv-share0-share1.automount.


From the boot log, it looks like the system is trying to actually mount 
these shares. But the server they're being mounted from may not be up yet 
when both are powering up together. That's why I'm using an automount.


Mar 26 18:29:14 saruman kernel: CIFS VFS: Error connecting to socket. 
Aborting operation.
Mar 26 18:29:14 saruman kernel: CIFS VFS: cifs_mount failed w/return code = 
-113

Mar 26 18:29:14 saruman mount: Unable to find suitable address.
Mar 26 18:29:14 saruman systemd: srv-share0.mount mount process exited, 
code=exited status=32

Mar 26 18:29:14 saruman systemd: Failed to mount NAS1 share0.


So what's happening here is that systemd is trying to mount share0, which 
is failing...



Mar 26 18:29:14 saruman systemd: Dependency failed for Automount NAS1 share1.
Mar 26 18:29:14 saruman systemd: Job srv-share0-share1.automount/start failed 
with result 'dependency'.


... which means it can't start the automount inside it.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd-sysusers

[Michael Chapman]

On Mon, 5 Feb 2018, Reindl Harald wrote:

Am 05.02.2018 um 06:56 schrieb Michael Chapman:

 On Mon, 5 Feb 2018, Johannes Ernst wrote:

 It appears systemd-sysusers does not create home directories. On the
 other hand, it picks (largely unpredictable) UIDs from a range.

 So I have to run systemd-sysusers, and after that, find the UID of the
 user and chown the home directory? Or is there the equivalent of the
 “useradd -m” flag somewhere that I’m just not seeing?


 systemd-sysusers is, as the name suggests, really for _system_ users, and
 often those kinds of users don't have ordinary home directories -- that
 is, ones the user can actually write to.

 However, systemd-sysusers.service is ordered before
 systemd-tmpfiles-setup.service at boot, so if you need to create a system
 user's home directory and ensure its ownership is correct, you could use a
 corresponding tmpfiles.d fragment to do so.


i hope you meant systemd-tmpfiles-setup.service is ordered before 
systemd-sysusers.service and you simply talked about "Before=" which in fact 
means ordered after


Sorry, I cannot work out what you are saying.

Take a look at the unit files as shipped in systemd. 
systemd-tmpfiles-setup.service is ordered After=systemd-sysusers.service 
(which is, as far as I can tell, equivalent to what I said before). It 
needs to be that way around for a tmpfiles.d fragment to be able to 
reference a user created by systemd-sysusers.___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd-sysusers

[Michael Chapman]

On Mon, 5 Feb 2018, Johannes Ernst wrote:
It appears systemd-sysusers does not create home directories. On the 
other hand, it picks (largely unpredictable) UIDs from a range.


So I have to run systemd-sysusers, and after that, find the UID of the 
user and chown the home directory? Or is there the equivalent of the 
“useradd -m” flag somewhere that I’m just not seeing?


systemd-sysusers is, as the name suggests, really for _system_ users, and 
often those kinds of users don't have ordinary home directories -- that 
is, ones the user can actually write to.


However, systemd-sysusers.service is ordered before 
systemd-tmpfiles-setup.service at boot, so if you need to create a system 
user's home directory and ensure its ownership is correct, you could use a 
corresponding tmpfiles.d fragment to do so.___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Again, why this strange behavior implied by "auto" in fstab ?

[Michael Chapman]

On Thu, 25 Jan 2018, Thomas Blume wrote:
[...]

Suppressing the auto mount when a device (re)appears, is usually desired
during some administrative tasks.
What about lowering the hurdle for administrators by introducing a new
systemctl command?

Maybe something like:

systemctl lock $DEVICE

We could write the name of $DEVICE in some directory below /run/systemd.
An udev rule could parse this directory when an add event for a device
occurres and if $DEVICE matches, it could set SYSTEMD_READY=0.
We would only need to make sure that SYSTEMD_READY gets reset back to 1 at 
an:


systemctl unlock $DEVICE

That shouldn't be too hard to code either.

Would this be an acceptable approach?


You could just use:

  systemctl --runtime mask path-to-mountpoint.mount

Or even:

  systemctl --runtime mask /path/to/mountpoint

if systemd already has the mount unit loaded. That should prevent the 
mount unit from being started -- i.e. prevent systemd from mounting the 
filesystem.


The --runtime option ensures that the mask will go away upon the next 
reboot, even if the admin forgets to call "systemctl --runtime unmask".

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

Re: [systemd-devel] systemctl is-active command returns inactive even if the unit does not exist

[Michael Chapman]

On Thu, 25 Jan 2018, Kevin Hsu wrote:

Hi folks,

"systemctl is-active" command gives "inactive" no matter the unit exists
and indeed inactive or it just not exist. This behavior is semantically
true since a unit can never be active
if it does not exist. But "systemctl is-enabled" command will give a clear
result "Failed to get unit file state for no-exist.service: No such file or
directory" to indicate user the existence
of the given unit. I am wondering if "systemctl is-active" should behave
the same.


I don't think it would be possible to change what "systemctl is-active" 
prints out now, and I think it makes sense for it to track the ActiveState 
property of the unit precisely.


You can get the properties of a unit using "systemctl show". For example:

  $ systemctl show --property LoadState,ActiveState,SubState \
does-not-exist.service
  LoadState=not-found
  ActiveState=inactive
  SubState=dead

As you can see here, what you're interested in is the "load state" of the 
unit, which is somewhat orthogonal to the unit's "active state".

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

Re: [systemd-devel] SSL handshake error from offlineimap when using systemd to initialize

[Michael Chapman]

On Wed, 24 Jan 2018, Yubin Ruan wrote:

On Mon, Jan 22, 2018 at 01:54:36PM +0100, Lennart Poettering wrote:

On So, 21.01.18 19:12, Yubin Ruan (ablacktsh...@gmail.com) wrote:


Hi,

I use offlineimap to synchronize my emails. I want it to do a synchronization
at system startup so recently I add a systemd service for it. However I always
get error like this:

   EOF occurred in violation of protocol (_ssl.c:590)


This suggests your network doesn't work when you invoke this.


1. usually (after system startup) the same service is invoked by a timer
and it works well so there is no problem with the script.

2. I believe the network is reachable, because the system will
auto-connect WIFI after system startup. Maybe the initialization order is
not configured properly? If so please see my mail service file
below.


Well, this is necessarily racy: your network setup races agains your
offlineimap invocation...


I got in the configuration file

 [Unit]
 After=network.target

Isn't this enough to get the initialization order right?


No, network.target is mostly about ordering things correctly during 
shutdown.


You need to do two things:

* Use After=network-online.target in your unit.
* Enable some _other_ service that detects when the network is "online" 
(whatever that means), and that is ordered Before=network-online.target.


If you are using systemd-networkd, for instance, this service is 
systemd-networkd-wait-online.service. If you are using NetworkManager, you 
want NetworkManager-wait-online.service.


See https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/ for 
further details.

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

Re: [systemd-devel] systemctl start second.service first.service

[Michael Chapman]

On Fri, 12 Jan 2018, Andrei Borzenkov wrote:

12.01.2018 03:47, 林自均 пишет:

How about adding an "--order" option to systemctl? With this option,
systemctl will sort those units by ordering dependencies before submitting
them.


And why does it matter? If unit A can be started without unit B, why
does it matter in which order they are started? If unit A can *not* be
started without unit B, it must tell so using Requires or Requisite.


I actually do think there is merit having this _always_ done with a single 
transaction.


Just because you want ordering doesn't necessarily you care about 
requirements. You may have a set of Type=oneshot units, for instance, and 
you don't particularly care whether any of them fail, but they must be run 
in a particular order. Currently, you need to make sure that order is 
reflected in the systemctl arguments. It would be nice for the order to be 
derived correctly from their ordering dependencies.


With all jobs in a single transaction, you could use systemctl's 
--job-mode=fail option to determine whether the _entire_ transaction is 
safe to be applied. This would honor Conflicts= in units without requiring 
the user to list units in the correct order.


Thinking somewhat further ahead, I can imagine their might even be a 
use-case for having transactions represented in the DBus API. That way a 
client could build a transaction (start this unit, stop that unit, etc.), 
and apply it all at once.___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Default reply to the mailing-list instead of sender

[Michael Chapman]

On Tue, 19 Dec 2017, Cecil Westerhof wrote:

With most mailing-lists when replying with GMail a reply is default send to
the mailing-list, but with this mailing-list it is default send to the
sender. Would it be possible to change this?


Just use the "Reply all" functionality of your email client. I would be 
surprised if Gmail couldn't do this.


Recipients can elect to deduplicate the mail either on their local mail 
system or on the list server itself (by setting the "Avoid duplicate 
copies of messages?" option in their list preferences).


Mailman-based lists default to keeping the sender's From and Reply-to 
headers intact. Some of the reasons are described at:


  http://www.unicom.com/pw/reply-to-harmful.html

It's not mentioned there, but one thing I find nice about lists 
implementing this policy is that in many cases it allows me to post to the 
list, and get replies, without needing to be subscribed. This is handy for 
those times when you only have a one-off question.

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

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

[Michael Chapman]

On Sun, 10 Dec 2017, Bjørn Forsman wrote:

On 9 December 2017 at 06:56, Andrei Borzenkov  wrote:

[...]
Firmware is unaware of MD RAID and each partition is individually and
independently writable by firmware.


1. "Firmware is unaware of MD RAID". I agree.
2. "... independently writable by firmware". I don't expect firmware
to _write_ to the ESP (does it?!). As long as it only reads, nothing
will get out of sync.


It's perhaps unlikely for firmware itself to write to the ESP, but 
certainly anything launched from the firmware can. One of my boot entries 
is an EFI shell, and it can move, copy, read and write files within the 
ESP.


I think it's probably wise to avoid software RAID for the ESP.___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] How to run forking daemon with systemd in correct way, without errors?

[Michael Chapman]

On Thu, 23 Nov 2017, Gena Makhomed wrote:

On 23.11.2017 7:45, Mantas Mikulėnas wrote:


This is bug in nginx code? And this bug should be fixed in nginx?

But "daemon(); write_pidfile();" is common pattern
used by many services and even in library functions.



It may be common, but not necessarily correct. The parent process should
only exit *after* finishing all the preparations (i.e. something like
"fork(); write_pidfile(); exit()"), since systemd uses the exit as a signal
that the daemon is now "ready".


You are joking? Why you think that this pattern is not correct?


Based on my understanding of the code, Type=forking services are not 
deemed to be active until it sees _both_ the process has exited and the 
PID file has appeared (so long as systemd is actually told about the PID 
file, of course).


It should not matter whether a Type=forking service's initial process 
exits first or writes its PID file first. If the PID file is missing when 
the process exits, systemd will log a "PID file ... not readable (yet?)" 
message, and it will keep the service in an "activating" state until it 
actually becomes readable.


In short, either design should work correctly.

However, there is something to be said for only writing out the PID file 
after the initial process has confirmed the service is operating 
correctly. This is possible with fork() (and some kind of IPC or signal 
between the child process and the original process) but not with daemon(). 
daemon() always exits successfully, which means other process managers 
that don't PID files like systemd does would assume the process had 
started successfully, even if the service's child process died straight 
away.


Many other deficiencies with the BSD daemon() function are documented in 
systemd's daemon(7) manpage.


I would suggest ignoring some other commenters suggestions that PID files 
are unnecessary with systemd. Indeed, there's even a TODO item for a 
Type=pid-file service that would, presumably, allow even non-forking 
services to signal readiness by writing a PID file. I would find something 
like that very useful.___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemctl --user user can't restart their own service?

[Michael Chapman]

On Sat, 18 Nov 2017, Jeff Solomon wrote:

When I run:

  systemctl --user daemon-reexec

I see that the daemon gets a --deserialize flag in it command line on "top"
but the PID is not any different. I guess I don't need the PID to change if
the process picks up any changes to its unit file.


The systemd process simply reexecutes itself. It doesn't fork, so it 
doesn't get a new PID.



I would want to use this command for exactly the reason you specify
Michael. The user@.service file might change and we want to make use of it
immediately. Also, we're only using lingering, so logging out and in
doesn't apply to us.


This won't pick up changes to the user@.service unit loaded into the 
system-wide systemd instance. There shouldn't be any reason to change 
this unit.

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

Re: [systemd-devel] systemctl --user user can't restart their own service?

[Michael Chapman]

On Sat, 18 Nov 2017, Jeff Solomon wrote:

Hi,

Is it by-design that a user can't restart their own user service?


If they aren't a lingering user, they'll get a new systemd instance if 
they completely log out and back in again.


Alternatively, they can restart the running instance with:

  systemctl --user daemon-reexec

This serializes state across the re-execution, so services running in the 
instance are not killed.


There's few reasons a user might want to do this however. The only one I 
can think of is where the admin had updated the systemd package and the 
user wanted to make use of it immediately.

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