# Why people uses cron job while kernel modules exist and why not services?



## fbsd_ (Jun 20, 2021)

1)Cron job: So cron job be able to run a process accordance with certain time intervals or whatever the desired shape is. It can be able to run most of file types or all type of languages probably. 
2)Kernel module: Kernel module also runs with kernel on the background. Its main target is making system useful and responsible to connected devices. Especially hardware developers spending a lot of time with them.
3)Service: A service can run on background and waits for something and then response to it.

So while thinking about that reasons I think kernel modules mostly targeting kernel operations and that would be one reason to not using them. Another reason is they writen on C/C++.
What about service?
I think that would be more useful to write programs as kernel modules like sleeping system at certain time. Like when a system developer wants to create a automatic sleep function which option is the best. If he uses cron job, users would want to use cron job because its useful for normal daily users to and then corrupt some system files.

Services seems to be best option is it?


----------



## mer (Jun 20, 2021)

My opinions only, based on writing software at both kernel and application level.

First:  apologies if this gets long.

The language used to implement functionality is a non-issue to me.  You use what you need to.  Something written in C/C++ is not a downside.  Language is a tool, use the right tool for the job.

As you recognize, kernel modules are for devices and "kernel stuff" like filesystems.  Some may be accessing the hardware, some may be providing a generic interface (think of generic usb interface and then a module that implements access to a specific usb device chipset).  zfs.ko provides the functionality to interface with ZFS devices.  Root access is typically required to load modules.

Cron basically runs any executable at any given interval:  every minute, the first day of every month, the second thursday at 3:33 am of every 3rd month.  Look at the "periodic" parts of the system.  Some you want to run daily, some weekly, some monthly.  Any executable already written can be run by a cron job (assuming the proper permissions), by any user (individual crontabs).

Services (or the "init" system) typically initialize and configure things during system boot up/shutdown/change of state.  These things can be widely different.  Take a look at /etc/rc.d at what is in there.  script that initializes and start firewalling,  script that starts DHCP client, starts jails, starts databases.

They all have their places where they are "best".  A lot depends on exactly what needs to be done, what is used to trigger the action and who is allowed to do that action.

You also need to keep in mind "how long does it wait"?
Stuff in the kernel, waiting milliseconds is a long time.
Cron:  if something is to be run on a regular time based pattern, you can set to run once a year at a specific day/date/time.
Services:  typically run startup, shutdown, change of system run level.  They may initialize other functionality (like devmatch/devd/devfs stuff), but they usually just spawn a process, record some information for later, then exit.  

Based on what you've written I don't know if anyone can say "what is the best option" for your use case.


----------



## zirias@ (Jun 20, 2021)

Tried a few times to really make sense of that, but, comparing cron with kernel modules, I guess I just have to give up. 

Anyways: cron _is_ a service, maybe this kind of helps…


----------



## ShelLuser (Jun 20, 2021)

Is OP really thinking it's a good idea to run, say, a mailqueue job as a kernel module and thus giving it potential root access to the whole system?


----------



## fbsd_ (Jun 20, 2021)

ShelLuser said:


> Is OP really thinking it's a good idea to run, say, a mailqueue job as a kernel module and thus giving it potential root access to the whole system?


Why not if it works for when system will sleep, which keypresses need to be recorded and reacted etc.


----------



## ralphbsz (Jun 21, 2021)

Programming in the kernel is hard. Debugging code in the kernel is very hard. Writing code that runs in the kernel so that it is secure is extremely hard. The general rule is: Put in the kernel what absolutely has to go into the kernel, everything else goes into user space.

When you are ready to write some program, the first step needs to be to think about the requirements: What does it need to accomplish? What is its job? Begin by writing that down. From those requirements, you can then derive the inputs and outputs of the program should be. From that you can figure out when the program needs to react, whether it can be driven by input, whether it needs to sleep and wake up on a regular schedule, or whether it should be started regularly. Another thing to consider is the volume of data that goes in and out, and how much processing is required (the jargon for that is "speeds and feeds"). Again, this will give you hints about how to implement it.


----------



## hardworkingnewbie (Jun 21, 2021)

@OP: Actually it is quite simple: you should only do in a kernel what needs to be done there. For the rest there is the userland.

*And there is really no need* whatsoever to run normal automation tasks in kernel space!


----------



## datasmurf (Jun 23, 2021)

hardworkingnewbie said:


> *And there is really no need* whatsoever to run normal automation tasks in kernel space!


This sounds like a new feature (request) to systemd to me.


----------



## astyle (Jun 23, 2021)

datasmurf said:


> This sounds like a new feature (request) to systemd to me.


Just tell systemd to start one more service (crond in this case). But no way will any sane admin try to run a mail server from the kernel! There's a reason for having a clean separation of kernel and userland. The less you have in the kernel, the better - why do you think FreeBSD is so incredibly stable and easy to troubleshoot?


----------



## SirDice (Jun 23, 2021)

This is important to understand: https://en.wikipedia.org/wiki/Protection_ring


----------



## astyle (Jun 23, 2021)

SirDice said:


> This is important to understand: https://en.wikipedia.org/wiki/Protection_ring


yeah, and this is frankly the basics... If you don't get even that, FreeBSD will be nothing more than a toy on your personal device.


----------



## datasmurf (Jun 23, 2021)

astyle said:


> Just tell systemd to start one more service (crond in this case). But no way will any sane admin try to run a mail server from the kernel! There's a reason for having a clean separation of kernel and userland. The less you have in the kernel, the better - why do you think FreeBSD is so incredibly stable and easy to troubleshoot?



Did you get that I was joking and mocking systemd a bit?


----------



## astyle (Jun 24, 2021)

datasmurf said:


> Did you get that I was joking and mocking systemd a bit?


Sorry, my remark was not aimed at you, datasmurf ... it was aimed at OP, with the idea to get OP to actually learn something. Sometimes, the best teacher is not a constructive suggestion but a sharp observation about how unforgiving real world can be.


----------



## fbsd_ (Jun 25, 2021)

datasmurf said:


> This sounds like a new feature (request) to systemd to me.


Are there systemd exist on FreeBSD? Because I just tried to locate it and then found nothing. Also take a look at internet too.
As what I understand from text I read is: On Unix and BSD it named as Daemon.
Also it have GPL-2.0(GNU) license like other Linux products so that would be the reason. So where is the daemon configuration?


----------



## Alain De Vos (Jun 25, 2021)

Maybe

```
/etc/rc.subr
```


----------



## mkernalcon (Jul 20, 2021)

I think I almost understand what you're asking:

Kernel code: as has been said, this is for what MUST be run in the kernel. Don't think of it as responding to hardware, think of it as the bare minimum interface to let userspace talk to your hardware. There are some serious security, stability, etc. problems with unnecessary code in the kernel - that's what userspace is for.

Cron jobs: run at regular intervals. Can't really "respond" to events, but might be used to check if an event has happened in the past

Services: Stay running and keep in touch with the inputs/outputs they need.

As for the specific problem of automatic sleeping, it depends on exactly what you mean. If you want your computer to go to sleep at 2am every morning, whether you are using it or not, that's exactly what a cron job is for. If you want your computer to go to sleep after 15 minutes of inactivity, that's a service - have a timer that resets every time something you consider to be "activity" happens, and if it hits 15 minutes, sleep. The kernel code would be just responsible for putting the computer to sleep when your service or cron job tells it to.

EDIT: And be glad FreeBSD doesn't have systemd. It's a mess, frankly.


----------



## astyle (Jul 20, 2021)

mkernalcon said:


> Cron jobs: run at regular intervals. Can't really "respond" to events, but might be used to check if an event has happened in the past


To me, if cron can actually check if an even has actually happened (as in, every 5 minutes run a script that checks logs for a specific event/value, that, in effect would be the same as saying 'Cron is responding to an event'. Yeah, it's a bit of logical daisy-chaining, but that's the UNIX philosophy of pipe, sed, grep.


----------



## ct85711 (Jul 21, 2021)

As with security, one of the most simplest concept in security (though hard to manage), is do as much as you can at the lowest/least permissions when possible.  The main reason is when sh$t hits the fan; it starts at that level and everything below it gets covered.  While people often refer root access as god mode, there are some things root can not directly manage (direct communicate with hardware).  The kernel on the other hand, could very well be considered as god's god; as the kernel has supreme control on the hardware; and has the final say what root can/cannot do.

Kernel modules area part of the kernel, so it tends to be at that level.  The nice part of cron jobs, is that you have the option of specifying the user level the job is ran at.  Services, are special as a lot of times they act like a sleeping beast, that wakes up to do it's task then go to sleep until it is needed again.  Just think about openssh, httpd, a database, even cron it's self are all services in that they sleep until they are needed.

Now, the part of things drop permissions, I consider that more of them giving you a "warm cozy feeling" that you are doing something.  The thing is, it does not change what the heart of the thing is.  Putting a tiger on a lease and in a cage, doesn't change the fact it is still a tiger and just as likely to rip your throat out when it gets a chance to.


----------



## fbsd_ (Jul 23, 2021)

ct85711 said:


> As with security, one of the most simplest concept in security (though hard to manage), is do as much as you can at the lowest/least permissions when possible.  The main reason is when sh$t hits the fan; it starts at that level and everything below it gets covered.  While people often refer root access as god mode, there are some things root can not directly manage (direct communicate with hardware).  The kernel on the other hand, could very well be considered as god's god; as the kernel has supreme control on the hardware; and has the final say what root can/cannot do.
> 
> Kernel modules area part of the kernel, so it tends to be at that level.  The nice part of cron jobs, is that you have the option of specifying the user level the job is ran at.  Services, are special as a lot of times they act like a sleeping beast, that wakes up to do it's task then go to sleep until it is needed again.  Just think about openssh, httpd, a database, even cron it's self are all services in that they sleep until they are needed.
> 
> Now, the part of things drop permissions, I consider that more of them giving you a "warm cozy feeling" that you are doing something.  The thing is, it does not change what the heart of the thing is.  Putting a tiger on a lease and in a cage, doesn't change the fact it is still a tiger and just as likely to rip your throat out when it gets a chance to.


Yea after some time. I think we have to choose the particular tool for the particular job. They all have good and bad sides. All useful for different jobs. Root privilege can be ridiculous for user-level apps, and once that's done, root is useless. While Service seems to be the best option for writing a program that automatically puts the computer into sleep mode after a while, kernel modules are the best for creating the connection between the hardware and the system.

And cron is also a service


----------

