From: "Ludovic Courtès" <ludo@gnu.org>
To: 35550@debbugs.gnu.org
Cc: sirgazil <sirgazil@zoho.com>
Subject: bug#35550: Installer: wpa_supplicant fails to start
Date: Fri, 03 May 2019 22:51:31 +0200 [thread overview]
Message-ID: <875zqr8dnw.fsf@gnu.org> (raw)
In-Reply-To: <87sgtv8hcz.fsf@gnu.org> ("Ludovic \=\?utf-8\?Q\?Court\=C3\=A8s\=22'\?\= \=\?utf-8\?Q\?s\?\= message of "Fri, 03 May 2019 21:31:40 +0200")
Ludovic Courtès <ludo@gnu.org> skribis:
> 678 May 3 16:03:40 localhost vmunix: [ 10.221211] shepherd[1]: Service dbus-system has been started.
> 679 May 3 16:03:40 localhost vmunix: [ 10.222093] shepherd[1]: Service loopback has been started.
> 680 May 3 16:03:40 localhost wpa_supplicant[398]: Successfully initialized wpa_supplicant
> 681 May 3 16:03:40 localhost shepherd[1]: Service wpa-supplicant could not be started.
> 682 May 3 16:03:40 localhost shepherd[1]: Service networking depends on wpa-supplicant.
> 683 May 3 16:03:40 localhost shepherd[1]: Service networking could not be started.
> 684 May 3 16:03:40 localhost wpa_supplicant[400]: dbus: Could not request service name: already registered
> 685 May 3 16:03:40 localhost wpa_supplicant[400]: Failed to initialize wpa_supplicant
> 686 May 3 16:03:45 localhost shepherd[1]: Service wpa-supplicant could not be started.
My guess is that it goes like this:
1. shepherd starts ‘networking’, which triggers the start of
‘wpa-supplicant’ (PID 398), which immediately “fails”. Thus
‘networking’ is not started.
2. shepherd continues and starts ‘wpa-supplicant’ directly (PID 400).
This time it fails for good; after 5 seconds, since the PID file
didn’t show up, shepherd says again that it could not be started.
Indeed, by looking at shepherd.conf from:
guix gc -R $(guix system build gnu/system/install.scm) | grep shepherd.conf
one can see that ‘networking’ comes before ‘wpa-supplicant’ in the expression:
(for-each start '(… networking … wpa-supplicant …))
So why is ‘wpa-supplicant’ marked as failing to start on the first
attempt?
The only reason I can think of is if ‘read-pid-file’ from (shepherd
service) returns immediately and returns #f instead of a number. That
can actually happen if the PID file exists but is empty (or contains
garbage).
You would expect wpa_supplicant to create its PID file atomically: write
it under a different name, then rename(2)… but no:
--8<---------------cut here---------------start------------->8---
int os_daemonize(const char *pid_file)
{
#if defined(__uClinux__) || defined(__sun__)
return -1;
#else /* defined(__uClinux__) || defined(__sun__) */
if (os_daemon(0, 0)) {
perror("daemon");
return -1;
}
if (pid_file) {
FILE *f = fopen(pid_file, "w");
if (f) {
fprintf(f, "%u\n", getpid());
fclose(f);
}
}
return -0;
#endif /* defined(__uClinux__) || defined(__sun__) */
}
--8<---------------cut here---------------end--------------->8---
So there is a possibility, albeit unlikely, for shepherd to see the PID
file after it’s been open but before it’s been written to. (This
problem is not limited to the installer.)
I’m not 100% convinced that this is what’s happening there but that’s
the only lead I have. I’m surprised we haven’t seen other reports
before.
Thoughts?
Ludo’.
next prev parent reply other threads:[~2019-05-03 20:52 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-03 19:31 bug#35550: Installer: wpa_supplicant fails to start Ludovic Courtès
2019-05-03 20:51 ` Ludovic Courtès [this message]
2019-05-04 15:28 ` Ludovic Courtès
2019-05-05 20:26 ` Ludovic Courtès
2019-05-05 22:21 ` Ludovic Courtès
2019-05-06 19:47 ` pelzflorian (Florian Pelz)
2019-05-07 7:53 ` Ludovic Courtès
2019-05-06 20:00 ` Danny Milosavljevic
2019-05-07 8:05 ` Ludovic Courtès
2019-05-08 14:32 ` Ludovic Courtès
2019-05-08 22:25 ` Ludovic Courtès
2019-05-09 6:46 ` pelzflorian (Florian Pelz)
2019-05-09 10:18 ` Ludovic Courtès
2019-05-11 18:13 ` Ludovic Courtès
2019-05-03 21:26 ` Ricardo Wurmus
2019-05-04 3:26 ` sirgazil
2019-05-04 12:49 ` Ludovic Courtès
2019-05-04 14:07 ` pelzflorian (Florian Pelz)
2019-05-04 15:32 ` Ludovic Courtès
2019-05-04 15:47 ` pelzflorian (Florian Pelz)
2019-05-04 21:14 ` Ludovic Courtès
2019-05-04 21:34 ` pelzflorian (Florian Pelz)
2019-05-05 16:29 ` Ludovic Courtès
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=875zqr8dnw.fsf@gnu.org \
--to=ludo@gnu.org \
--cc=35550@debbugs.gnu.org \
--cc=sirgazil@zoho.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/guix.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.