pramodvu I have no idea HOW to implement it, as the '66 scandir' process SHOULD be in the user's sesson [idealy as the leader/1st process, but the the shell?], but/and ideally be supervised by the PID1's scandir.
This is simple, start a scandir@ then the user will be able to start services by itself. The service will create a nested scandir. That's mean that root and user service are completely separated. Each user need to have it own scandir@ instance service.
pramodvu In 66-dbus-launch, please support a config-file or 2, say, in /usr/lib/66/dbus-services.list and /etc/66/dbus-services.list [& corresponding user files], which in each line has the format "org.freedesktop.Foo dbus-foo", and by reading it 66-dbus-launch doesn't create a fresh frontend for 'org.freedesktop.Foo', instead starting 'dbus-foo' on it's activation, a service with it's own frontend in 66.
I'm not sure to understand your request.
Actually, 66-dbus-launch handle system service and user service, it just depends of how you launch the 66-dbus-launch program.
Frontend file for 66 is created on the fly of the corresponding dbus service when the service is activated by dbus. You can see the result at /etc/66/service for root or $HOME/.66/service for user. You can also see an example of the created frontend file at the documentation. This frontend file is not erased but overwritten by 66-dbus-launch at every activation of the service to be sure to use the latest declaration of the dbus service of the host. So, at the end 66 will use it own frontend file. That also means that you can control the service through 66 as you do for any other service.
vixalien I think 66 has user services. By default when you run 66 enable [something] as a normal user, this will enable it for you and not globally. But I agree this syntax is confusing and might lead to people enabling services as user services instead of system services. systemd has systemd --user to enable services for yourself, or systemd --global where an administrator can enable user services for all users at once. Maybe @eric can say their thoughts on this.
This is simple, any 66 command can be executed for root privileges or regular user. Doing 66 statusas root will give you root service overview and doing it as regular user will give you user service overview. That means that root CANNOT handle user service and user service CANNOT handle root service. If root what to deal with user service it need first to connect with the regular user of his choice.
Maybe an option is missing for handling user service from root directly as the -o option of the scandir command. It can be easier for sysadmin to administrate user services. Also, it's planned to incorporate the s6-svperms features (more or less) and also certainly implemented at the groups feature for a tree.
pramodvu vixalien Personally, I would prefer having a simple list of services instead of having a module service like boot@. This would also make it easier to convert existing alpine services.
Yes, a simple list of services is what is to be done for time being.
It would be sufficient to be on par with openrc.
You can also use the tree features to get a runlevel behavior as tree have interdependence between them. It easier to build the boot with separated services but it will be less easier for user to modify it. It's clearly a matter of choice.
I need to revamp the service for the boot (maybe boot2@) even for Obarun to use and incorporate the newest feature of 66. I was waiting to reach the 0.8.0.0 version (this release bring frontend service declaration stability). The new identifier solve some problems like the dbus@ instance for user. With the @U identifier, this service not need to be an instantiated one anymore. It can be easier for user to do 66 start dbus instead of 66 start dbus@<user> and also easier to declare interdependence between services like Depends = ( dbus ) instead of Depends = ( dbus@<user> ) even if you can do now Depends = (dbus@@U) for now.
The 66-ns will be incorporated directly on 66 with a [namespace] section (or [ns] don't know yet about the name). To be honest, even if its work, i'm not really happy of the 66-ns programm.
Actually, the 66-ns program broke the service supervision. Let me explain. When you launch a service through 66-ns, the state of service inside the namespace is never know by the s6-supervise supervising the 66-ns program. That mean that:
s6-supervise test_ns
|_ 66-ns -o unshare=pid bash -c "haveged;dhcpcd"
|_ haveged
|_ dhcpcd [master]
|_ dhcpcd [control proxy]
|_ dhcpcd [network proxy]
if the haveged service exit, the signal is not transmitted to the s6-supervise through the 66-ns process. And so, the supervision tree is not aware about the changes of the state of the haveged service. You also cannot control the haveged service directly. These behavior is pretty annoying and will be resolve in the future.
pramodvu Would you please implement Provides= in 66's frontend? It would be of help.
No need to ask for it, it's already planned. But, it not so evident to implement it and i'm very very happy to see this kind of discussion about implementing new features. I was waiting for this kind of discussion from a long time. Two mind is better than one concerning reflection, conceptualization of a feature.
But please do not mix different point on the same thread. Prefers to use an existing one or create a new one especially to talk of it. So, i will answer on this here
