I tried to run a service at boot that was about to check the NTFS partition from windows that sometimes don’t have its “dirty flag” removed each time it happens I have to reboot and it starts to p*** me off.
It doesn’t happen often but it happens each time I reboot from Windows (I’m dual booted).
The service I created is expected to run after target local-fs.target.
These are the directives I set:
[Unit]
Description=datas2 de merde
After=local-fs.target
[Service]
Type=oneshot
ExecStart=/usr/bin/datas2demerde
It is not an openSUSE problem. It is a Windows problem.
My solution:
Turn of fast boot in Windows.
When that doesn’t work, disable hibernation in Windows.
Another option: when you reboot from Windows, hold down the SHIFT key while clicking “Restart”. That is supposed to cause Windows to do a full shutdown.
No. There are three directories (actually more if we consider generators) where unit definitions are looked for; .wants is expected to contain symlinks into one of these directories. /usr/lib/systemd is intended for units installed by packages; local unit definitions should go into /etc/systemd. Other than that /usr/lib/systemd/system is correct.
I got a failure when trying to launch it.
You expect us to guess what failure it is?
It is enabled.
It cannot be enabled by definition. “Enabled” means “links in [Install] section are created” and your unit definition does not have [Install] section so it cannot be enabled.
Also, just because you condition your code to run “after” local-fs.target, there is nothing that determines how long after local-fs.target it will run. You need to use or add a stronger condition to encourage your code to run promptly.
This is one of the weird things about the systemd boot… To encourage parallelism and maximum efficiency very little is sequenced with certainty which could cause bottlenecks. Instead, everything is different levels of conditions letting the system sort out what needs to be done dynamically.
If you think your custom Unit file actually attempts to run, then you should determine its actual failure by searching previous bootlogs, something like the following
Surely not ^^
The system indicates me that the service has failed… journalctl gives nothing more than “exited with error”. That means to me “something in my way of trying to make a workaround has failed” ^^
sirius:/ # journalctl -u datas2demerde.service
– Logs begin at Sat 2020-08-22 21:10:05 CEST, end at Sat 2020-08-22 21:10:22 CEST. –
Aug 22 21:10:10 sirius systemd[1]: Failed to start datas2 de merde.
and
sirius:/ # systemctl status datas2demerde.service
● datas2demerde.service - datas2 de merde
Loaded: loaded (/usr/lib/systemd/system/datas2demerde.service; static; vendor preset: disabled)
Active: failed (Result: exit-code) since Sat 2020-08-22 21:10:10 CEST; 1h 20min ago
Main PID: 864 (code=exited, status=1/FAILURE)
Tasks: 0
CGroup: /system.slice/datas2demerde.service
Aug 22 21:10:10 sirius systemd[1]: Failed to start datas2 de merde.
Nothing more…
I think the “service” is not launched at the right time… anyway I will attack windows instead of poping my head on this ^^
When you post computer output you should use tags [noparse]
[/noparse], not quotation. Quotation is removed on replies which makes it hard to comment on specific lines.
I think the “service” is not launched at the right time…
That’s not how you troubleshoot problems. systemd did not fail to start your service - systemd correctly started your service and the program that was started exited with exit code 1. We cannot even claim that this program failed because exit code 1 may be correct for this program (but by convention any exit code not equal zero is considered failure indication). Read manual for the program that is started. What it does and what exit code is expected. If exit code 1 does mean failure, add more logging to your program to see what it does and at which point it exits.