Skip to main content
Raspberry Pi

Timeline for Launch a Bluetooth Low Energy command after raspberry startup

Current License: CC BY-SA 4.0

15 events
when toggle format what by license comment
Oct 25, 2022 at 22:00 comment added goldilocks♦ ...For the win then you just parse all the other timer files at shutdown, find the longest one, and edit yours to run that + 1 :P
Oct 25, 2022 at 21:56 comment added goldilocks♦ ...A good reason for it not to work that way is: What if everyone want their service to run after (or before) all the others? You need to then ask why, and I guarantee the answer involves an XY problem (as does your example with cron) where the X is "because it depends on ______" -- which is why IMO a dynamic hierarchy based on dependencies is a good design. Not omnisciently perfect, of course. BTW, a solution to "run last" (or try to) in systemd would be via a timer (see man systemd.timer), these can be in relation to boot start.
Oct 25, 2022 at 21:55 comment added goldilocks♦ I agree that setting up a cron job is easier, and if cron can do everything you want, then use cron. I'd consider it more of an "end user" program than systemd; most linux users should never have to write a service file. WRT getting something to run absolutely last, this is sort of a "it doesn't work that way" thing, software design largely is about going with one opinion rather than another.
Oct 25, 2022 at 20:39 comment added Seamus @goldilocks Your answer reflects my opinion re systemd: "Can't promise this will solve your problem, but..." I'm not knocking your answer either, but I feel that systemd demands too much from many who might otherwise benefit from its advantages. I hope that's clear - and not offensive. I hold an opinion re systemd, that's all. I feel a simpler solution may be a better solution. I never (I hope) suggest that people ignore systemd - that they never consider it. But in my experience, systemd usually requires far more effort than setting up a cron job.
Oct 25, 2022 at 20:09 comment added Seamus @goldilocks: It seems we have a difference of opinion wrt systemd. You are imagining I'm saying something that I'm not really... perhaps getting down to cases will help: Do you think you know enough about systemd to have it start crond as the absolute last daemon during init? I tried to do that some time ago, and never got an answer. Starting crond after everything else is started would cover most cases - I think. But, for some reason - systemd does not allow one to do this - at least not in a straightforward manner.
Oct 25, 2022 at 19:52 comment added goldilocks♦ Or, going with sane convention: cron does what it does and cron is responsible for that, just like the python interpreter is responsible for what it does. You seem to be suggesting something truly monstrous, where the only thing you would need would be the perfect omniscient init system. If "arrogent mindset" means there's a lot of (provided) docs to read and concepts to grok regarding a very complex piece of software, then blessed be the arrogant mindset...
Oct 25, 2022 at 19:52 comment added goldilocks♦ "Do you feel it's useful for systemd to simply start crond at an arbitrary point, and then wash their hands of it"? The point is not arbitrary. Going beyond that, how should systemd control the minutiae of cron (and everything else I guess)? Should it read cron's config files to find out what it is going to do, then analyze the job specs there and somehow determine what the prereqs for myscript.py are? Well of course it could just read myscript.py and parse the import statements! This is all so simple and obvious!
Oct 25, 2022 at 18:55 comment added Seamus @goldilocks: The init job is a tough one. I would not argue that systemd offers the user no advantages. What I do feel is that there's an arrogant mindset behind it; I feel it could be so much better in terms of ease of use. I also feel that if you're going to "claim the throne", you should be a proper steward. Do you feel it's useful for systemd to simply start crond at an arbitrary point, and then wash their hands of it? You're absolutely correct in that there are options available, but as hard as I try I can't convince myself to feel badly about criticizing systemd :)
Oct 25, 2022 at 13:53 comment added goldilocks♦ So (and I am not knocking your answer, just trying to defang some confusion about OS fundamentals), what's "paradoxical" ;) ;) is to say, "I would like a dependency based boot service like systemd, but I do not want to use systemd". Kind of like saying you don't want to use Chrome as a web browser, but you then gripe about how all the other web browsers don't do the things Chrome does. A bad analogy in the sense that cron and systemd are much more dissimilar than a set of web browsers -- but note there are alternate init systems available to use (please don't act on that tho, lol).
Oct 25, 2022 at 13:48 comment added goldilocks♦ "It therefore seems odd that the systemd designers did not provide a method to allow cron users to communicate their job's service dependencies." -> It does, to the same extent that it does for other services. Of course, that is more about the cron daemon itself rather than anything it starts on its own -- which cron could have an interface like systemd to organize tasks in a hierarchy of dependencies (or it could query systemd about service states), but many people would be upset if it suddenly sprouted features of that sort.
Oct 25, 2022 at 13:37 comment added goldilocks♦ "In the paradox that is systemd design logic, the cron daemon is actually started/controlled by a systemd unit: -> Yes, but there's nothing paradoxical about it because: 1) Processes cannot start themselves, 2) The kernel only starts 1 process, init, which on contemporary GNU/Linux systems is impemented by systemd. Cron runs like any other kind of background service, that's what init is for (hence it is the common ancestor of every running process, pid 1). If it wasn't started by init/systemd, it would have to be started by something started by systemd.
Oct 25, 2022 at 6:32 comment added Seamus @Andrea: Yes, it's rather deep. I don't understand it well enough to explain why, but I've come to believe that designs that yield a difficult user experience are not great designs. But I suppose it's as good as we're going to get for a while.
Oct 25, 2022 at 5:30 vote accept Andrea
Oct 25, 2022 at 5:30 comment added Andrea Thank you for the explanation, I've tried and just by putting 60 seconds I was able to make it work!!! Weird stuff about systemd :-(
Oct 24, 2022 at 5:05 history answered Seamus CC BY-SA 4.0