Linux device unit inactive (dead) after systemctl daemon-reload
I used the solution proposed by galets in this post to add my own udev rule:
How to wait for a /dev/video0 before starting a service
When Linux boots, my device is detected, and the rule creates a sys-bus-pci-drivers-mydevice.device unit. I created a service which includes the BindsTo=sys-bus-pci-drivers-mydevice.device and Requires=sys-bus-pci-drivers-mydevice.device, and the service only loads once my hardware has been detected and its driver loaded. Perfect!
My problem is that whenever I perform any systemctl command to manage any services, my device unit goes into inactive (dead) state. For example:
systemctl daemon-reload
systemctl unmask whatever.service
Once any of these are executed, if I perform systemctl status sys-bus-pci-drivers-mydevice.device, it reports:
* sys-bus-pci-drivers-mydevice.device
Loaded: loaded
Active: inactive (dead)
Jan 25 09:25:41 FLABADO systemd[1]: Found device /sys/bus/pci/drivers/mydevice.
At this point, if I attempt to restart any service which includes the Requires= dependency, they fail. I have to reboot the system to recover.
I confirmed that the device is still present, its driver active, and commands that I execute that make use of the hardware all function perfectly.
I'd like to know if anyone has ever encountered this behavior, and if so, is there a way to avoid or recover from it without having to reboot?
I'm using Yocto 2.1 (Krogoth) to build my Linux distribution. Kernel version is 4.4.26-yocto-standard.
linux systemd udev yocto
edited Jan 27 at 16:23
filbranden
8,06121139
asked Jan 25 at 15:07
Jason CoteJason Cote
61
add a comment |
I used the solution proposed by galets in this post to add my own udev rule:
How to wait for a /dev/video0 before starting a service
When Linux boots, my device is detected, and the rule creates a sys-bus-pci-drivers-mydevice.device unit. I created a service which includes the BindsTo=sys-bus-pci-drivers-mydevice.device and Requires=sys-bus-pci-drivers-mydevice.device, and the service only loads once my hardware has been detected and its driver loaded. Perfect!
My problem is that whenever I perform any systemctl command to manage any services, my device unit goes into inactive (dead) state. For example:
systemctl daemon-reload
systemctl unmask whatever.service
Once any of these are executed, if I perform systemctl status sys-bus-pci-drivers-mydevice.device, it reports:
* sys-bus-pci-drivers-mydevice.device
Loaded: loaded
Active: inactive (dead)
Jan 25 09:25:41 FLABADO systemd[1]: Found device /sys/bus/pci/drivers/mydevice.
At this point, if I attempt to restart any service which includes the Requires= dependency, they fail. I have to reboot the system to recover.
I confirmed that the device is still present, its driver active, and commands that I execute that make use of the hardware all function perfectly.
I'd like to know if anyone has ever encountered this behavior, and if so, is there a way to avoid or recover from it without having to reboot?
I'm using Yocto 2.1 (Krogoth) to build my Linux distribution. Kernel version is 4.4.26-yocto-standard.
linux systemd udev yocto
edited Jan 27 at 16:23
filbranden
8,06121139
asked Jan 25 at 15:07
Jason CoteJason Cote
61
Doesudevadm info /sys/bus/pci/drivers/mydeviceafter it goes inactive (vs. after it's been working) give you any hints on what happened? Please also post the version of systemd in your system, that might be helpful information too.
– filbranden
Jan 27 at 16:28
udevadm info /sys/bus/pci/drivers/mydevice reports the same thing before and after the problem occurs: P: /bus/pci/drivers/mydevice E: DEVPATH=/bus/pci/drivers/mydevice E: SUBSYSTEM=drivers E: TAGS=:systemd: E: USEC_INITIALIZED=8424690 Systemd version is 229+git0+714c62b463.
– Jason Cote
Jan 28 at 17:42
add a comment |
I used the solution proposed by galets in this post to add my own udev rule:
How to wait for a /dev/video0 before starting a service
When Linux boots, my device is detected, and the rule creates a sys-bus-pci-drivers-mydevice.device unit. I created a service which includes the BindsTo=sys-bus-pci-drivers-mydevice.device and Requires=sys-bus-pci-drivers-mydevice.device, and the service only loads once my hardware has been detected and its driver loaded. Perfect!
My problem is that whenever I perform any systemctl command to manage any services, my device unit goes into inactive (dead) state. For example:
systemctl daemon-reload
systemctl unmask whatever.service
Once any of these are executed, if I perform systemctl status sys-bus-pci-drivers-mydevice.device, it reports:
* sys-bus-pci-drivers-mydevice.device
Loaded: loaded
Active: inactive (dead)
Jan 25 09:25:41 FLABADO systemd[1]: Found device /sys/bus/pci/drivers/mydevice.
At this point, if I attempt to restart any service which includes the Requires= dependency, they fail. I have to reboot the system to recover.
I confirmed that the device is still present, its driver active, and commands that I execute that make use of the hardware all function perfectly.
I'd like to know if anyone has ever encountered this behavior, and if so, is there a way to avoid or recover from it without having to reboot?
I'm using Yocto 2.1 (Krogoth) to build my Linux distribution. Kernel version is 4.4.26-yocto-standard.
linux systemd udev yocto
edited Jan 27 at 16:23
filbranden
8,06121139
asked Jan 25 at 15:07
Jason CoteJason Cote
61
I used the solution proposed by galets in this post to add my own udev rule:
How to wait for a /dev/video0 before starting a service
When Linux boots, my device is detected, and the rule creates a sys-bus-pci-drivers-mydevice.device unit. I created a service which includes the BindsTo=sys-bus-pci-drivers-mydevice.device and Requires=sys-bus-pci-drivers-mydevice.device, and the service only loads once my hardware has been detected and its driver loaded. Perfect!
My problem is that whenever I perform any systemctl command to manage any services, my device unit goes into inactive (dead) state. For example:
systemctl daemon-reload
systemctl unmask whatever.service
Once any of these are executed, if I perform systemctl status sys-bus-pci-drivers-mydevice.device, it reports:
* sys-bus-pci-drivers-mydevice.device
Loaded: loaded
Active: inactive (dead)
Jan 25 09:25:41 FLABADO systemd[1]: Found device /sys/bus/pci/drivers/mydevice.
At this point, if I attempt to restart any service which includes the Requires= dependency, they fail. I have to reboot the system to recover.
I confirmed that the device is still present, its driver active, and commands that I execute that make use of the hardware all function perfectly.
I'd like to know if anyone has ever encountered this behavior, and if so, is there a way to avoid or recover from it without having to reboot?
I'm using Yocto 2.1 (Krogoth) to build my Linux distribution. Kernel version is 4.4.26-yocto-standard.
linux systemd udev yocto
linux systemd udev yocto
edited Jan 27 at 16:23
filbranden
8,06121139
asked Jan 25 at 15:07
Jason CoteJason Cote
61
edited Jan 27 at 16:23
filbranden
8,06121139
asked Jan 25 at 15:07
Jason CoteJason Cote
61
edited Jan 27 at 16:23
filbranden
8,06121139
edited Jan 27 at 16:23
filbranden
8,06121139
edited Jan 27 at 16:23
filbranden
8,06121139
8,06121139
asked Jan 25 at 15:07
Jason CoteJason Cote
61
asked Jan 25 at 15:07
Jason CoteJason Cote
61
asked Jan 25 at 15:07
Jason CoteJason Cote
61
61
Doesudevadm info /sys/bus/pci/drivers/mydeviceafter it goes inactive (vs. after it's been working) give you any hints on what happened? Please also post the version of systemd in your system, that might be helpful information too.
– filbranden
Jan 27 at 16:28
udevadm info /sys/bus/pci/drivers/mydevice reports the same thing before and after the problem occurs: P: /bus/pci/drivers/mydevice E: DEVPATH=/bus/pci/drivers/mydevice E: SUBSYSTEM=drivers E: TAGS=:systemd: E: USEC_INITIALIZED=8424690 Systemd version is 229+git0+714c62b463.
– Jason Cote
Jan 28 at 17:42
add a comment |
Doesudevadm info /sys/bus/pci/drivers/mydeviceafter it goes inactive (vs. after it's been working) give you any hints on what happened? Please also post the version of systemd in your system, that might be helpful information too.
– filbranden
Jan 27 at 16:28
udevadm info /sys/bus/pci/drivers/mydevice reports the same thing before and after the problem occurs: P: /bus/pci/drivers/mydevice E: DEVPATH=/bus/pci/drivers/mydevice E: SUBSYSTEM=drivers E: TAGS=:systemd: E: USEC_INITIALIZED=8424690 Systemd version is 229+git0+714c62b463.
– Jason Cote
Jan 28 at 17:42
Does
udevadm info /sys/bus/pci/drivers/mydevice after it goes inactive (vs. after it's been working) give you any hints on what happened? Please also post the version of systemd in your system, that might be helpful information too.– filbranden
Jan 27 at 16:28
Does
udevadm info /sys/bus/pci/drivers/mydevice after it goes inactive (vs. after it's been working) give you any hints on what happened? Please also post the version of systemd in your system, that might be helpful information too.– filbranden
Jan 27 at 16:28
udevadm info /sys/bus/pci/drivers/mydevice reports the same thing before and after the problem occurs: P: /bus/pci/drivers/mydevice E: DEVPATH=/bus/pci/drivers/mydevice E: SUBSYSTEM=drivers E: TAGS=:systemd: E: USEC_INITIALIZED=8424690 Systemd version is 229+git0+714c62b463.
– Jason Cote
Jan 28 at 17:42
udevadm info /sys/bus/pci/drivers/mydevice reports the same thing before and after the problem occurs: P: /bus/pci/drivers/mydevice E: DEVPATH=/bus/pci/drivers/mydevice E: SUBSYSTEM=drivers E: TAGS=:systemd: E: USEC_INITIALIZED=8424690 Systemd version is 229+git0+714c62b463.
– Jason Cote
Jan 28 at 17:42
add a comment |
0
active
oldest
votes
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "106"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f496692%2flinux-device-unit-inactive-dead-after-systemctl-daemon-reload%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
0
active
oldest
votes
0
active
oldest
votes
active
oldest
votes
active
oldest
votes
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f496692%2flinux-device-unit-inactive-dead-after-systemctl-daemon-reload%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Does
udevadm info /sys/bus/pci/drivers/mydeviceafter it goes inactive (vs. after it's been working) give you any hints on what happened? Please also post the version of systemd in your system, that might be helpful information too.– filbranden
Jan 27 at 16:28
udevadm info /sys/bus/pci/drivers/mydevice reports the same thing before and after the problem occurs: P: /bus/pci/drivers/mydevice E: DEVPATH=/bus/pci/drivers/mydevice E: SUBSYSTEM=drivers E: TAGS=:systemd: E: USEC_INITIALIZED=8424690 Systemd version is 229+git0+714c62b463.
– Jason Cote
Jan 28 at 17:42